Jump to content

  • Log In with Google      Sign In   
  • Create Account


Which language is best for a 3d Games Engine?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
19 replies to this topic

#1 Roger Rabbit   Members   -  Reputation: 122

Like
0Likes
Like

Posted 11 May 2006 - 06:51 AM

Hi All I'm about to embark on a project to create a 3D Games Engine with some fellow programmers. I was wondering which language would be best to use for creating the engine; C++ or C#? The engine will be DirectX based, and aimed, for now, just for PC gaming. Thanks! -Andy

Sponsor:

#2 deathkrush   Members   -  Reputation: 350

Like
0Likes
Like

Posted 11 May 2006 - 06:57 AM

If you want pure speed, go with C++. If you don't like dealing with pointers and want to use Managed DirectX, go with C#. It'll be pretty slow in C# though, so if you are planning to have a high-poly count and multi-pass techniques, forget it. For low-poly geometry, C# and Managed DirectX are OK.

#3 Washu   Senior Moderators   -  Reputation: 3953

Like
0Likes
Like

Posted 11 May 2006 - 07:00 AM

Quote:
Original post by deathkrush
If you want pure speed, go with C++. If you don't like dealing with pointers and want to use Managed DirectX, go with C#. It'll be pretty slow in C# though, so if you are planning to have a high-poly count and multi-pass techniques, forget it. For low-poly geometry, C# and Managed DirectX are OK.


Please do specify your source for this particular tidbit of misinformation.

OP: Either language will do, however, you will find that some languages are a lot easier to learn/use than others. C++ is not a newbie friendly language, and I would tend to recommend going with something else.

#4 Josh Petrie   Moderators   -  Reputation: 2719

Like
0Likes
Like

Posted 11 May 2006 - 07:07 AM

Go with whatever language you know better. If you don't know either, follow Washu's sage advice. C++ is not a good choice for a beginner to learn.

MDX and C# are perfectly capable of doing high-performance, high-polygon count rendering. Many of the bottlenecks in graphics programming are logical (your culling sucks and you are rendering too much), unavoidable (ring-0 switch in the driver), or not CPU-bound (your shaders are too expensive). These are all language agnostic. The "performance overhead" inherent in managed languages and APIs (such as C#/MDX) will be insignifigant next to these.

MDX + C# does, however, give you a development-time speed increase assuming you are already familiar with the language and API (and even if you are not familiar you can often still develop quicker).

#5 JBourrie   Members   -  Reputation: 1201

Like
0Likes
Like

Posted 11 May 2006 - 07:10 AM

C# is a wonderful language that is much more n00b friendly, and the above post about speed is completely incorrect. C# code is very fast, and "high poly counts" or "multi-pass techniques" are reliant on the speed of the video card far more than the speed of the code (given the code isn't terribly written, anyway).

To "others", please don't give advice when you don't know what you're talking about. Thank you.

Check out my new game Smash and Dash at:

http://www.smashanddashgame.com/


#6 Bob Janova   Members   -  Reputation: 765

Like
0Likes
Like

Posted 11 May 2006 - 08:01 AM

If you know either language (or any other compiled language; you can just as well write a good 3D game in Delphi, VB.net [not normal VB tho] etc), use that. If you know neither, use C# because it's far easier to learn and far more forgiving – it's much harder to write bad C# code than it is bad C(++) code.

C# is ever so slightly slower, but not noticably if you use Managed DirectX as all the work is being done on the GPU (outside your code) anyway. Don't worry about speed.

#7 Aiursrage2k   Members   -  Reputation: 320

Like
0Likes
Like

Posted 11 May 2006 - 08:15 AM

I myself would use c++, because thats I use/know.

I dont know if c# is any slower, but you lose access to pointers, which might be a blessing or a curse. The examples that come with the directX SDK are both for: c#/c++ so that wont really matter.

#8 JBourrie   Members   -  Reputation: 1201

Like
0Likes
Like

Posted 11 May 2006 - 08:27 AM

Quote:
Original post by Aiursrage2kI dont know if c# is any slower, but you lose access to pointers, which might be a blessing or a curse.


Not necessarily. At any time in C# you can drop into "unsafe" mode, and then you get access to all of your pointers again. For the code that has to be super-fast (image manipulation and such), this is a huge blessing.


Check out my new game Smash and Dash at:

http://www.smashanddashgame.com/


#9 Will F   Members   -  Reputation: 1069

Like
0Likes
Like

Posted 11 May 2006 - 10:39 AM

A better question to ask is why you want to create a 3D engine rather than learning to use a free one like Irrlicht or OGRE (though OGRE is more of a renderer than an engine) or a cheap one like Torque or C4. Unless you need a feature that none of them provide (and would be difficult to implement in them), can do a better job, and are sure you aren't suffering from not invented here syndrome.

Of course, if you want to do it for educational purposes, go ahead with it, you'll learn much. But if you want to make an actual game rather than an engine your time will probably be better spent leveraging existing tools.

#10 JBourrie   Members   -  Reputation: 1201

Like
0Likes
Like

Posted 11 May 2006 - 11:34 AM

Quote:
and are sure you aren't suffering from not invented here syndrome.

But if you want to make an actual game rather than an engine your time will probably be better spent leveraging existing tools.


First, I'd like to point out that I get the feeling this guy is doing it for educational purposes. That being said...

Often "Not Invented Here Syndrome" is blamed, when in reality the learning curve of a full game engine is harder then just writing your own from scratch that fits your needs without the fluff.

I found that I could write a 2D game engine + physics in a fraction of the time that it took to learn Torque2D, and the interface was the way I prefer it. Sure, my engine doesn't currently support all of the features T2D has, but it supports all of the features that I need for my current project.

Using a commercial engine is a great idea if you need the feature set of the engine, and you can weigh the cost of getting up to speed with the engine VS writing your own. But it's not the end-all solution to the problem... what if you want to make Katamari Damacy? It really has it's own special set of challenges that required it's own engine to make it work efficiently. I had the same issue with Rumble Box, Torque + ODE would have been a nightmare.

One other example is a recent 2D puzzler that I worked on using the PopCap Developers Framework. Because my UI designs rarely function via the windows-like "standard", the framework ended up being a barrier as opposed to a boon, despite it's ease of use.

Use the right tool for the job :)

</rant>

Check out my new game Smash and Dash at:

http://www.smashanddashgame.com/


#11 Will F   Members   -  Reputation: 1069

Like
0Likes
Like

Posted 11 May 2006 - 02:18 PM

Quote:
Original post by JBourrie
First, I'd like to point out that I get the feeling this guy is doing it for educational purposes. That being said...

Often "Not Invented Here Syndrome" is blamed, when in reality the learning curve of a full game engine is harder then just writing your own from scratch that fits your needs without the fluff.

Use the right tool for the job :)


Point taken. I agree that If none of the existing projects out there suit your needs, writing yor own might be the best solution. That seems to be the case in Rumble Box, and I agree with your decision - you couldn't find a preexisting solution and you didn't need many of the features they provide.

Also, "not invented here" was probably not the right phrase in my post, reinventing the wheel is more appropriate.

As for how long it takes to learn an existing engine, here's someone who made a simple game in OGRE in 2 days. Considering it was his first 3D game, how long would it have taken to make it from scratch? It's true not everyone will be able to pick it up in 2 days, and it'll take longer to learn how to use the more advanced features - but it's not that tough to get started.

I still think that if you want to spend your time making a 3D game, rather than a full fledged engine you're better off using one of the available ones - especially if you're going to need some of the features provided. If a complicated scene graph, model and texture loaders, skeletal animation, an octree or BSP, sky box/plane, particle system, etc. (which have all had extensive testing/debugging/peer review) are needed - the time taken to learn an API that already does it for you is going to take less time than writing it all yourself.

It comes down to what the OP's team wants to get out of the project - if it's a engine with a rich feature set, I think they'd be better off using an existing project (unless they're doing it because they enjoy the process of creating an engine). However, if they're more interested in making games rather than engines, I'd suggest taking a look at what's out there and evaluate how they want to spend their time.

just my 2 cents

#12 deathkrush   Members   -  Reputation: 350

Like
0Likes
Like

Posted 11 May 2006 - 02:46 PM

Quote:
Original post by JBourrie
C# is a wonderful language that is much more n00b friendly, and the above post about speed is completely incorrect. C# code is very fast, and "high poly counts" or "multi-pass techniques" are reliant on the speed of the video card far more than the speed of the code (given the code isn't terribly written, anyway).

To "others", please don't give advice when you don't know what you're talking about. Thank you.


I read the Managed DirectX Kickstart book written by the creater of Managed DirectX API. He says that doing graphics in C# is inherently and significantly slower than doing it in C++. I don't know, maybe the situation changed with the new version of the API, but last time I tried it, it was very slow even for simple scenes.

I guess it depends on what sort of system you are targetting your engine at. On slow systems you gain a lot more speed with using C++, but on fast systems you might not notice a difference between C++ and C#.

#13 Mike2343   Members   -  Reputation: 468

Like
0Likes
Like

Posted 11 May 2006 - 03:17 PM

Quote:
Original post by deathkrush
Quote:
Original post by JBourrie
C# is a wonderful language that is much more n00b friendly, and the above post about speed is completely incorrect. C# code is very fast, and "high poly counts" or "multi-pass techniques" are reliant on the speed of the video card far more than the speed of the code (given the code isn't terribly written, anyway).

To "others", please don't give advice when you don't know what you're talking about. Thank you.


I read the Managed DirectX Kickstart book written by the creater of Managed DirectX API. He says that doing graphics in C# is inherently and significantly slower than doing it in C++. I don't know, maybe the situation changed with the new version of the API, but last time I tried it, it was very slow even for simple scenes.

I guess it depends on what sort of system you are targetting your engine at. On slow systems you gain a lot more speed with using C++, but on fast systems you might not notice a difference between C++ and C#.


I've never read the book but it sounds like the author had a poor implementation. Also what is the release date on the book? I'm a C# newbie but a friend is using it to make an educational engine and it's not slow in the least. It is about 5-15% slower then his C++ engine he just finished writing (at this point I doubt he's optomized the C# one much if at all).

You need solid benchmarks to actually say what the difference is. In my friends case he's implementing everything "the same" (as much as you can, using the same features etc just re-written) so it's fairly accurate the %'s.

#14 deathkrush   Members   -  Reputation: 350

Like
0Likes
Like

Posted 11 May 2006 - 04:01 PM

Quote:
Also what is the release date on the book?


The book I was referring to is "Managed DirectX 9: Graphics and Game Programming" by Tom Miller, 2004.

#15 Washu   Senior Moderators   -  Reputation: 3953

Like
0Likes
Like

Posted 11 May 2006 - 06:18 PM

Having not read the book, i can't say for certain, but he certainly has said anything but that in his blog. Furthermore, the performance difference is at around 10% of that of C++, and that fluctuates up and down depending on what is being done. For graphics the majority of the work is spent on the GPU, not the CPU, and as such C# will have very little impact on it.

#16 JBourrie   Members   -  Reputation: 1201

Like
0Likes
Like

Posted 11 May 2006 - 06:39 PM

Quote:
Original post by deathkrush
Quote:
Also what is the release date on the book?


The book I was referring to is "Managed DirectX 9: Graphics and Game Programming" by Tom Miller, 2004.


I'll remember to not buy that book, then.

Check out my new game Smash and Dash at:

http://www.smashanddashgame.com/


#17 Tape_Worm   Crossbones+   -  Reputation: 1503

Like
0Likes
Like

Posted 11 May 2006 - 08:01 PM

Quote:
Original post by deathkrush
Quote:
Original post by JBourrie
C# is a wonderful language that is much more n00b friendly, and the above post about speed is completely incorrect. C# code is very fast, and "high poly counts" or "multi-pass techniques" are reliant on the speed of the video card far more than the speed of the code (given the code isn't terribly written, anyway).

To "others", please don't give advice when you don't know what you're talking about. Thank you.


I read the Managed DirectX Kickstart book written by the creater of Managed DirectX API. He says that doing graphics in C# is inherently and significantly slower than doing it in C++. I don't know, maybe the situation changed with the new version of the API, but last time I tried it, it was very slow even for simple scenes.

I guess it depends on what sort of system you are targetting your engine at. On slow systems you gain a lot more speed with using C++, but on fast systems you might not notice a difference between C++ and C#.


Perhaps you should read his blog. He even addresses this issue somewhat here. At what point in that book (which I have right in front of me) does he say it's significantly slower? When he mentioned a 40% difference? That passage was in reference to an early prototype version of MDX, not the current (at that time MDX 1.1) version.

I think I've seen far too many of these threads... :(

#18 Roger Rabbit   Members   -  Reputation: 122

Like
0Likes
Like

Posted 11 May 2006 - 09:27 PM

Wow! What a fast response - thanks guys! This is more for educational purposes than anything else. I'm starting a BSc in Computer Games Programming in a few months and I was looking to really stretch my programming skills before I start, as well as giving myself a kind of side project to work on for the next few years. I think for now I'll go with C# as it seems slightly easier and the general opinion is that it's not that much slower than C++. Am I correct in saying that the difference in speed between a C# Engine and a C++ Engine is dependant on the system, ie. if you have a good GPU and CPU, the C# will run nearly as fast as C++, but on a slower system the difference is much larger?

Thanks again everyone!

#19 deathkrush   Members   -  Reputation: 350

Like
0Likes
Like

Posted 12 May 2006 - 09:02 AM

Quote:
Original post by Tape_Worm
At what point in that book (which I have right in front of me) does he say it's significantly slower? When he mentioned a 40% difference?


Yea, after reading that intro part I was totally under the impression that MDX is slow. I ran a few samples from that book. On my IBM ThinkPad, the rotating cube demo seems to be running at 10-20 FPS, totally not smooth and frame skipping. A similar cube demo programmed in OpenGL and C++ runs at about 300 fps and very smooth. So I don't know, either I'm a bad C# programmer, the demos from that book are terrible or my computer is to slow to run MDX.

#20 Tape_Worm   Crossbones+   -  Reputation: 1503

Like
0Likes
Like

Posted 12 May 2006 - 10:31 AM

Quote:
Original post by deathkrush
Quote:
Original post by Tape_Worm
At what point in that book (which I have right in front of me) does he say it's significantly slower? When he mentioned a 40% difference?


Yea, after reading that intro part I was totally under the impression that MDX is slow. I ran a few samples from that book. On my IBM ThinkPad, the rotating cube demo seems to be running at 10-20 FPS, totally not smooth and frame skipping. A similar cube demo programmed in OpenGL and C++ runs at about 300 fps and very smooth. So I don't know, either I'm a bad C# programmer, the demos from that book are terrible or my computer is to slow to run MDX.


I wouldn't be so shocked to see a 50% drop with a very complex scene and poor optimization choices and the like (you'd also probably get lackluster performance under C++ if you didn't do things in the correct way). But wow! That's remarkably slow for such a simple scene. You'd have to be doing something really nasty in the main rendering loop (e.g. forcing multiple Gen2 garbage collections per frame) to get those frame rates I think. I've written many similar tests and I've always gotten roughly around the same speeds in both C++ and C# (and I have the optimizing skills of a dead gnat). Either way, something is wrong there. If the examples from the book run around the same speed, I would say something is definitely up, although, I can't understand why or what. I do know this: The rendering loop he uses in that book is horrid, and will cause gen-2 garbage collections which will slow you down (that is, if he's using the DoEvents() method, I'm too lazy to check, even if it isn't, it's still ugly). But still that shouldn't slow you down to the extremes you mention. I can see why you would think MDX was slow. Like C++, if you aren't careful on how you plan your code it'll bite you in the ass. I've seen C++ code run horribly slow because I just didn't care.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS