So I've fooled around with WPF a bit recently, and I must say that I really like the idea. I love the framework as a whole, from the GUI to the plumbing.
However, as much as I love managed land, I love my native code just as much. So I'm wondering what sort of libraries exists for C++ which capture the essence of various parts of WPF. I'm not looking for interop solution, nor do I want Managed C++ or C++/CLI solutions, but pure C++ solutions.
Now, I'm not expecting to find a "copy" of WPF for C++ - I wouldn't expect that to exist, nor would I need it to. Instead, I would expect that different libraries might capture a subset of the desired concepts. My particular interests are
Hardware accelerated graphics for widget based GUI's (via DirectX or OpenGL, preferably the latter)
Declarative language for GUI design (preferably an XML dialect)
Data binding
Resolution independence (less important)
To say a little about my reasoning, I would like to implement such a library myself, which captures a specific model that I have begun working out. I am in the process of finding some more inspiration and helpful resources before locking down my design. The library is intended to be cross-platform, so references to cross-platform ideas would be great, but not strictly necessary as I am usually capable of translating things into cross-platform solutions.
Lastly, although I am writing a C++ library, and C++ ideas would be great, I am open to ideas from any native language.
Thanks in advance for any help.
There isn't really anything like this. Not cross-platform at any rate. Direct2D works reasonably well, but is obviously Windows-only. And NVIDIA recently dropped this "path" extension of OpenGL that is similar in basic functionality, but it is NVIDIA-only (and not available on Mac OSX). Cairo has an OpenGL backend, but I have no idea how good it is. It can't be that good if Mozilla dumped Cairo in favor of D2D on Windows.
Many GUI toolkits have some form of language for making a GUI. Qt has one that is pre-compiled into C++.
Not that I know of. Data binding requires some form of reflection (WPF-style data binding does), and C++ has no native support for reflection. So you would need to implement reflection of some sort before you can even begin to make WPF-style data binding work.
That comes with #1. More or less, as any GPU-based renderer will be able to operate at arbitrary resolutions.
I love C++, but honestly, this sort of thing is best implemented for a higher level language. The lack of language-based reflection support will make implementing data binding a huge pain. Whereas, you could just implement the low-level "render stuff to area" and basic window/event management in C++, then expose it to a scripting language where data binding and such work. That way, you have native code speed where you need it, but the versatility and reflection of a scripting language for dealing with the GUI and its associated data.
I'm several years late, but for the benefit of anybody else reading this question: you're looking for Qt Quick / QML:
http://qt-project.org/doc/qt-4.8/qml-intro.html
http://doc.qt.io/qt-5/qtqml-cppintegration-topic.html
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 :)
Is it best to program a game for the iPhone in Objective C or in C++.
What language would a game like Flight Control be written in?
What format should graphics be in to show properly and load quickly on the iPhone?
Games like Flight Control are usually written in Objective-C with some C calls to OpenGL and other C APIs. The graphics can be stored in PNG or JPEG. I would stay out of C++ unless I had to use some C++ code or had developers with good C++ knowledge. According to my experience the bottleneck is seldom in the language, so that you haven’t much to gain by switching to C++.
You can't avoid using Objective-C or Objective-C++, due to the many APIs you'll have to interact with. Whether you also use C++ for the core of your game depends largely on experience and the third-party tools you plan to use.
I wrote my game mostly in C++ even though the only major third-party component I use — Chipmunk Physics — is written C. This was mainly because I have been programming C++ for years, and I'm much more comfortable with it than with Objective-C. Others will of course have different perspectives, depending on their experience.
Speaking more subjectively, I find C++ is a much better language for writing spatial game logic. Its ability to represent vectors, matrices, etc., as classes and overload mathematical operators on them makes things much cleaner. Also I find Objective-C's retain/release model to be a royal PITA, compared to C++'s RAII.
WRT, images. I found PNG to be quite adequate, though my game isn't texture-heavy. This page provides a lot of insight into efficient texture storage on the iPhone. Texture atlases are particularly important.
You will need to make your top level views and operating system interface in either Objective C or Objective C++. There is no way of calling the top level Apple APIs without it.
Once you get to the game logic, you can do most of your work in C if you wish to use Core Graphics or OpenGL.
You may also look at chipmunk (C) or Box2D (C++):
Should I go chipmunk or Box2D?
http://www.cocos2d-iphone.org/forum/topic/6841
I appreciate everybody's quick response and expertise.
I am in the process of learning either C++ or Objective C and it looks as though Objective C is more direct to the iPhone.
My background is "gasp" COBOL85 (among other arcane languages). I would rather have someone already fluent in iPhone apps code the game, but I would guess the development costs would make that a little prohibitive. I do have a request for bid prepared, with "pseudocode", if someone out there would like to see it and give a quote. Meanwhile, there doesn't seem to be an advantage to C++
Ken clean37#hotmail.com
You can now speed your development by using a language that doesn't require you as a developer to manage your memory manually and worry about leaks, that language is namely C#. The advent of MonoTouch is the magic that makes this possible but even before MonoTouch I've heard the Unity framework was used for several iPhone games with success.
Ok, to be less of a "commercial" (tough crowd...)
Using C# will allow you to relatively easily port your game to other mobile platforms (like the Droid) without a rewrite of the code. Objective C is hardly a language accepted widely beyond the Apple community. The AppStore is still growing thanks to iPhone4 and the iPad but the Android is nothing to sneeze at and there are other mobile devices to consider beyond the big two...
See this related answer regarding support for the Android.
Bottom line is larger audience = more revenue for you when writing the same code. My apologies if you were looking for a selection of either Objective C or C++ without bringing another option to light...
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.