Which language is best for a 3d Games Engine?

Will F · May 11, 2006 08: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

deathkrush · May 11, 2006 08: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#.

CrazyCdn · May 11, 2006 09: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.

deathkrush · May 11, 2006 10: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.

Washu · May 12, 2006 12:18 AM

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.

JBourrie · May 12, 2006 12:39 AM

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.

Tape_Worm · May 12, 2006 02:01 AM

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... :(

Roger Rabbit · May 12, 2006 03:27 AM

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!

deathkrush · May 12, 2006 03:02 PM

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.

Tape_Worm · May 12, 2006 04:31 PM

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.

Which language is best for a 3d Games Engine?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Which language is best for a 3d Games Engine?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines