Slashdot Mirror

← Back to Stories (view on slashdot.org)

Making a GUI for OpenGL Games?

Posted by ryuzaki0 on from the 2d-or-3d-widgets dept.

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

29 of 96 comments (clear)

  1. It's been done by obeythefist · · Score: 2, Informative

    It's been done before: Galactic Civilizations

    --
    I am government man, come from the government. The government has sent me. -- G.I.R.
    1. Re:It's been done by BrookHarty · · Score: 4, Insightful

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

  2. SDL overlays by hitchhacker · · Score: 4, 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

    1. Re:SDL overlays by BrynM · · Score: 3, Interesting
      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
      --
      US Democracy:The best person for the job (among These pre-selected choices...)
  3. Why not use C++ by bsmoor01 · · Score: 5, Interesting

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

    1. Re:Why not use C++ by Gherald · · Score: 2, Informative

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

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

      --
      The unofficial /. digest
    2. Re:Why not use C++ by EzInKy · · Score: 2, Insightful

      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?

      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 mind I find someone has gone and mucked the whole thing up with namespaces and what not. Hell, they even changed the way standard header files are included.

      But anyway, in the end you are right. Use just enough C++ for the gui and encapsulating the units and get on with the business of actually writing the game (this is aimed as much at me who has been spending way too much time writing macros trying to turn C into the great language that C++ used to be).

      --
      Time is what keeps everything from happening all at once.
  4. what you kind of want is GLUI.... by johnjones · · Score: 3, Informative

    see Gui toolkits

    GLUI would be a good one GLUI website

    try it out

    regards

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

    1. Re:what you kind of want is GLUI.... by Xetrov · · Score: 2, Interesting

      From the first line on the GLUI page: "GLUI is a GLUT-based C++..." :)

      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 ;)

    2. Re:what you kind of want is GLUI.... by Xetrov · · Score: 2, Informative

      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.

  5. Develop in a more modern language. by Anonymous Coward · · Score: 4, Informative

    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.

  6. Evaluations of some toolkits supporting OpenGL by jncook · · Score: 5, Informative

    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

    1. Re:Evaluations of some toolkits supporting OpenGL by Cthefuture · · Score: 2, Informative

      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.

      --
      The ratio of people to cake is too big
  7. Invent a new wheel by presearch · · Score: 3, Insightful

    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

    1. Re:Invent a new wheel by Watcher · · Score: 2, Insightful

      Are you in a hurry to get it out? Running out of steam?

      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, and the project usually dies from boredom or lack of momentum. If you're paid to write that code, its one thing, but when its something you're doing in your own (generally limited) spare time, you really just want to write the game you want and not have to worry about all of the boring code until much later.

    2. Re:Invent a new wheel by presearch · · Score: 2, Insightful

      If I'm writing a game (or any application) and I'm footing the cost and time, and I see parts of it as boring to write, or not as part of the unifed whole, it's a clue that I might have a design error.

    3. Re:Invent a new wheel by Watcher · · Score: 2, Insightful

      Or maybe you've just discovered that some sort of code isn't all that interesting to write. Maybe would much rather concentrate on getting your application written than writing the XML parser you need. It sounds to me like you're the type who ends up writing the end all be all libraries to write your application. That's all well and good if the libary is something you're interested in writing, but I've seen more than a few folks who wrote an impressive library to get some dinky little application written, burned out, and never got anything done. Personally, I'd much rather use something off the shelf so I can concentrate on getting the goal of the project done, then go back and write a new library later if the old one just isn't up to scratch. Better to ship something that works than never ship something because you burned out making some dinky part of it function.

  8. GTK + gtkglarea by photon317 · · Score: 3, 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.

    --
    11*43+456^2
  9. Re:Because he prefers to remain blissfully ignoran by doctormetal · · 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.

  10. write your own or use C++ by nickos · · Score: 2, Insightful

    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!

  11. Had a similar problem... by AlXtreme · · Score: 2, Informative
    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.

    --
    This sig is intentionally left blank
  12. Re:Because he prefers to remain blissfully ignoran by gsasha · · Score: 2

    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.

  13. Re:Because he prefers to remain blissfully ignoran by excessive · · Score: 2, Insightful
    Actually, it's hard to find a problem for which plain C would be a better fit
    I'd like to see you suggest that on the Linux kernel mailing list...
  14. Try: irrlicht by tod_miller · · Score: 2, Informative

    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

    --
    #hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
  15. SDL + OpenGL + GUI by ggambett · · Score: 2, Informative

    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
  16. Re:Because he prefers to remain blissfully ignoran by tepples · · 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.

  17. Re:Not on all platforms by tepples · · 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 and retrogamers everywhere.

  18. You might check out blender's sourcecode.... by Zphbeeblbrox · · Score: 3, Informative

    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
  19. GUIs are not easy by UnConeD · · Score: 3, Insightful

    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.