C# Vs C++

Not according to EVE.

As you may know, EVE has at its core the programming language known as Stackless Python.​

http://www.eveonline.com/devblog.asp?a=blog&bid=786

Contradiction there

'Quite' important.

There are entire game engines created in actionscript. To make a claim that C# of all things isn't fast enough for a game engine is ludicrous.

 

According to EVE, they used C/C++ for the graphics engine and audio engine, and python for the rest (logic [which I encompass networking and UI in), presumably for the easy threading in stack-less python.

That's not a contradiction, let me dissect the paragraph for you.

"It's not as fast as C++. "
Implying that C# isn't as fast as C++.

"You can't preform a loop and presume that it is just as fast, faster, or slower from the results of that overly simple test."
stating that the outcome of simple tests is not enough information to make a presumption of the speed of something.

performance is quite important.

Despite having the ability to make a terrible game engine in a high level language, virtually all good game engines will be programmed in lower level languages. I can not thing of any good game engine past the early 1990s that wasn't programmed in a low level language, or at least largely a low level language.

 

So the core of a 'game engine' is graphics and audio? Not since I last checked.

Exactly, you don't have enough evidence to 'make a presumption of speed' and yet you gladly make a presumption of speed

Well I already told you there are entire game and physics engines programmed in Actionscript. (These engines are used in games with MILLIONS of plays, and even make money).

http://www.flashrealtime.com/flash-game-library-engine-list/#2D

Eve uses python in its core, according to its own devs.

In short, your definition of 'good game engine' is apparently far too short sighted.

 

I consider the core game engine to be graphics, audio, and physics Everything else fits into the logic. For two out of three (and perhaps physics as well, I'd have to do more research), they don't use python.

No, I stated your tests were not made well enough to make a presumption of performance based on them. I personally have done in the past more extensive testing, as well as I know the general runtime isn't as fast due to reading and experience.

I have a hard time considering a flash game to be successful. Out of those engines though, I'd consider the engines themselves rather terrible, even if they have the ability to power flash games.

I define a good game engine as something that's:
powerful
efficient
extensible to some degree

 

Then be explicit. Wiki for example:

The core functionality typically provided by a game engine includes a rendering engine (“renderer”) for 2D or 3D graphics, a physics engine or collision detection (and collision response), sound, scripting, animation, artificial intelligence, networking, streaming, memory management, threading, localization support, and a scene graph.

Contains a lot more than your rather limited version. And of course EVE boasts even more - e.g. it's market system.

I've never considered audio or graphics to be particularly of importance when building the core of a MMO - server's generally don't have speakers or screens attached.

Then provide the tests and the numbers. The language shoot out indicates that mono is less than 3 times as slow as C on median. Given the high level of optimization that presumable gone into those tests and the fact that mono isn't .net that is excellent.

Then that is to your loss.

While I dislike flash, and action-script is slow, the flash game engines do manage to do all of that.

---------------------------------------------------------------------------

Crush the Castle (1+2+expansions) has more than 50MN plays on Armor games alone.

It apparently uses or used something called glaze:

http://armorblog.com/2009/04/production-notes-crush-the-castle/

If you don't think this is good then you entire definitions fit into context beyond any sort of usefulness for me.

 

While I don't feel like going thorugh years of projects to find one to prove a point of little consequence, here is the first page I found on a google search. http://www.codeproject.com/KB/cs/CSharpVsCPP.aspx

I have a rather different opinion than you. While I won't continue the argument as its not going anywhere, I will state that in an MMO I consider the challenging parts of the engine to be client sided. I consider the challenging parts of the logic to be server sided. It seems that in wiki's definition they include logic in the core engine, which I'd debate.

In any case, I stand by my stance that C++ is different than C# in many ways; it's more efficient if you know what your doing, as well as its ugly and not my favorite language (although, neither is C#).

EDIT: after reading the article I linked to I would like to state that although largely accurate, it is partially not, specifically saying C++ doesn't support JIT. While it is not a part of the C++ standard, many compilers and compiler back ends such as LLVM do support JIT that works rather fast).

 

Valve just phoned. They'd like you to take a look at "Machinarium". It's available right now, on Steam. And it's written entirely using Adobe's Flash. (As were Amanita Design's earlier "Samorost" titles.)

Not every game requires a first-person viewpoint and 3D graphics. Chris Sawyer made a rather large chunk of cash from his "Tycoon" series of games. All but one of the games—and the exception was developed by another development team—used an isometric 3D engine with thousands of sprites. Not a polygon in sight. (Oh yeah: and he wrote them entirely in X86 assembly language. None of yer namby-pamby C++ or C.)

*

Analysing Rare's* ZX Spectrum sprite code and duplicating it successfully while still in school is hard.

Writing a two-player, split-screen, parallax scrolling engine for an Atari ST (not STE) in Motorola 68000 assembly language. No custom chips. No hardware acceleration. None. Just you, an 8MHz CPU, and some (shared) video RAM. That is (bloody) hard.


Once, programmers flew free, soaring right up to that hot, silicon sky and surprising even the engineers who designed that hardware with what they could achieve.

Now we're bowed under the weight of gargantuan API References and endless warnings not to touch anything we're not supposed to. Programming is now mostly the drudgery of passing data between different third-party code libraries. It's a tedious game of "guess the API function call" and "find the docs".

We've been tamed. Cowed.

For me, the magic disappeared years ago; I now program only as a means to an end and vastly prefer programming humans in English. There, at least, you can still fly.

And, with that, I think it's time to sign out.


* Better known at the time as Ashby Computers Graphics, trading as "Ultimate: Play The Game".

 

Ok, since this thread has gone "my opinion is this and is better than...", something to chill out (or mabye not)

The guy that made this picture must really love Python and probably C (and obviously thinks C# is crap), but, in my opinion, his(her) view of C++ is pretty much what the language is: there is everthing you need in it, but you must choose the right part or you will end up messing the whole thing. Of course, once you know what everything is, how could I say, wellcome to hotel california

http://d3uwin5q170wpc.cloudfront.net/photo/28126_700b.jpg

 

Are you saying that you now prefer COBOL?

That picture is pretty spot on. I Lol'd hard, especially at his visual metaphor for functional programming languages. I can think of quite a few languages that I would add though.

 

Um, wow. Have you actually programmed anything in Unity? Speaking as someone who's programmed 6502 assembly (JSR $FFD2 LDA #01 STA 53281!), I guarantee it's at least as much fun as that.

--Eric

 

Hammers do different things then saws

 

In programming c# has more features by default, but it lacks many great libraries that are available in c++. Thus you need to know both to write a wrapper for example.

 

So does c++ and c#. Sure you use saw on wood, but I can also hit nails with a saw, just not as effective as a hammer.
A bit more relevant comparison would be a small hammer vs sledge hammer.

 

Or a bodywork hammer vs a carpenters hammer.

 

Correct, the same way c++ and c# do different things.
You can not write a device driver in c#, you can not write an OS in c#

 

I think that C# is alot easier to learn than C++ but that may also depend on the teacher. C# seems like a friendlier language

 

Yes, C# is friendlier, o ye mighty thread necromancer.

 

Learn C# for the ease of getting into programming, then learn C++ because it's still required by alot of game companies if you look for programming jobs.

 

Java, even out performs C++ in some areas (see: http://en.wikipedia.org/wiki/Java_performance#Program_speed).

C# looks like the bastard child of Java/C - it's too bad, I grew up on Turbo Pascal and followed Anders Hejlsberg all the way to Delphi, at that point moving on to "Oak" later called "Java". So I've always liked Anders compilers until I saw the train wreck that is C#.

What I'd really like to see is a performant Groovy for Unity3D or at least Java.

And no, Javascript != Java.

That said, given the choices .. Boo, JS and C#, there's only one serious choice there anyhow which is C#. To answer the question, between C++ and C# I'd go with C#, simply because the use cases where i'd achieve and significant performance gains in C++ would be offset by the simplicity in dealing with everyday coding in C# (if somewhat half-baked and convoluted).

 

thank you!