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

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

Re:SDL overlays

[BrynM]

As a level designer and player - not a gaming coder, I vote for textured polygons as well for a few reasons:

• You can avoid changing between 2D and 3D and the resolution pop/time delay for some configurations.
• The same artists that create your entities and environments can create your GUI widgets giving the game a consistant look and feel. A good example of this can be found in Primal Software's I of the Dragon tech demo (read their news for the demo download).
• You can probably leverage some of your existing code instead of building something from complete scratch
• An idea... Work a menu editor into your level editor

Why not use C++

[bsmoor01]

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

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/

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

Invent a new wheel

[presearch]

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

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.

Re:It's been done

[BrookHarty]

Why is it someone wants to design a game, its "Been done".. Maybe he has new ideas. Let the guy try. What would of happened if Linus said "Well, Minix is good enough for me"....

Exactly...

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

GUIs are not easy

[UnConeD]

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.