Making a GUI for OpenGL Games? 96
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?"
It's been done (Score:2, Informative)
Re:It's been done (Score:1)
Re:It's been done (Score:2)
Re:It's been done (Score:5, Insightful)
Exactly...
Re:It's been done (Score:1)
Re:It's been done (Score:2)
SDL overlays (Score:5, Informative)
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 (Score:4, Interesting)
Re:SDL overlays (Score:2)
Re:SDL overlays (Score:2)
FYI, this is what the Quake series does. It ends up being highly portable.
-molo
Re:SDL overlays (Score:1)
Why not use C++ (Score:5, Interesting)
Is there some reason you're opposed to C++?
Re:Why not use C++ (Score:3, Informative)
Most emphatically YES when the universe of discourse is game programming!
Re:Why not use C++ (Score:2)
Why?
One of the design criteria of C++ is that you don't pay for what you don't use. If you write in the subset of C++ which is also in C, you get C (modulo some corner cases, like not being able to use "class" as a keyword). Indeed, you can't really get a C compiler these days; they're almost all C++ compilers with an internal command-line switch, or multiple-frontend compilers like GCC.
Re:Why not use C++ (Score:2)
C++ is by far the most common and (it would seem) regarded as the best choice for low level game programming. So if you are OPOSSED to using C++, you'd better have a good reason/explanation.
As for the rest of your post, it's true but doesn't address why someone would be OPOSSED to C++ for game progamming, which is what is so confusing about this story.
Re:Why not use C++ (Score:1)
Because he prefers to remain blissfully ignorant. (Score: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.
Re:Because he prefers to remain blissfully ignoran (Score:2)
Seriously, people, read one of Bruce Eckel [mindview.net]'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.
Not on all platforms (Score:1)
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?
Re:Not on all platforms (Score:2)
Re:Not on all platforms (Score:2, Funny)
but a game for an 1.8MHz microcontroller won't be very complex as far as design.
I'm sure you didn't realize it, but you just insulted NES developers [parodius.com] and retrogamers everywhere.
Re:Not on all platforms (Score:1)
Re:Not on all platforms (Score:2)
I think it just about proves my point -- it's a waste of time for a developer to try to compensate for a slow processor by excessively optimizing code. This mig
Re:Not on all platforms (Score:1)
Second, I've yet to see a Doom port or an MMORPG for the NES.
The "destroy hordes of baddies" theme of Doom was alive and well in Smash TV, an arcade port, as well as many other similar overhead-view shooter games. Remember that even Wolfenstein started out as a 2D game. As for MMORPGs, people weren't willing to tie up phone lines during those years when the NES was commercial.
Re:Not on all platforms (Score:2)
Not to mention a separate memory controller chip, which was located in the game cartridge. You couldn't scroll back the level in Super Mario 1, because the controller didn't support it, but Mario 2+ had a more advanced version.
I seem to recall those micros also using auxiliary chips. Could be wrong here...
Re:Because he prefers to remain blissfully ignoran (Score:2)
Amen! The correct way is of course to write the engine in somethign fast
Re:Because he prefers to remain blissfully ignoran (Score:2, Insightful)
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.
Re:Because he prefers to remain blissfully ignoran (Score:2)
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.
Re:Because he prefers to remain blissfully ignoran (Score:2, Insightful)
Re:Because he prefers to remain blissfully ignoran (Score:1)
Re:Because he prefers to remain blissfully ignoran (Score:2, Insightful)
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.
Re:Because he prefers to remain blissfully ignoran (Score:2)
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.
Re:Because he prefers to remain blissfully ignoran (Score:1)
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.
Re:Because he prefers to remain blissfully ignoran (Score:1)
> 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?
The quick answers are... (Score:2)
Re:Because he prefers to remain blissfully ignoran (Score:2)
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.
Re:Why not use C++ (Score:3, Insightful)
I can't say as I blame guy. Twelve years ago, before I decided to make healthcare my career and relegate programming as a hobby I thought C++ was the greatest thing since sliced bread since it wrapped up both the power of C and object orientation all in one nice tidy little package.
But now just when I've got some time on my hands that I want to devote to creating some programs I've got in
what you kind of want is GLUI.... (Score:4, Informative)
GLUI would be a good one GLUI website [unc.edu]
try it out
regards
John Jones
--
http://www.johnjones.me.uk/
Re:what you kind of want is GLUI.... (Score:2, Interesting)
I didn't like any of the openGL GUI packages out there so I made my own. It really isn't difficult to draw your own textured QUADs etc over the top of the scene. You can push/pop the attributes as well as the projection matrix, so you can make sure lighting etc is turned off when you draw the gui... RTFM
Re:what you kind of want is GLUI.... (Score:2, Informative)
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. (Score:4, Informative)
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.
Does it all have to be in C? (Score:1, Redundant)
Re:Does it all have to be in C?-Blender. (Score:1)
what about OpenGL for the TUI? (Score:2)
yiesh, kids these days.
Re:what about OpenGL for the TUI? (Score:1)
Evaluations of some toolkits supporting OpenGL (Score:5, Informative)
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
Re:Evaluations of some toolkits supporting OpenGL (Score:3, Informative)
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 expensi
Re:Evaluations of some toolkits supporting OpenGL (Score:1)
Don't forget, if your writing your game and releasing it under a GPL compatable licence you may use Qt for Free (beer/speech). GPL doesn't mean you have to give it to everyone, you just need to give the source to whoever you sell it to.
If not, the Qt fees _aren't_ that expensive.
Cheers,
Chris.
Re:Evaluations of some toolkits supporting OpenGL (Score:2)
True but you can't restrict redistribution. That means the first person you sell it to can redistribute to anybody. This effectively nullifies your commercial software. GPL just doesn't work for commercial apps unless all you plan to sell is support.
If not, the Qt fees
Re:Evaluations of some toolkits supporting OpenGL (Score:2)
Okay, but it's better and much faster to develop in than the alternatives, with the exception of Qt. wxWidgets apps come out excellently in Windows, they just generally require some tweaking to make them work well in Linux as well because it's a native widget wrapping library. But it's _because_ it uses native widgets that wxWidgets has become so popular - compare to using something like Swing (ugh).
O
Re:Evaluations of some toolkits supporting OpenGL (Score:2)
There's a separate directory for each target in the tree that contains sensibly named source files like "notebook.cpp" which implement their name.
It is true that wxWidgets does not behave identically on each platform. These issues, where they arise, are often dealt with or documented, but it comes down to this--In the several thousand lines of wxWidgets-using code that I
Re:Evaluations of some toolkits supporting OpenGL (Score:2)
One correction: Qt is a tri-license, GPL/QPL/commercial. It hasn't been purely commercial in years (since around 1998 or so, IIRC).
Invent a new wheel (Score:4, Insightful)
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 [tqworld.com]
Re:Invent a new wheel (Score:3, Insightful)
As a counter point to this: he probably wants to build the game, not the GUI. If he was focused on writing the best darned GL GUI out there, then he wouldn't have asked this question. Most game projects die because they get into writing horrid amounts of generic game code (sound mixers, UIs, cross platform IO, so on) that isn't specific to what they're doing. All that accomplishes is making it a much longer path to get to writing the game they want
Re:Invent a new wheel (Score:3, Insightful)
Re:Invent a new wheel (Score:3, Insightful)
GUIs are not easy (Score:3, Insightful)
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 arr
Ask on the FreeCiv Mailing List (Score:2)
Re:Ask on the FreeCiv Mailing List (Score:2)
GTK + gtkglarea (Score:4, Informative)
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.
gtkglext (Score:1)
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.
Als
write your own or use C++ (Score:3, Insightful)
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!
Had a similar problem... (Score:3, Informative)
I did find one written in C however: Agar [csoft.org]. It's also being actively developed, so might be worth a shot.
Try: irrlicht (Score:3, Informative)
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
Re:Try: irrlicht (Score:1)
Sorry, I don't think this should get modded up. Irrlicht is a "game engine" (Well, mostly a graphics engine). Its not the answer to the question. He would have to redo all his code to fit in the Irrlicht framework.
I was going to say, use CEGUI [sourceforge.net] but it isn't pure C. It is a very actively developed GUI system, with renderers for DirectX, OpenGL, Ogre3D [ogre3d.org] and Irrlicht.
Re:Try: irrlicht (Score:2)
I realise his main reason to make the engine is probably interest and self challenging, but push comes to shove, he has a nice example there.
Soooooooooooo aaaaand why do you care about the status of moderation? perhaps someone else would have found it interesting...
Write your own AND use C++ (Score:2)
About the GUI, I would recomment to write your own. Games after all often need some special properties (zoomability, transparency, pie-menus, WiW) that som
SDL + OpenGL + GUI (Score:3, Informative)
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 [doomsdayhq.com] project.
Of course, you can always use a 3D engine which already includes a GUI (we are currently using OGRE [ogre3d.org]) and which solves the OpenGL/D3D/Whatever abstraction.
Good luck!
Perfect Solution...But (Score:1)
I think it isn't that hard to build your own.. (Score:1, Informative)
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 contro
You might check out blender's sourcecode.... (Score:3, Informative)
Blender [blender3d.org]
Other programming projects you may enjoy: (Score:1)
IBM CGA Games with PC Speaker audio
Mouseless User Interfaces
Check this engine comparison site (Score:2)
You may want to just go for the Torque [devmaster.net] engine that Tribes2 and on uses. It's not free but it's full featured and well reviewed.