Slashdot Mirror
Making a GUI for OpenGL Games?
stuck in a bind asks: "I am currently coding a civilization-type game (in C) but on a galactic scale. OpenGL is used to draw everything so far. However I have been unable to find a decent, nice GUI, practically all of them are coded in C++.
The only other options I can think of is coding my own toolkit (too much work, and I would hate to reinvent the wheel here), using SDL to draw 2D bitmaps on top of my OpenGL window. The last option would be to switch to GTK and use the GTK GL widget. What would the educated gamer/programmers of Slashdot recommend?"
I mean, it's kinda old, and really in need of a re-vamp, but it's still a classic. If you're willing to put up with the way it seems to work around all of its inadequacies.
It's been done before: Galactic Civilizations
I am government man, come from the government. The government has sent me. -- G.I.R.
using SDL to draw 2D bitmaps on top of my OpenGL window.
don't use SDL's method for blitting SDL_Surface's over OpenGL.. it's too slow.
do your 2D with OpenGL (textured polys).
-metric
OO is pretty much ideal for GUI programming. So why not code up your GUI in C++ and leave the rest of your game in C?
Is there some reason you're opposed to C++?
see Gui toolkits
GLUI would be a good one GLUI website
try it out
regards
John Jones
--
http://www.johnjones.me.uk/
What would the educated gamer/programmers of Slashdot recommend?
Choose one:
(1) Switch to C++. Problem solved. Nobody in their right mind (outside of tiny platforms such as the Gameboy and certain icky parts of the Playstation 2) is still writing games in straight C. C++ does a much better job of encapsulation and maintaining a clear codebase - particularly if you expect the codebase to be worked on by more than one person.
Besides, UI programming is a pain in the ass without object-orientated encapsulation.
(2) If you're amazingly stubborn and still don't want to modernize your codebase, you can still use C++ without C++ features (you can ignore language features like classes, for example). This will let you use the C++ toolkits that you want.
(3) Write your own. If you really have the incentive and dedication to write a game, you should be able to write a UI toolkit for it.
Can you write the GUI in C++, or just utilize an existing GUI written in C++? I can't see any problem linking your C code with someone else's C++ stuff.
yiesh, kids these days.
I know that what you want is a C-based UI toolkit that can render widgets in OpenGL. I recently had to research this, and my impression is that you're stuck. As others have suggested, you might consider switching to a C++ compiler and just linking in your C code. You'll be hard pressed to find an advanced UI toolkit that isn't based in C++. Object orientation just matches user interface coding too well.
i tepapers.html
Here's the results of my search. This was for an application which had a very large number of Windows-like UI elements, but had to be able to render a 3D world using OpenGL.
FLTK -- Unsuitable. LGPL. Can open GL windows. Uses direct calls to OS line-drawing routines, so could be adapted to render directly to GL. Reasonable number of widgets, but ugly. No skin support. Development slow (two check-ins in last month).
wxWidgets(aka wxWindows) -- Good. LGPL. Can open GL windows.Used by Mitch Kapor's Chandler PIM project. Would require separate UI thread not to block. Requires awkward preprocessor macros in UI classes. Third-party graphical widget layout tools.
GLOW -- Unsuitable. Renders to GL. Not actively maintained. Uses advanced C++ (STL, RTTI). Clean code. No access to OS features, based on GLUT. Very simple, ugly widgets. Small library of widgets
Qt -- Very good. Commercial license. Can open GL windows. Included graphical UI layout tools. XML-based UI files, but compiled into code rather than loaded at runtime.
GLUI -- Unsuitable. LGPL. Renders to GL. Not actively maintained. Simplistic C++ code. No access to OS features, based on GLUT. Very simple, ugly widgets. Small library of widgets.
XPToolkit(aka Mozilla/XUL) -- Unsuitable. Tri-license MPL/LGPL/GPL. No GL support. Would need to ship Mozilla or Firefox as part of app. Excellent ideas for XML-based UI layout, though.
Full-custom with XML library -- Good. Renders to GL. Easiest for migration. Could do in-game UI editing, both for default skin, user skins, and script UI controls. Probably more work for you.
Also, if you're new to UI library development, I strongly suggest you read the Qt whitepapers. Their concept of signals and slots seems quite powerful (though I have not used it myself).
Qt 3.3 whitepaper:
http://www.trolltech.com/products/wh
James
Why doesn't he look at the blender source code? Their GUI is done using OpenGL.
If you're taking the time and effort to write "a galactic scale civilization-type" game that's written well enough that it's worth the time for others to play, why not go all the way and do the GUI from scratch too?
Are you in a hurry to get it out? Running out of steam? Face it. Odds are it's largely an academic exercise and your game isn't going to be the next Unreal super-hit anyway , so why go the extra mile and innovate instead of imitate? If it does turn out to be a super hit, wouldn't it be best to hand-craft a quality game from the ground up?
Besides, If you were really clever you've got most of the hard part already done in the game components,
so perhaps you can use the game engine itself, and it's active elements, to build the GUI as well and come up with something that's totally new.
--
Looking for short term neural disruption? Play tranquility
Liberals call everyone Nazis yet they are the closest thing to it.
That would be your easiest route. It's all C, it's a decent toolkit, it's fairly portable, etc...
If it were me, I'd explore that first - but if that didn't work out right (say you want odd shaping of how the GUI overlays the GL stuff), then I'd switch to rendering the GUI into textures and letting OpenGL put the GUI on the screen. Just about anything (GTK or what-have-you) can be made to render to a bitmap in memory which serves as the texture for an OpenGL polygon that's placed where it needs to be for the GUI to look right.
11*43+456^2
I suspect he's one of the hordes of (mostly C) coders who believe that using a C++ library requires you to write your entire application in C++.
Then again, if he's writing in straight C these days, I suspect that learning new and inconvenient facts might not be what he's looking for right now.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
I made an opengl C program for my computer graphics 2 class called opengl building blocks. It's a really simple program where you make 3 models consisting of 24 bit colored evenly sized cubes.
I used gtkglext. Pretty much I write the opengl app. Then I write the gtk gui. I make a drawing area widget and use gtkglext to put the opengl app in the drawing area. It's a beautiful thing.
Then if I want people to interact with the drawing area I can register gtk callback functions with any events on it. voila.
Also there is glut, but it is very simplistic. There is a slightly better thing called glutui or some such I forget. It is slightly better than glut with more gui elements. gtkglext I prefer because I get the full gtk2 library right there.
The GeekNights podcast is going strong. Listen!
He could use evas, and edje.
Even then, C is probably one of the worst languages to write a game in (except maybe assembler). If you are using C because you are too lazy to learn C++, you're in for a world of pain. It's possible to do OOP in C -- it's just a horrible, horrible pain in the ass.
Seriously, people, read one of Bruce Eckel's books or something. They are available for free on his website and they are the the best programming books I have seen so far.
I suspect he's one of the hordes of (mostly C) coders who believe that using a C++ library requires you to write your entire application in C++
In most cases you have to. Rather impossible to call C++ classes from plain C, unless you make a wrapper around them.
Then again, if he's writing in straight C these days, I suspect that learning new and inconvenient facts might not be what he's looking for right now.
What wrong with plain c? OO languages aren't suitable for everything.
If I was in your shoes, I would think carefully about exactly what GUI elements you want to use. Most likely you'll find you only really need a small subset of the ones that you'd find in a full toolkit (maybe buttons, menus, text fields and comboboxes/dropdowns). If you insist on using C (and I guess you do), you'll probably find that you can code these in quite an efficient way (because your code won't have to be as flexible as code used in a full toolkit). A basic "toolkit" designed especially for your game isn't as much work or as hard as you think.
On the other hand you could just bite the bullet and use C++. Personally I really like C++, but it took me a long time to lose the prejudice I had towards it.
Good luck!
I did find one written in C however: Agar. It's also being actively developed, so might be worth a shot.
This sig is intentionally left blank
OO languages aren't suitable for everything.
Right. But they are frigging darn good for GUI programming, and that's the problem in question.
Actually, it's hard to find a problem for which plain C would be a better fit, since you can always stick with the C subset of the language. Except maybe when a C++ compiler is not available.
has a zlib[?] licence, no obligations really, and you can redist for commercial use.
l
Has a full UI set of things.[buttons sliders]
Yep written in C++ but can use DX 8.1, 9.0, OpenGL1.2 and somethign else, and software.
And has skeletal animated or quake 2 style meshes. and loads quake 3 maps, objs or 3ds, jpgs and even psd.
Scenegraph and special effects you can turn on [water, fire etc]
http://irrlicht.sourceforge.net/screenshots.htm
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
You can call C++ code just from from what is essentially C code, except for these calls. While that technically makes it C++ code, it doesn't require specific changes to existing C code except where you choose to use you C++ library.
C++ and C mix just fine. If a programmer afraid to call C++ code from mostly C code without a wrapper for some reason of language purity, I suspect that the problem is with that programmer and not the languages, which work just fine together.
The ultimate plays for Madden 2006
Is moving from c to Java an option? I know that Java supports OpenGL as part of its graphic packages.
You did, however, say you needed c. Anyone out here is slash-space have any opinions of writing games in Java?
There is basically no reason to not use C++ these days, sure ABI compatibilty can be worse than C's and there are a few other minor compability issues, but hardly any of them matter for game programming. So pick a good C++ book (ie. Acceleraled C++) and learn the language, there is really no reason to avoid it, especially when the alternative is plain C.
About the GUI, I would recomment to write your own. Games after all often need some special properties (zoomability, transparency, pie-menus, WiW) that some normal GUI can't match or only if you write almost all of your widgets yourself. Writing your own GUI will save you the time to workaround the limitations of some premade GUI, especially since the benefits of a premade GUI toolkit won't be of much use for a game (no need for uniform look and such).
Last not least, if you really want to go C and a premade GUI toolkit, you could go for GTK+ and GtkGLArea (or however that OpenGL widget is called) and then just run your game in the GL widget which is surrounded by normal GTK+ GUI elements. Sure it won't look as pretty as native OpenGL stuff, but it might be the easiest alternative, see FreeCiv for example which does this (well, beside it doesn't use OpenGL).
You can call C++ code just from from what is essentially C code, except for these calls. While that technically makes it C++ code, it doesn't require specific changes to existing C code except where you choose to use you C++ library.
That is only true if you compile your C code with a C++ compiler, otherwise you will get in a lot of trouble (name mangling, class constructors/destructors that are not being called, etc).
C++ and C mix just fine
Only if you pass them both through the same compiler.
Write your own, in C++. It's easier than it sounds if you design the controls correctly. I wrote the UI for our games (see Betty's Beer Bar for an example) and it didn't take too much time. It's not OpenGL but the idea is the same, only the drawing part changes.
As for OpenGL, keep it generic - you can hook a SDL window and Direct3D (I submitted a mini howto but I think Sam never included it, check the mailing list archives), so a good idea may be to create or use an abstraction library that can use either OpenGL or Direct3D. Since Direct3D 8+ is almost a copy of OpenGL, writting one is also easier than it sounds. And if your license is compatible, there's a simple wrapper in the Doomsday Engine project.
Of course, you can always use a 3D engine which already includes a GUI (we are currently using OGRE) and which solves the OpenGL/D3D/Whatever abstraction.
Good luck!
My website
It seems to have disapeared off the net, but there was a project on lisdl.org called SymphonieNG Link This project was basically a tracker using SDL & OpenGL which used a 2D OpenGL GUI. AND it was written in standard C. Maybe it is cached somewhere, but I can't find it at present. It was also linked on opengl.org
Of cource it is bothering job when you invent wheel that already exist.
But it is better. Fast. Smaller code. And it makes your code *SIMPLER*.
You don't have to learn GUI developer's coding style.
I also doing my GUI job on my own using OpenGL Ortho + GL_RECT + Textures.
It didn't took that long time. Almost 2 weeks passed and I managed to make the GUI controls that is very simple button, text, editing area, list control for the long text, combobox for the my 3D modeler and popup style menu...
Every control shares most part of their elements so you don't need any hard job to make new component, just a simple modification you get new one. I use C++ so just one inherit I get new one.
And you can and will use this codes all over the game. Because game need not only windows style GUI that is hard to manage with GUI library.
Well what I wanted talk about is.. it doesn't take that long time and it worth it. Just make your own.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Yes, but what about non-systems programming?
There: Something at a specific location.
Their: Owned by someone.
Please make sure your english compiles.
Even then, C is probably one of the worst languages to write a game in (except maybe assembler).
Not always. For example this situation: Your boss has given you an 8-bit microcontroller clocked at 1.8 MHz, a video controller, and a video game design. Implement the game engine. Will you choose anything but assembly language on an 8-bit CPU, especially when you have to fit video memory updates into vertical blank time?
> C++ and C mix just fine
Only if you pass them both through the same compiler.
And what popular platform with OpenGL doesn't have a decent C++ compiler?
Game programming has more in common with systems programming than some may think. In fact, I come from environments where all game programmers also must be systems programmers, namely Apple II, NES, MS-DOS, and Game Boy Advance.
Years ago, I wrote a flight sim type application using Embedded Tk (in C) and OpenGL. Tcl was very handy to build a decent GUI very rapidly.
It's UI is completely done in opengl and the library (Ghost) hasn't been mentioned. The blender developers wrote it when Glut didn't quite fit the bill for them.
Blender
If you see spelling or grammatical errors don't blame me. I tried to preview but IE here at work borked the CSS
OS X, freebsd, netbsd, and solaris just that I know of. Gcc is barely a capable C compiler, nevermind C++.
Amen! The correct way is of course to write the engine in somethign fast C/C++ then design the GAME in something easy like lua or python. Thats how its been since the begining of time.
Religion is a gateway psychosis. -- Dave Foley
If you want something quick you can always use Tk alongside ToGL http://togl.sourceforge.net/...
You basically write your GUI in Tcl/Tk and use ToGL for the OpenGL rendering window...
If Minix was good enough for Linus then Minix would have been what Linux was(and is). It wasn't.
I'd strong recommend against making your own UI toolkit. Many programmers seem to have the idea that anything involving GUIs is easy, because it's designed for 'stupid users'. Not so.
...
UI's are complex beasts that need to be fast, consistent, flexible and powerful. 'Designing' a UI is not about making pretty skins for the buttons, but defining the behaviour and actions in the UI so that they form a harmonious whole.
Take for example, the 'simple' scrollbar. It consists of 4 areas to click on: the up/down arrows, the thumb to drag around and the gray area outside of the thumb which you can click to go up/down a page. The thumb's length should represent the visible portion of the document/item. If the view shows 75% of the item, then the thumb should cover 75% of the scroll 'gutter'. When viewing a list of lines or items, scrolling should stop as soon as the last item has appeared at the bottom. The granularity of the scrollbar should match the contents that are being scrolled (don't make a smooth scrolling bar if the contents only skip up/down line per line).
Nearly every Flash brochure site and computer game out there which implements its own widgets violate at least one of these rules for scrollbars. Think about all those tiny little implicit rules about buttons, checkboxes, menus,
If all you want to do is make a GUI, then by all means, code one. If you want to make a game, find a good, existing toolkit and use it.
Macintosh System 6 Toolkit Applications
... and other technologies which are twenty years obsolete....
IBM CGA Games with PC Speaker audio
Mouseless User Interfaces
You may want to just go for the Torque engine that Tribes2 and on uses. It's not free but it's full featured and well reviewed.
Bad management trumps ideology - Show the world you want better leadership. http://www.timefornewmanagement.com
They might not be preferable, but that's not the same as suitable.
C++ is an OOL. You have the option of using OOP, it's not mandatory. With minor changes to things like your includes and namespace declarations, it doesn't take too much work to get an old C program to compile with a C++ compiler.
-You can cry, but you'll still die. There'll be no tears in the end.