• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Roger Rabbit

Which language is best for a 3d Games Engine?

19 posts in this topic

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
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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).
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.

0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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>
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
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#.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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... :(
0

Share this post


Link to post
Share on other sites
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!
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0