views:

3973

answers:

27

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.

+13  A: 

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.

Drealmer
+1 Its a brilliant platform, can develop on it for free (with the Express editions of VS) and C# is great to get things going quickly on. Unfortunately it lacks a lot of the power I need for writing professional games (fair bit of overhead is implicit in the sytem, c++ you can code around, plus you can access things like SIMD commands in c++)
Grant Peters
However C# may not be the best one at "A reasonable story for accessing C libs is also a must." You might also have issues outside of the Windows world.
Jem
Thanks to Mono, C# is quite portable. And accessing C libs can be easily done with P/Invoke.
el.pescado
You can develop on it for free without *any* version of VS, thank you very much.
harpo
+10  A: 

What about D Programming Language?

Some links requested in the comment:

Win32 Api

Derelict (Multimedia lib)

daddz
Is there any way to use win32 API, OpenGL and D3d through D now? Last time I looked (some time ago) there was only partial support (Being the reason my game code base is still c++)
Fire Lancer
+1  A: 

There are no true alternatives for big AAA titles, especially on the consoles. For smaller titles C# should do.

yrp
Probably true about the big AAA titles. Few business folk would want to risk it all on a non-mainstream language. Realistically C# will only do if you're only targeting Windows, no?
Baxissimo
There are AAA games written in other languages. Jak and Daxter, for example, was written in Lisp.
Nathan
C# can also run on linux and Macs, but i don't think they really have any 3d libraries yet. (Though I wouldn't be surprised if there was an OpenGL one for linux)
Grant Peters
+11  A: 

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

Pieter
That's why I said "as is the ability to avoid its use when necessary". As long as you can turn off the collection when necessary it can be ok.Also note there's a difference between the soft real-time of graphics and the hard real-time of "real-time systems".
Baxissimo
This just isn't really true anymore for modern garbage collection implementations. Although still a small minority, commercial games ARE being written in C#.
NM
Commercial games written in C# sure are possible. But may be not real-time critical ones.
Jem
It depends on the definition of real time. But garbage collection doesn't actually require long pauses; that's an implementation detail. Better implementations can also avoid reading everything into memory on the mark phase (reading everything into memory destroys any performance improvement you were hoping to get out of your cache).
Max Lybbert
+9  A: 

Perhaps a hybrid approach. Python and C++ make a good combination (see, for example, PyGame).

James Hopkin
There is that one well-known MMORPG that went that route -- Eve Online? That was Stackless Python even. Not the main line. I had forgotten about that, it's pretty much a AAA title I think. Maybe doesn't fit yrp's definition of one.
Baxissimo
I believe Eve Online uses Stackless Python for their server code. I doubt the real-time 3D code is written in Python.
Nathan
Also, PyGame is not 3D.
Nathan
+2  A: 

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.

Adi
Do you have any references saying that "C# is not as efficient as C++"? Because most of what I've seen says that the difference is neglible, and it's not even sure which one is faster. See Raymond Chen's http://blogs.msdn.com/oldnewthing/archive/2005/05/10/415991.aspx and Rico Mariani's http://blogs.msdn.com/ricom/archive/2005/05/10/performance-quiz-6-chinese-english-dictionary-reader.aspx optimization duel.
erikkallen
+2  A: 

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

Johan Moreau
+6  A: 

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

DevilDog
A: 

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!

R Caloca
Not true. XBox360 runs C#
Grant Peters
True, using XNA. But AAA-titles and most 'professional' companies, you'd probably get a blank stare if not outright anger if you suggest something else than C/C++/Asm.
R Caloca
+11  A: 

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.

Nathan
This is my cue to plug lispbuilder-sdl again...http://code.google.com/p/lispbuilder/wiki/LispbuilderSDL
justinhj
I should point out that GOAL was very much not a standard Lisp; Naughty Dog wrote its compiler internally from the ground up, and it had many features that would be quite alien to a typical Common Lisp programmer. For example, it was heavily imperative, relying extensively on side-effects, and it offered transparent integration with inline assembly so that things that looked like Lisp forms were often actually opcodes.
Crashworks
I hope to soon make some games in lisp, but unfortunately finding info on lisp game development is pretty light.
Isaiah
A: 

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.

Nemanja Trifunovic
A: 

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++.

Balk
+14  A: 

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.

Dima
precompiled headers work for gcc as well
Tom
Thanks. Didn't know.
Dima
A: 

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()
Markowitch
+1  A: 

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

komma8.komma1
+18  A: 

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.

Martin Cote
Everytime I've tried to use a non-trivial Boost library I've always been disappointed. Boost shared_ptr is about the only thing I've tried from Boost that actually did what I wanted it to, did it well, and wasn't horribly confusing, or some way limiting. YMMV.
Baxissimo
Blargh... Hate boost, long compile times, confusing and i can usually write something a lot more usable fairly quickly when I need it (and test cases make sure I iron out the bugs). I'm a professional games dev and love c++ for writing games (all that raw, low level power!) though if its not a professional game, i usually just go for C# and XNA.
Grant Peters
Have to second Grant on that. Boost is way too bloated to be useful in general. I have ended up implementing a small, sane, subset of Boost and STL and use that as a set of foundation libraries for my team's development.
Tarydon
+5  A: 

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/

mittens
+2  A: 

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.

McKenzieG1
+9  A: 

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.
MSalters
+2  A: 

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.

PhiLho
A: 

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.

+7  A: 

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.

But there are other languages that compile to native code. The D programming language is coming along very nicely. Some people say OCaml is great. Etc. Also, whatever language you use for your app, you're always going to be making calls to lower-level native libs like OpenGL, BLAS, etc to do the really heavy lifting. So I disagree that C/C++ are required to get the needed perf. But depending on the project, they may be required for other reasons.
Baxissimo
+1  A: 

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 :-)

sdclibbery
A: 

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).

Tobias Langner
A: 

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.

oyd11
+1  A: 

I vote c++0x. Partial support is already available in gcc-4.3+ using the -std=c++0x flag.

tuxjay
A: 

Have a look to Delphi/Pascal Object and some exemples : http://www.delphigamer.com or http://glscene.cjb.net/

philnext