SlimDX, MDX or OGL?

Started by
20 comments, last by FeverGames 15 years, 4 months ago
I had a look around the forums, so forgive me if Ive missed something about this already. Ive been programing in C# for the past year or so, and Ive started looking at trying my hand at building a game. However, I'm not exactly sure what which way to go. Ive heard alot of people say to use C++ instead of C#. But I already know a decent amount of C# and am comfortable with it. So, should I stick with C# or try C++? Should I try and use the OpenGL, DirectX/MDX or SlimDX?
Its Db, not C#...
Advertisement
Take my words with a grain of salt, as I'm a C++ DirectX programmer (before using DX I was on OGL side), so I'm not into MDX/SlimDX, etc.

As for OpenGL/DirectX you can find many threads here. In the end it's up to you.

AFAIK MDX is dead, so I wouldn't suggest you to use it. SlimDX could be a better option but if you already know C#, I suggest you to have a look at XNA.

i wonder why you say he should take a look at xna. Xna isn't exactually an industry standard way of working, it is a premade sort of engine in which a lot is not possible because it is based on development for the 360, and secondary for the PC.

so i do not agree that XNA is better if you already have knowledge of C# over SlimDX, i'd rather take the opposite. If you have little knowledge of C# XNa is great to get lots done in notime, but SlimDX gives you way more freedom because it has nothing premade, except the fact that you can do all the DX calls like is done in C++.

but thats my word.
I'd suggest sticking with C# and learning XNA too.

C# is perfectly fine for game development, although it's limited to Microsoft platforms. C++ is still the main language used in the industry, but it's best to learn one thing at a time and learn XNA, then look at C++ if you want.

And if you're a C# person, you'll most likely be comfortable with XNA/DirectX than with OpenGL.
I myself am a .NET developer, but I've been programming with C++ for years as well, so I can give you some advice. Your productivity will increase a lot if you use C# instead of C++. Some reasons to do so:
1) First, and most important of all, the .NET framework. In C++ you need a threading library, a sound library, a graphics library, etc... Plus, boost sucks. It just tries to emulate things that C++ wasn't meant for. In .NET, however, everything is there for free - just name it: garbage collector, network library on top of sockets (plus them if you need them), continual improvement, ridiculously easy multithreading and synchronization... If you want to build your graphical tools - WinForms and WPF are there waiting for you. And everything is well integrated.
2) Productivity. C++ is not meant to be a robust language (I mean for RAD). C#, however, is designed for that. The least of all is garbage collection. In C#, you can remove all elements of a collection given some predicate in just one line of code (IEnumerable's extension methods + lambda expression). You will never worry about simulating a sprintf behaviour in C# - it is just adding the params keyword before the last argument. These are just very simple examples - but in C++ you don't even have descent exception mechanism, using exceptions is even considered highly ineffective. For example, there is no such thing as finally. In C++ your destructor is not always called. So, your program crashes and there is a pretty good chance to leave lots of resources unfreed. Cool, huh?
3) Events and component-driven programming. In C++ you can emulate this behaviour with boost (which sucks IMO), Qt's signals and slots, Gtkmm's signals and slots (the last two being extremely intuitive and nice to use; boost claims to have improved gtkmm, but in reality it just made something very nice into a complete disaster). However, the resulting code is ugly and it is not very easy to get started, because all the examples online are extremely simple and if you need something complicated, you are left on your own and you will lose lots of time of research for something that is a-matter-of-fact in C#. Look at System.Collections.ComponentModel.ObservableCollection and see what I mean. You can do it in C++, but you will lose a lot of time before you even start coding for something as simple as that. In boost's signals you don't have the full control of an event's add and remove overides (just as a property's get and set if you've never customized an event). Something essential for component-driven programming (well, objects in games to tend to be componets with events, properties and all) is data binding, which is something you have to emulate on your own in C++ (not that it is difficult, but every time you have to emulate a feature, there is a chance that you make a mistake somewhere, and most importantly - you lose time).
4. Visual studio. It is free for both C++ and C#. However, code completion in C++ isn't good at all. It is the best there is (Eclipse CDT is very close, however), but it still isn't as good. Microsoft is investing a lot of money in .NET, and I'm left with the feeling that they just neglect C++. There are .net-only features in Visual Studio, which I find invaluable. For example, before you start coding, you have some sort of design for your game. Well, you can visually (via drag&drop) create a class diagram, and the tool generates the skeleton code for you. Every method is "implemented" with throw new NotImplementedException(), so you can't forget to implement them :D. There are very nice shortcuts: automatic add of a using statement, make a property out of a field, rename using refractor, etc. Templates are very time-saving as well: type for, the double-press tab, and it generates the skeleton for you. The same for all code structures. There is a shortcut for automatic interface and abstract class implementation (skeleton).

In conclusion, productivity in C++ is just not good enough once you've been used to C# and .NET. I would use C# or Python for my projects over C++ anytime. If you want to use C# and OpenGL, you can try OpenTK - it seems very SDL-like (and is therefore very nice). For DirectX, you were told: XNA is very beginner-friendly.

Just to add, SlimDX is nowdays good to use for development. It is (at least in my experience) stable and is not going to change _hughe_. But to be sure some of their developers should tell you these things.

if you are a beginner XNA is great. It depends on your needs as well. Are you going to develop an engine or are you going to make a simple scene with some effects, without bothering how it all actually works inside out...
Quote:Original post by Evil Steve
C# is perfectly fine for game development, although it's limited to Microsoft platforms.


Come on Steve, you're smarter than that. C# isn't limited to Microsoft, I've seen C# games running on a Mac OS. Portability depends on what APIs you use, not the language. You'd have to use Mono instead of .NET and use Tao instead of DirectX.

SlimDX - Windows
XNA - Windows, XBOX360, Zune
OpenGL - Windows, Mac, Linux

Not trying to say SlimDX is bad, I actually prefer it to the others. It just isn't as portable. If you don't care about that than give it a try.
Quote:Original post by Scet
Quote:Original post by Evil Steve
C# is perfectly fine for game development, although it's limited to Microsoft platforms.


Come on Steve, you're smarter than that. C# isn't limited to Microsoft, I've seen C# games running on a Mac OS. Portability depends on what APIs you use, not the language. You'd have to use Mono instead of .NET and use Tao instead of DirectX.
You're right, I was having some sort of brain fart [embarrass]

I should have said, it's not available on as many platforms as C++ is.
Quote:Original post by FeverGames
i wonder why you say he should take a look at xna. Xna isn't exactually an industry standard way of working, it is a premade sort of engine in which a lot is not possible because it is based on development for the 360, and secondary for the PC.


Whoa whoa whoa whoa let's hit the breaks and back up a bit here.

XNA is not an engine or anything close to it. It has a few optional components like the Game class and the Content Pipeline that could be parts of a much larger engine, but if so they would be a small part of it.

What is it that you think is "not possible" with it? On the PC side of things the Graphics component is a wrapper of D3D9. The only things you can't do are the vendor-specific hacks, which off the top of my head included Nvidia's hardware shadow maps, ATI's R2VB, and any of the old methods for binding the depth buffer as a texture. Not exactly deal breakers, IMO (especially when you consider that you gain compatibility with a console for those things).

As for your assertion that it's "based on development for the 360", I'm a little curious as to what leads you to say that. If you ask me or any of the other guys who develop for the 360 using XNA, I doubt you'll find any that wouldn't agree that the PC is a much better choice for running a managed framework.
i say this because if you start implementing things like low level audio api's or world wide used physics engines you are not going to be able to deploy it on the 360 anymore, which is kind of a big part of the whole xna thing. Also it doesn't allow you to easily swap to stuff like DX10 or DX11 in future, if not never.

ok so XNA might not be an engine, but it does do lots of things for you which you might not want.

but this might go a bit to much offtopic. I am just not a big fan of XNA :) It's a great way to start fast with 3D and get results fast on both the Xbox and pc. Just don't pass the lines that microsoft gives you (audio specific, physics specific, scripting languages other then written in .NET) :)

This topic is closed to new replies.

Advertisement