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.
Related
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).
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.
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".
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.
Will learning C++ help me build native applications with good speed? Will it help me as a programmer, and what are the other benefits?
The reason why I want to learn C++ is because I'm disappointed with the UI performances of applications built on top of JVM and .NET. They feel slow, and start slow too. Of course, a really bad programmer can create a slower and sluggish application using C++ too, but I'm not considering that case.
One of my favorite Windows utility application is Launchy. And in the Readme.pdf file, the author of the program wrote this:
0.6 This is the first C++ release. As I became frustrated with C#’s large
.NET framework requirements and users
lack of desire to install it, I
decided to switch back to the faster
language.
I totally agree with the author of Launchy about the .NET framework requirement or even a JRE requirement for desktop applications. Let alone the specific version of them. And some of the best and my favorite desktop applications don't need .NET or Java to run. They just run after installing. Are they mostly built using C++? Is C++ the only option for good and fast GUI based applications?
And, I'm also very interested in hearing the other benefits of learning C++.
yep, C++ is absolutely great. Check Qt. It has a great Python binding too, so you can easily prototype in Python, and when/if you need extra performance, porting to C++ is a mostly 1:1 translation.
But in fact, writing C++ isn't so hard either when you have a great platform, the worst part is writing all the class declarations :-)
If you want to build Windows applications that will run without frameworks such as .NET or virtual machines/interpreters, then your only really viable choices are going to be Visual Basic or C/C++
I've written some small Windows apps before in C++ code, and there is definitely a benefit in terms of speed and ease of deployment, at the expense of difficulty going up for development. C++ can be very fast, natively compiles, has many modern language features, and wide support. The trade off is that it's likely that you'll need to write more code in certain situations, or seek out libraries like Boost that provide the functionality you're after.
As a programmer, working in C++ and especially in C is good experience for helping you understand something just a tad closer to the machine than say, .NET, Java or a scripting language like VBScript, Python, Perl etc. It won't necessarily make you a better programmer, but if you are open to learning new lessons from it you may find that it helps you gain a new perspective on software. After all, most of the frameworks and systems you depend on are written in pure C, so it will never hurt you to understand the foundations. C++ is a different animal from straight C, but if you develop in C++ for Windows you'll likely find yourself working in a mix of C and C++ to work with Windows APIs, so it will have a trickle-down effect.
I wrote C++ windows apps for 10 years and switched to c# about 2 years ago to work on the latest product. I am embarrassed by how pathetic the C# app is. It takes 20 seconds to start up, you have to wait a second or so for it to switch between screens. I've used some third party GUI control library, and that leaks memory like a sieve! My app runs at 150 meg, and its doing hardly anything.
I am looking to go back to C++.
You can use MFC, it will be far quicker than .Net. Or, if you really want to burn, check out WTL - aLthough, there's not much documentation for that. I suggest you go with either MFC or Qt because you'll find plenty of good information and tutorials for them.
I can see that C# can be quicker to develop with, and maybe in some future version it will be quicker and smaller.
You will hate my answer:
The biggest bottlenecks in GUI development usually are not because of the language. After all most of the time in most applications the UI is idling, waiting for some user input. I can hear your screams already, but I said in most of the apps.
Let's put it this way: I am pretty sure that one can design a good UI on top of the .Net CLR. Learning C++ is a good thing, but will not solve the inherent problems of developing a good UI.
As always. It depends.
As long as you stay away from microsofts large Frameworks, as MFC, .net etc your applications can be blazing fast, but hard to code. Your benefit: You will really learn how windows is working behind its nice(?)surface. Just look into the initialisation code for COM-Objects and you know what I mean. You will never see such things in VB or C#
You have to program each button, each window and each control by yourself, sending silly window messages, however your applications are small, very small. This is an forgotten art:
Write small, fast programs
Good luck!
If you're committed to learning the raw, gritty details of Win32, then C++ will get you there. If you're not, then you'll end up using a bunch of wrappers anyway. For something like a small utility or especially something like a shell extension (where trying to use .NET will cause you problems anyway), C++ will let you write effective code with the absolute minimum in external dependencies. For a larger app, YMMV - a lot of the UI sluggishness out there comes from poor design: naive algorithms, an unwillingness to spin off non-trivial operations onto separate thread(s), reliance on badly-written 3rd-party components instead of custom controls... Mistakes easily made in any language.
Here is my honest answer to this.
First, I think every programmer should learn C/C++ just for the fact that by learning C++ you learn about programming. It is a systems-level language. You have to consider the finer details of memory management and so forth. I am shocked at how many programmers do not understand the foundational aspects of a programming language or computer system. By learning C/C++, you force yourself to understand programming at a more intimate level. On top of that, if you learn how to program in C/C++, you can program in almost anything.
That isn't to say C/C++ is always the right tool for the job. It can be a total pain to debug and take longer to write more meaningful code. However, it is perfect for those situations where you need absolute control of how a program executes.
This goes to say, I don't prefer C/C++ for UI programming. You still have to use a windowing framework specific to the OS you run on (MFC,Win32,Motif,GTK,QT,etc.). These frameworks don't lend themselves to easy learning curves. For at least Windows development, .NET is really the future of UI development (even though surprisingly MFC got a major overhaul for Vista that does stuff .NET doesn't even do yet). If you write your UI in .NET, it is easier to maintain and for others to maintain.
I typically write my UI in .NET and backend in C++.
Yes and no. It's all about optimization...And since C++ allows you to work on a lower level C++ is one of the best languages to write fast applications.
However those low-level mechanics implemented in C++ could be very annoying if you're used to more abstract approaches to OOP.
Testing your software in C++ is usually a long process.
If you are looking for speed anyway, C++ would definitely be one of the best choices.
C++ will indeed potentially get you a leaner, meaner and faster application (if you do it right).
However, the .NET framework is built for comfort from a developer point of view; a vast improvement over Win32 API or MFC, which may seem like hard work in comparison, So consider how you will implement the aspects for which your application depends on .NET (there are other frameworks available that may be easier than MFC or Win32 API), and also consider the costs and license issues of using such frameworks; for example the free VC++ Express Edition for example does not include MFC support.
If you know where you application is sluggish, C++/CLI may be a solution; allowing you to mix managed and native code to accelerate the parts that need it. However if it is the GUI that is intrinsically slow rather than the application processing; this may not be a useful path.
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.
C++ just sucks too much of my time by making me micro-manage my own memory, making me type far too much (hello std::vector<Thingy>::const_iterator it = lotsOfThingys.begin()), and boring me with long compile times. What's the single best alternative for serious real-time graphics programming? Garbage collection is a must (as is the ability to avoid its use when necessary), and speed must be competitive with C++. A reasonable story for accessing C libs is also a must.
(Full disclosure: I have my own answer to this, but I'm interested to see what others have found to be good alternatives to C++ for real-time graphics work.)
Edit: Thanks everyone for the thoughtful replies. Given that there's really no "right" answer to this question I won't be selecting any particular answer. Besides I'd just pick the language I happen to like as a C++ alternative, which wouldn't really be fair.
What about D Programming Language?
Some links requested in the comment:
Win32 Api
Derelict (Multimedia lib)
I wouldn't discard C++. In fact, I would consider adding Boost to your C++ library, which makes the language much more usable. Your example would become:
BOOST_FOREACH( Thingy& t, lostOfThingys ) {
// do something with 't'
}
Boost has tons of tools that help make C++ a better language.
C# is a nice language that fits your requirements, and it is definitely suited for graphics, thanks to the efforts of Microsoft to provide it with great tools and libraries like Visual Studio and XNA.
Real-time + garbage collection don't match very well I'm afraid.
It's a bit hard to make any real-time response guarantees if a garbage collector can kick in at any time and spend an undefined amount of processing...
I disagree with your premise. When used carefully and properly, C++ is a great language, especially for a domain like real-time graphics, where speed is of the essence.
Memory management becomes easy if you design your system well, and use stl containers and smart pointers.
std::vector::const_iterator it = lotsOfThingys.begin()) will become much shorter if you use
using namespace std;
typedef vector::const_iterator ThingyConstIter;
And you can shorten compile times significantly by breaking up your systems into reasonably self-contained modules, by using precompiled headers, or by using the PIMPL idiom.
Perhaps a hybrid approach. Python and C++ make a good combination (see, for example, PyGame).
Some variation of Lisp that compiles to machine code could be almost as fast as C++ for this kind of programming. The Naughty Dog team created a version of Lisp called Game Oriented Assembly Lisp, which they used to create several AAA titles, including the Jak and Daxter series. The two major impediments to a Lisp approach in the game industry would be the entrenched nature of C/C++ development (both tools and human assets are heavily invested in C/C++), as well as the difficulty of finding talented engineers who are stars in both the game programming domain and the Lisp language.
Many programming teams in the industry are shifting to a hybrid approach wherein the real-time code, especially graphics and physics code, is written in C or C++, but game logic is done in a higher-level scripting language, which is accessible to and editable by programmers and non-programmers alike. Lua and Python are both popular for higher-level scripting.
Let's not forget to mention the new 'auto' use:
auto it = lotsOfThingys.begin(); // Let the compiler figure it out.
auto it2 = lotsOfFoos.begin();
if (it==it2) // It's still strongly typed; a Thingy iter is not a Foo iter.
As a developer/researcher/professor of 3D VR applications for some 20 years I would suggest there is no alternative (except possibly C). The only way to reduce latency and enable real-time interaction is an optimized compiled language (eg C or C++) with access to a fast relaible 3D graphics library such as OpenGL. While I agree it is flustrating to have to code everything, this is also essential for performanc and optimization.
Sometimes, looking outside the beaten path you can find a real gem. You might want to consider PureBasic (Don't let the name mislead you). Here's some details:
PureBasic Features
Machine Code (Assembly) executables (FASM)
In-line Assembly support
No run-times needed (no DLLs needed,etc.) 1 executable file
Tiny executables (as small or smaller/as fast or faster than C++ w/out the runtime)
You can write DLLs
Multi-thread support
Full OS API support
Multi-platform support
Windows 95-2003
Linux
Mac-OS X
Amiga
2D & 3D game development
DirectX
OGRE
Generous Licensing
Inexpensive (79 Euros or about $112)
Life-time license (all future updates & versions included)
One price for all platforms
External Library support
3rd party DLLs
User Libraries
On-line Support
Responsive development team led by it's creator
On-line forum
One place for answers (don’t have to go all over the net)
Huge amount of sample code (try code out while in IE with IEtool)
Fast replies to questions
Bonus learning (alternative to learning C++)
API
Structures
Interfaces
Pointers
Visit the online forum to get a better idea of PureBasic (http://www.purebasic.fr/english/index.php) or the main site: www.purebasic.com
I completely agree with the mention of C# for graphics programming. It has the slight disadvantage of being a managed language and allowing the garbage collector free reign over your application is framerate suicide after a while but with some relatively intelligent pool allocations made early in the program's life any real issues can be avoided.
Several people have already mentioned XNA, which is incredibly friendly and well-documented and I would like to echo that recommendation as well. I'm personally using it for my hobby game projects and it has treated me very well.
XNA isn't the only alternative, though. There is also SlimDX which is under constant development as a means of providing a lean wrapper of DirectX in a similar fashion as Managed DirectX (which was, I believe, discontinued by Microsoft in favor of XNA). Both are worthy of research: http://code.google.com/p/slimdx/
There are no true alternatives for big AAA titles, especially on the consoles. For smaller titles C# should do.
C# is a good answer here - it has a fair garbage collection (although you'd have to profile it quite a bit - to change the way you handle things now that the entire memory handling is out of your hands), it is simple to use, have a lot of examples and is well documented.
In the 3D department it gives full support for shaders and effects and so - that would be my choice.
Still, C# is not as efficient as C++ and is slower due to overhead, so if it is speed and the flexibility to use any trick in the book you like (with pointers and assembly if you like to get your hands dirty) - stick to C++ and the price would be writing way more code as you mentioned, but having full control over everything including memory management.
I would say the D programming language is a good option. You can link to C object files and interface with C++ code through C libraries. D has garbage collection, inline assembly, and game developers have created bindings to SDL and OpenGL libraries, and are also actively working on new game development apis. I love D. Too bad my job doesn't demand it's use. :(
Like James (hopkin), for me, the hybrid approach is the best solution. Python and C++ is a good choice, but other style like C#/C++ works. All depends of your graphical context. For game, XNA is a good platform (limited to win32), in this case C#/C++ is the best solution. For scientific visualization, Python/C++ is accepted (like vtk's bindings in python). For mobile game JAVA/C++ can works...
If you are targeting Windows, C++/CLI (Microsoft's .NET 'managed' dialect of C++) is an interesting possibility, particularly if you want to leverage your C++ experience. You can mix native code (e.g. calls to C-style libraries) with .NET managed code quite seamlessly, and take advantage of .NET GC and libraries.
As far as concerns about GC impacting 'real time' performance, I think those tend to be overblown. The multi-generational .NET GC is very good at never taking much time to do a collection, unless you are in some kind of critical low-memory situation. I write .NET code that interacts with electronic derivatives exchanges, where time delays == lots of $$$, and we have never had a GC-related issue. A few milliseconds is a long, long time for the GC, but not for a human interacting with a piece of software, even a 'real time' game. If you really need true "real time" performance (for medical devices, process control, etc.) then you can't use Windows anyway - it's just not a real-time OS.
Lot of game engines can fit your need, I suppose. For example, using SDL or Cairo, if portability is needed. Lot of scripting languages (coming in general with easy syntax and garbage collection) have binding to these canvas.
Flash might be another alternative.
I will just point out Processing, which is an open source programming language and environment for people who want to program images, animation, and interactions.
Actually, it is a thin wrapper around Java, making it look like a scripting language: it has a (primitive) IDE when you can type a few lines of code and hit Run without even having to save the file. Actually it wraps the code around a class and adds a main() call, compiles it and run it in a window.
Lot of people use it for real-time exhibitions (VJ and similar).
It has the power and limitations of Java, but adds out of the box a number of nice wrappers (libraries) to simplify access to Java2D, OpenGL, SVG, etc.
Somehow, it has become a model of simple graphics language: there are several applications trying to mimic Processing in other languages, like Ruby, Scala or Python. One of the most impressive is a JavaScript implementation, using the canvas component implemented in Firefox, Safari, Opera, etc.
I vote c++0x. Partial support is already available in gcc-4.3+ using the -std=c++0x flag.
Would 'C' be too obvious an answer?
I have very successfully used C++ for the engine, with the application written in Lua on top. JavaScript is also very practical, now the latest generation of JIT based JS engines are around (tracemonkey, V8 etc).
I think C++ will be with us for a while yet; even Tim Sweeney hasn't actually switched to Haskell (pdf) yet, AFAIK :-)
Java and LWJGL (OpenGL wrapper) has worked well for me. If you're looking for more of a scene graph type library like Orge have a look at jMonkeyEngine which we used to create a google earth type application (see www.skapeworld.com). If you're sensible with object creation the garbage collection is a non issue.
If your target is a PC, I think you can try C#, or embed Lua in your C++ app and run scripts for 'high-level' stuff. However if your target is a console, you must manage your own memory!
Objective-C looks like a good match for your requirements (the latest version with optional GC), although it is too dynamic and Smalltalk-like for my taste.
XNA is your best bet I think. Being supported by the .NET framework you can build for a Windows or Xbox 360 platform by simply changing a setting in Game Studio. Best yet, all the tools are free!
If you decide to go with XNA you can easily get started using their quickstart guide
XNA Quickstart guide
It has been a rewarding and fun experiance for me so far, and a nice break from the memory management of C++.
Garbage collection is a must (as is
the ability to avoid its use when
necessary)
You can't disable a garbage collector temporarily. You would need a deterministic garbage collector then. But such a beast does come with a performance hit also. I think BEA JRockit is such a beast and then you should stick to Java.
Just to comment on your example; typedef is your friend...
typedef std::vector<Thingy> Thingys;
Thingys::const_iterator it = lotsOfThingys.begin()
Don't overlook independent languages in your quest. Emergence BASIC from Ionic Wind Software has a built in DirectX 9 engine, supports OOP and can easily interface with C libraries.
http://www.ionicwind.com
James.
The best enviroment for your project is the one you get your task done in the fastest way possible. This - especially for 3D-graphics - includes libraries.
Depending on the task, you may get away with some minor directx hacking. Then you could use .NET and slimdx. Managed languages tend to be faster to programm and easier to debug.
Perhaps you need a really good 3D-engine? Try Ogre3D or Irrlicht. You need commercial grade quality (one might argue that Ogre3D offers that) - go for Cryengine or Unreal. With Ogre3D and Irrlicht you might uses .NET as well, though the ports are not always up to date and plugins are not as easyly included as in the C++ versions. For Cryengine/Unrealengine you won't have a real choice I guess.
You need it more portable? OpenGL for the rescue - though you might need some wrapper (e.g. SDL).
You need a GUI as well? wxWidgets, QT might be a possiblity.
You already have a toolchain? Your libraries need to be able to handle the file formats.
You want to write a library? C / C++ might be a solution, since most of the world can use C / C++ libraries. Perhaps with the use of COM?
There are still a lot of projects/libraries I did not mention (XNA, Boost, ...) and if you want to create some program that does not only display 3D-graphics, you might have other needs as well (Input, Sound, Network, AI, Database, GUI, ...)
To sum it up: A programming language is a tool to reach a goal. It has to be seen in the context of the task at hand. The task has its own needs and these needs may chose the language for you (e.g. you need a certain library to get a feature that takes long to programm and you can only access the library with language X).
If you need the one-does-nearly-all: try C++/CLI (perhaps in combination with C# for easier syntax).
Good question.
As for the 'making me type far too much', C++0x seems to address most of it
as mentioned:
auto it = lotsOfThingys.begin()) // ... deduce type, just like in *ML
VS2010beta implements this already.
As for the memory management - for efficiency - you will have to keep good track of memory allocations, with or without garbage collection (ie, make memory-pools, re-use allocated object sometimes) anyhow, so that eventually whether your environment is garbage collected or not, matters less. You'll have to explicitly call the gc() as well, to keep the memory from fragmenting.
Having consistent ways to manage memory is important anywhere.
RAII - is a killer feature of C++
Another thing - is that memory is just one resource, you still have to keep track of other resources with a GC, so RIAA.
Anyhow, C# - is a nice alternative in many respects, I find it a very nice language, especially the ability to write functional-style code in it (the cute lambda -> syntax, map/select 'LINQ' syntax etc), thus the possibility to write parallel code; while it's still a 'standard curly-brackets', when you (or your colleagues) need it.
Have a look to Delphi/Pascal Object and some exemples :
http://www.delphigamer.com or http://glscene.cjb.net/
You can look at Ada. There is no garbage collector but this language is oftenly used for real-time system needing high reliability. That means less debuging times for your 3D applications.
And, you can also look at Haskell, if you don't know the functional paradigm this language will look weird to you, but it's worth a bit of your time. Tim Sweeney (EPIC Inc) is considering this language as a C++ alternative.