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?"

Comments

It's been done

[obeythefist]

It's been done before: Galactic Civilizations

SDL overlays

[hitchhacker]

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

what you kind of want is GLUI....

[johnjones]

see Gui toolkits

GLUI would be a good one GLUI website

try it out

regards

John Jones
--
http://www.johnjones.me.uk/

Re:what you kind of want is GLUI....

[Xetrov]

Of course you probably want some text/fonts too. The easiest way is to use a texture font (eg an image with all the characters on it), but I found that using freetype2 was also pretty easy and the results are fantastic (blended true-type fonts, mmmmm).

I think the freetype2 dist has an example openGL application in it, otherwise I'm sure something is available via google.

Develop in a more modern language.

[Anonymous Coward]

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.

Evaluations of some toolkits supporting OpenGL

[jncook]

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.

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/whi tepapers.html

James

Re:Evaluations of some toolkits supporting OpenGL

[Cthefuture]

I think if you have ever made a wxWidgets application then you wouldn't call it "good".

It would be easier to just write separate GUI's for each platform and #ifdef all the code as needed.

That's what wxWidgets code looks like anyway. Ugh, too many special cases, not all the widgets work the same way depending on platform (with more or less features and different behaviours; it's a nightmare). It it's fat, really fat, too many layers.

Qt is by far the best cross-platform kit out there but insanely expensive (compared to other non-cross commercial kits like MSDN or something).

Gtk would be next in line but it tends to be buggy and coding GUI's in C sucks. There is Gtkmm but that just adds an extra layer that makes the bugs ever harder to find. Plus it's not really very cross-platform. On MacOS it runs under X11 and on Windows it's buggy as hell and slow. It's probably at or near the top feature-wise as far as free toolkits go. Unfortunately.

Fltk is hyperlightweight and the code is very tweakable allowing you to make it look like whatever you want. That does take extra work though. Like I said, it's very easy to hack on. I like it for simple projects or projects where you're creating a custom GUI. It works on the main 3 platforms flawlessly.

And don't forget the FOX toolkit. It's sorta like a free Qt clone but it mostly sucks (limited Mac support and it's ugly as sin).

In the end Qt wins if you can afford it.

Re:Why not use C++

[Gherald]

> Do you need a good reason to be opposed to C++?

Most emphatically YES when the universe of discourse is game programming!

GTK + gtkglarea

[photon317]

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.

Had a similar problem...

[AlXtreme]

this list contains both toolkits for OpenGL and others, but you're right: C OpenGL UI toolkits aren't very common. PUI, GLUI, GLOW, the more well-known OpenGL TKs are all C++.

I did find one written in C however: Agar. It's also being actively developed, so might be worth a shot.

Try: irrlicht

[tod_miller]

has a zlib[?] licence, no obligations really, and you can redist for commercial use.

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

SDL + OpenGL + GUI

[ggambett]

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!

I think it isn't that hard to build your own..

[FractalPenguin]

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 might check out blender's sourcecode....

[Zphbeeblbrox]

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