OpenGL or DirectX? [closed] - c++

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I know this is probably a very subjective question, but I just want to start with the one which is the easiest and fastest to learn, so that I can get started with a small project of mine as fast as possible, it's a a little 2D game, to start with at least.. Which one would you recommend me to go with? And I'm using C++

First question: Are you on Windows? If not, use OpenGL.
If you're on Windows, this will come down to a matter of taste. The APIs are different, but the concepts required are very similar for both OpenGL and DirectX. Most things are supported on both, although they do work a bit differently.
Microsoft provides quite a few samples and a decent framework you can use for DirectX (9 or 10), which can make it easier to get started.
That being said, if you're targetting Windows Vista/Win7 only, moving to DirectX 10 may make life easier. A lot of the annoyances in DX9 and earlier were removed in DX10, and the API is a bit more clean.
That being said, if this is for a game, I'd recommend looking at using a middleware engine like Ogre instead of writing directly in DirectX OR OpenGL. This will make your life much simpler, especially while learning.

I haven't used DirectX, but OpenGL is fairly simple and there are some good beginner's tutorials at NeHe. Also, if you even want to go cross-platform, you'll need OpenGL.
However, DirectX isn't just a graphics library, you can also use it for sound, etc. so it's probably worth looking into.

If it's just 2D, then perhaps it might be worth looking into SDL, which is already cross platform and seems pretty easy to learn. There are many tutorials on the net, but one particular site I remember is Lazy Foo's SDL Tutorials. You can also mix OpenGL with SDL, there are tutorials for that as well.
If you don't want to use SDL, and you are on windows, I would recommend DirectX. I do recognize that the choice between them ultimately ends up in a flame war pretty much anywhere on the Internet, but my understanding is that DirectX is geared towards game developers, so you will find many utility libraries, functions, and classes that might facilitate various tasks. With OpenGL, you would have the ability to write cross platform code, provided that the helper functionality such as image loading is also cross platform (For which there are indeed cross platform libraries).
So my bottom line is: Both are fine, OpenGL gives you cross platform code (Provided you write it), and DirectX gives you more game development oriented tools and libraries.

If it's all about getting started as fast as possible, I'd recommend OpenGL on a NVidia GPU. You can throw almost anything at it and it will display something. However, if you want to achieve decent performance with low programming effort, I'd recommend Direct3D. There are too many ways to do things in OpenGL, and beginners will most certainly discover the slow paths first since they are covered by many ancient tutorials (see NeHe). Additionally, debugging OpenGL apps is painful, although tools like gDEBugger can help.

If you have some COM experience and it does not make your head hurt I'd recommend DirectX, just because SDK has a lot of good examples/tutorials right out of the box. If you better prefer more C-style programming or are confused with COM stuff then I'd say OpenGL.

As pointed out by several of other people, If you are planning to port your "Game" to other platforms other than windows, you better start using OpenGL.
If it is just a simple 2D game, and you won't need a 3D support for now, SDL would be a better choice, later you can combine "SDL" and "OpenGL" together. ( you can directly use openGL from SDL, it even has it's own header in SDL ).
At the same time, DirectX offers features that neither OpenGL, nor SDL can give you. OpenGL is way behind DirectX. [ OpenGL 3.0 is nothing more than an incremental update, the API hasn't changed much since 2.x ].
So if you are planning to write a game for windows, just use "DirectX", if not "OpenGL" and "Sdl".
Finally if you aren't looking for headaches just use a GameEngine, e.g. C4 Engine. Believe me when you go for 3D you have no choice, since there are so many topics that will need a lot of time to "Dig" and "Learn".

Related

DirectX/C++ 3D Engine programming: Learn now, or wait for DirectX 12? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'm a relatively ok-ish programmer, but my main focus has been in application development with C# so far. I have almost zero experience with game development and 3d engines - I've begun reading up on how 3d Engines work in general, e.g. there was a wonderful guide explaining how to develop a very simple software-based 3D engine in C#. Very helpful, but that pretty much summarizes my whole experience with the topic.
Also, I haven't really been working with C++ much so far (even though I'm aware of the basic conceptual differences to C#, and would consider getting up to at least "sufficient" speed in that language manageable).
So anyway, out of pure personal interest, I'd like to play around with developing - or rather, learning how to develop - simple DirectX-based 3d Graphics Engines for educational purposes.
I'm simply interested in the graphics parts (no sound/animation/game states/networking or whatever, only very rudimentary input). Rendering some simple geometry, and then progressively learning how to extend this with more modern shading techniques would be fine.
I've already found some great resources for this. But before I dig into the topic: I know DirectX12 is around the corner, and seeing how much it seems to evolve the system, I'm really not sure if there are going to be many breaking changes to the API. Or in other words: I'm afraid that I start learning DirectX 11 stuff now, and in a few months from now it'll all be useless as DirectX 12 works in a significantly different way, from a programming point of view.
I'm not sure how much of this is already known, or if there are developer previous available to the broader public already. But if its possible to tell already: Would you guys recommend me waiting for DX12, or start with v11 as development will be very similar in the future anyway?
For the record, I know of course that learning DX11 won't hurt in any case. But I'm not in a rush, and if half of what I'd be learning now becomes obsolete in a few months, I'd prefer just waiting until then to slowly get started.
Think of DX12 as "DirectX without training wheels, without brakes, and at the moment maybe without tires".
It will be more than a 'few months' for DirectX 12 to have a rich set of tutorials, support libraries, best practices, rock-solid drivers, and widely deployed support in the operating system on end-users machines. It's "bleed edge" right now, and best consumed by GPU graphics programming experts actively working on titles and engines today who want to make sure it all works.
For everyone else, learn DirectX 11 at least for the next year or so, and possibly longer depending on the needs of your app, your personal skill level, and the focus of what you are trying to learn in the meantime.
What I can say is that learning to program DirectX 11 using the legacy DirectX SDK stuff like D3DX is a dead-end for DX12. Focus instead on DirectX 11 using 'modern' helpers like DirectX Tool Kit and DirectXMath for C++.
Anatomy of Direct3D 11 Create Device
The Care and Feeding of Modern Swap Chains
Direct3D Win32 Game Visual Studio template
DirectX SDK Samples Catalog
DirectX SDK Tools Catalog
Living without D3DX
DirectX SDKs of a certain age
UPDATE: DirectX Tool Kit for DirectX 12 is now available along with some tutorials. That said, it is best to learn Direct3D 11 first as Direct3D 12 is an API designed for graphics experts and is quite unforgiving for newbies. Knowing how to use DirectX Tool Kit for DX11 will naturally map to the DirectX 12 version if you want to go that route.
Most of what you will learn using DirectX 11 will be applicable if you switch to version 12.
In fact, for your purposes, you may not ever need to switch. DirectX 12 essentially trades off ease of use for CPU performance. It also requires Windows 10, so it's going to be more than a few months before it becomes widely used.
DirectX 9 is still widely used for making games, despite its age. I wouldn't recommend it if you're starting from scratch though.
Oh, and whatever you do, don't choose DirectX 10. DirectX 11 can do all the same things, on the same graphics cards and operating systems.

QT or MFC which is better to learn [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I want to have working experience in c++ application programming. I am in dilemma to choose game programming or standalone programming. please suggest me which framework/API is beneficial for me to learn.
Qt mobile / QT gui programming , any other APIs ,
what about learning MFC instead of QT,
are there any other gui framework than qt
On the first part of the question: I suggest you try some lightweight programming in both directions.
Now on the part of what framework to use. If you truly decide on game coding only you would probably need to go with specialized framework/engine for game development. Still, Qt will let you do some game development so you can try it for game and standalone programing before you make up your mind.
Regarding the frameworks you suggested. MFC is not popular as before and probably will not be much supported by microsoft in the future. Qt and wxWidgets are popular frameworks that will allow you to do cross platform apps. I recommend Qt because it makes coding much easier, wxWidgets becomes more useful if you are really interested in making native apps for the major platforms.
There are a variety, with different benefits and limitations. MFC is pretty much just Windows, whereas QT is cross platform, and (IMO) much more in demand in the current job market (which until recently I was searching very tenaciously!) Another popular option might be WPF, which is Windows specifc.
Short answer: do QT until 'the next big thing (tm)' comes along.
I can't give you opinions here. To gain experience, start programming in whichever framework fulfills your requirements.
Qt is good enough, and there is wxWidgets as an option. These two are cross platform unlike MFC.
As for choosing between game programming or GUI programming, you can do both, one after another.
Hope this helps!
MFC is windows and if you are mainly targetting windows, WPF is the new Micorsoft desktop GUI standard. Having said this, most games do everything in a 3D API-native (OpenGL/Direct3D) manner, and the main platform-specific parts is the windowing and user input.
There also comes a tradeoff between using an existing User Interface library compared to rolling your own. You will find it quite hard to deeply integrate Qt or WPF widgets into your game as first class citizens, and may need to jump through some hoops to do certain custom behaviours. Doing it manually from scratch comes with the benefit of really learning what is going on and being able to do exactly what you want to do; but the cost of this is you arent leveraging an existing complete library.
My personal advice is to take some time to learn either Qt or WPF (Qt if you care about multiplatform, a lot of projects use Qt, but WPF is pickup up momentum, especially due to Windows 8) just to get an idea of what a UI API looks like from the client side. Also learn the basics of a graphics API (OpenGL or Direct3D). Then you will be in a much better position to make your decision. Ultimately I would recommend creating a non-game UI program, and a seperate game program. This will give you a much better idea.
In the context of a game, you can leverage Qt/WPF/etc in the area of tools and editors. But generally realtime in-game UIs use a tightly integrated 3D accelerated UI library. One such library is Scaleform (commercial, flash-based), and another is CEGUI (LGPL/MIT).

Beginning 3D programming / OpenGL

I'm fairly familiar with C / C++ / java, but I have mostly only ever done command line programming (with the exception of GUI in java).
I am really interested in 3D programming, but the problem I am having is I feel I know so little that I'm not even sure where to start so I am having difficulty searching for said resources.
I was hoping someone could point me in the right direction as to some resources / tutorials to get started.
I understand the two large platforms are OpenGL and Direct3d. My questions is which would be "better" to learn?
I originally started with a little OpenGl with some tutorials at http://nehe.gamedev.net but I later found out that most of the stuff there is depreciated / bad style.
I then learned the most recent version of OpenGL is 4.x, and my barely a year old VG card only supports OpenGL 2.x (HD 4890).
I would like to learn how to basically "walk" through some 3 dimensional environment, e.g. a maze.
I personally haven't worked with OpenGL, and I've only worked with DirectX through XNA, but from what I know, OpenGL is a somewhat easier than DirectX (not to mention cross-platform too) to learn, so that might be a better start. You don't have to worry about so many things like creating textures (e.g. with Maya) in a special format; you can just use a JPEG file or something to get it to work. I hear the Java Monkey Engine is good.
If you're using Windows and cross-compatibility isn't an issue though, certainly give Microsoft XNA Game Studio a try, it's great for beginning game programming -- fast but easy and powerful. (You'd need to learn C# though, but it should be easy, since you have more than enough experience.)
If you're more interested in 3D programming and not the underlying OpenGL/DirectX, I would start using some sort of framework or game engine, e.g. XNA, so that you're not worrying (as much) about low-level stuff. However, if you want to learn OpenGL or DirectX, I would start with 2D because it will still teach you the API, but it will be simpler (because again you're not having to deal with both 3D and an API at the same time), though you could get away with this if you're just making a simple maze game (as you say).
For modern OpenGL, the newest SuperBible covers it; http://www.arcsynthesis.org/gltut/ covers it; and http://www.swiftless.com/opengltuts/opengl4tuts.html covers it as well.
To answer whether OpenGL or DirectX is better, choose the latter if you're interested in any of or solely XNA/Xbox/Windows Phone, and the former if you're using Linux/want to write cross-platform games. I think the newer versions of OpenGL are similar to DirectX anyways.
https://gamedev.stackexchange.com/ can probably help you; there are a lot of questions aimed at beginners; see https://gamedev.stackexchange.com/search?q=beginner.
http://www.gamasutra.com/blogs/LewisPulsipher/20110516/7453/So_Youre_Going_To_Make_A_Game_For_The_Very_First_Time.php also gives some nice advice (though its for game and not 3D programming)
OpenGL and DirectX share a lot of concepts, though if you want to be cross-platform, then OpenGL is certainly the better choice. Especially if you want to target newer platforms such as Android or WebGL.
You will probably find it easiest to start with a ready-made 3D engine rather than starting out with "raw" OpenGL. Some options to get you started:
If you have Java experience, it might be a good idea to check out jMonkeyEngine. It's a fully fledged OpenGL game engine (uses LWJGL under the hood, supports bullet physics, shader architecture, full SDK etc.) and it comes with some good example code.
On the C++ side, I heard good things about Ogre3D and Irrlicht in the past.
There's a big list of game engines on Wikipedia
I really would start with XNA.
There are already some good 3D libraries and tutorials out there.
e.g. http://msdn.microsoft.com/en-us/library/bb197293%28v=xnagamestudio.31%29.aspx
http://www.nfostergames.com/XNAQuickStartEngineWalkthrough.htm
And Library example:
http://quickstartengine.codeplex.com/
This: http://www.amazon.com/Introduction-Game-Programming-Direct-9-0c/dp/1598220160 is a great book for learning "modern" (aka shader based) graphics programming with DirectX. There's also a newer DX10 edition that I'm sure is good as well but I have not actually looked at it.
I'm not aware of an equivalent OpenGL book, maybe somebody else can suggest one. Once you master the basic concepts though (vertex buffers, shaders, render states, etc) it's not very difficult to move between GL and DX since they're both basically interfaces to the same graphics hardware.

Starting with OpenGL and C++, proper path?

I need some specific and some general advice. I'm a fairly proficient Java programmer and a very experienced web programmer, but I would like to get into software development and I've been tackling C++. I have a great idea for a game I'd like to do, and I realize it will be a huge undertaking--but I'm looking at it more for an opportunity to learn C++, wrapping, really whatever I run into in the dev process...
But I can't get my foot in the door conceptually! I can handle the C++ aspect fine, it's just setting up the graphics, the RIGHT way, that's confusing me. I've run through a bunch of tutorials for OpenGL with C++ that all say the different things, none of which I can really get to work...
Some say to use GLUT and GLEW. Some say GLUT is dead and that FreeGLUT is the thing now. Some ignore those entirely and use a bunch of files like "glaux.h" that I can't seem to find--and other tutorials devoted to AVOIDING "glaux.h"... Most tutorials I've found come with the caveat in the comments that their version of OpenGL is dated and I should be using newer libraries-- and still others with 3rd party libraries like Ogre and Aurora.
I've been looking through a bunch of books and tutorials that ALL have an almost completely different setup for using OpenGL with C++. I realized there is probably not one right way of doing it, per se, but I'm looking for the way that is the most current, most popular, and will maximize the usefulness of the project as far as my learning... Any links to tutorials or advice in general is much appreciated.
BTW, I'm using Visual Studio Express 2010 (good idea?). My game won't be too graphically intense (isometric 2d) but will require a TON of logic and a TON of data, which is why I want to speed things up by using C++. Any other insights on better ways of doing it than using c++ for login AND graphics (from an industry perspective) are also very valuable to me! Thanks in advance!
Assuming you're learning OpenGL as a learning experience, I would recommend you this:
Use GLEW, no argument. Just do it, everyone does
Code only to the core profile. By default, OpenGL accepts old command (eg fixed function pipeline) that will later disappear, and you don't want to waste your time on that. Specifically: learn about VBO's, texture's, and, most of all, learn about shaders.
Forget about glaux and glut. Freeglut is a good and very standard option. A less obvious choice would be qt, but it's QGLWidget allows you to easily make gl calls, and not worry about context creation and all that. And it's dead easy to add gui options, which is always very nice to have when programming graphics.
To actually learn OpenGL, I would recommend http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Table-of-Contents.html. Nehe has that problem where more than half of the stuff is useless to learn, and there's a lot of fluff (window creation et al) around it.
But, I wouldn't really recommend OpenGL as a way to learn real-time graphics programming. Your alternatives are not limited to DirectX. I learned a ton of graphics coding from working with Ogre3D. You still have all the concepts at your disposal that you need to know (working low level with Vertex and Index buffers, Textures, shaders), and implements tons of stuff to make your life easier. You might not learn the ins and outs of a specific API, but you will learn all you need to know conceptually. When I became a graphics programmer, I hadn't written a line of DirectX code, but I got to grips with our engine really swiftly. I learned the actually calls very easy after that. Know the hardware, and the concepts. The actual implementation changes over time anyway.
Oh, and just in case I haven't repeated it enough. LEARN SHADERS
The best tutorial around is (arguably, as anything "best") Nehe opengl tutorial. At least, this tutorial has been suggested for many years.
Also since you come from a Java background you might prefer C# bindings for opengl from frameworks such as Tao, but the actual setup might be harder than say, downloading samples and running them.
It's easy to see where the variety of choices available for OpenGL with C++ would be a bit bewildering. For the most part, Java gives two a pretty clear-cut choice between two possibilities (do you want a scene graph or not?)
The situation with C++ is certainly more complex.
Glut: This is basically an OpenGL-oriented application framework. It was apparently written primarily to allow examples to be short, but still work. The original implementation has some pretty well-known bugs, and hasn't been updated in over a decade. I would only use it in roughly the originally-intended context: short samples/examples/demos.
glaux: The story here is sort of similar to GLUT. It has some memory leaks that have been known but unfixed for over a decade now. It was never portable in any case. I'd avoid this one completely.
GLEW/GLEE: These allow relatively easy use of the functions added in newer versions of OpenGL from OpenGL implementations (e.g., Microsoft's) that haven't been updated to include headers/libraries to provide access to them directly. I prefer Glee by a small margin because it initializes itself automatically, but both work fine.
FreeGLUT: This has been updated more recently, and some of the bugs expunged. It still hasn't done much to improve the basic design of GLUT though. Probably a better choice for short demos/samples, but still not (IMO) suitable for much serious use.
Ogre3D: This is much bigger than any of the preceding libraries. It's a full-blown scene graph library, with texture loading, defined file format, etc. A solid library, but be aware that if you use it, you won't normally use OpenGL directly at all (e.g., on Windows, it can render via either OpenGL or Direct3D without changing the source code at all).
OpengSceneGraph: More often used for scientifically-oriented applications, but most closely comparable to Ogre3D.
FLTK: a small, lightweight GUI library that runs on top of OpenGL.
GLFW: In the same general spirit as GLUT, but it's been updated much more recently, doesn't have nearly as many bugs, and is (IMO) a nicer design -- minimal but still suitable for "real" use.
You should be using OpenGL if you want to write portable 3D applications. Windows, Linux and Mac OS X supports it.
You might want to take a look at NeHe tutorials. It's one of the best OpenGL tutorials available on the web.
My understanding is that if you want simple support for a recent version of OpenGL you'll have to leave Windows-land, so try take it in stride when getting started is ... complicated.
I think OpenGL is probably the right choice. You might also want to consider DirectX (which is better supported on Windows), but I'm personally not a big fan of it. You could also learn C# and use XNA, but if you want to learn C++ it just defeats the purpose. (I also can't help mentioning there's a good chance you could make it fast enough without C++)
I have to agree with the others that NeHe's tutorials are pretty much classic. You might also want to consider the OpenGL Red Book, but that costs money.
Regarding the 3rd paragraph, GLUT is old (and for that matter so is GLU), but if you see a good tutorial that uses them, I don't see anything wrong with them. Once you have your feet wet you might want to consider ditching GLUT and using SDL which I believe is a lot more 'alive'.
As far as GLEW goes, I've used it with success and it's nice if you want to do something fancy like shaders on Windows. However, I would say don't worry about it at first, because it will increase your setup time and keep you from getting to the fun stuff :)

XNA, direct X , OpenGL [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have been wanting to give game programming ago for a long while and never got round to it, and i have finally decided to give it ago. I have decided to try and create a simple to 2D platform game. I have had a quick play with XNA and I do like it. What i am looking for tho is a comparison between XNA, directx, OpenGL. mainly the strengths and weakness between them. I have been a .net developer for the last 4 years and that's were my knowledge mainly is.
If you want to do Direct X, say hello to Win32 and COM as your new best buddies. You'll be spending lots of time early on learning ins and outs of the win32 API. DirectX with Win32 provides you all the features needed for sound, game input, and graphics display. You'll also be writing in C or C++, and you'll get to learn all about memory management and the C mindset - not something you should consider giving up lightly. Learning and using C as a language for a major project can be very illuminating, and make you thankful for modern programming language features and design elements. You aren't actually forced to use C or C++ for development here; there are various .NET wrappers and other language wrappers for Direct X, but if you've got .NET experience, you might as well use the framework made for .NET: XNA.
XNA is a much newer, .NET based set of tools. It provides many of the same features that straight use of Win32 and DirectX does (sound, input, etc) but natively on a managed platform. For most games (especially one when just starting out) you can get great framerates with an XNA game (even though a native app can give you more), and is very good for learning the ins and outs of game development -- you can't really go wrong. Most of the fundamental data structures you'll need (quad/oct trees, Model-view-controller architecture, handling of events, structure of your program) you will still need to learn and implement yourself, and doing it in .NET will most certainly be easier than in C and C++. As a nice side bonus, if you have an Xbox 360, XNA community games can, with some work, be released through Xbox Live marketplace. Basically, as a .NET developer, you would probably feel most comfortable here.
OpenGL is a cross-platoform library for drawing polygons. It has a different framework and API from Direct X, and does not provide any any OS interaction tools. There's packages that let you program in OGL in many different languages. However, as others have said, this will probably be just as much work as writing with Win32 and DirectX. For other features besides graphics (keyboard, mouse, joystick, audio) you could consider using a framework like SDL some of the missing DirectX features. There's a pretty decent community surrounding the library that can give you pointers and tips if you go this route.
More thoughts on this can be found in an almost identical article, here: Suggested Gaming Platform to Learn direct-x, C Open GL, or XNA.
XNA is going to be the easiest/quickest way to get a game up and running for the 360 or Windows platforms. It will allow you to continue developing in a way that you are already familiar (C#.NET) and it will provide you with a sizable framework that will take care of the commonly used stuff automatically. With this ease comes some limitations though, as you will be limited to only the aforementioned platforms and due to it being a large framework there will be a lot of overhead that will go largely unused causing performance hits, however with a simple 2D platformer, this probably isn't going to be an issue.
DirectX is going to limit you in platform as well, and is going to be a lot more complicated to learn and develop in. Also you will most likely be programming in C or C++ here. The advantages will be in performance, since you are handling everything you will be in control of everything and able to optimize everything for what you need. I would think that for a first game, you're going to be much better off starting with XNA and moving to DirectX after you've "outgrown" XNA. Especially with the goal of creating a simple 2D platformer.
OpenGL will allow your game to run on most platforms but will be as complicated (if not moreso) as DirectX (although I should mention there are graphic engines for OpenGL which are pretty simple to use like OGRE. You'll also be developing in C/C++ for OpenGL. Again I would think XNA would be the better choice until you feel you're ready for the next step.
If your experience has been mostly with .NET as you say, XNA would have the shortest barrier to entry although you won't get quite as good of performance as you can with other options. As you say that you're planning on making a 2D platformer, however (assuming that the implication here is "non-hardware intensive"), then XNA would be more than sufficient and probably the most suitable choice for your project.
DirectX doesn't mean you have to use native code, there's several managed wrappers out there. The performance loss is somewhere in the range of 1-3% of native DirectX, but considering you will save hours and hours of dev time and likely will never need that last 2% anyway, managed is the way to go.
See this example: SlimDX - a fully managed wrapper for DirectX in C#
One option is to write your engine in .NET but implement the renderer with C++/CLI. I'm doing this for one of my projects. XNA, OpenGL and DX are all too low-level for what I want. I don't want to write a renderer, I want to use an existing one. The Ogre3D wrapper, Mogre, appears to be a complete mess (not sure if it's the design of Mogre, Ogre3D or both), and most other wrappers are hopelessly out of date. Instead I'm implementing the renderer using C++/CLI and Irrlicht, which seems to be faster and more well designed than Ogre3D.
You may consider doing something like this.
I started out using DirectX but have now moved on to XNA, mainly because I want to be able to focus more on the actual gameplay and less on the technology behind the game. Sure, you'll still have to do some engine coding, but it helps out alot to have a framework that supplies ready made functions specifically made for game programming.