Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×

Making a GUI for OpenGL Games? 96

Posted by Cliff 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?"
This discussion has been archived. No new comments can be posted.

Making a GUI for OpenGL Games? More

Making a GUI for OpenGL Games?

Comments Filter:

  • It's been done (Score:2, Informative)

    by obeythefist ( 719316 )
    It's been done before: Galactic Civilizations [galciv.com]

  • SDL overlays (Score:5, Informative)

    by hitchhacker ( 122525 ) on Thursday October 14, 2004 @10:25PM (#10531541) Homepage

    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)

      by BrynM ( 217883 ) * on Thursday October 14, 2004 @10:42PM (#10531651) Homepage Journal
      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 [primal-soft.com] 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
      • Not only is it too slow, but it's harder to get to work. It's fine and dandy using SDL to setup everything and encapsulate your OpenGL environment in a neat and platform-independant way, but don't use SDL to blit on top of OpwnGL. I tried this for my senior project, and it was nearly the death of me.
    • do your 2D with OpenGL (textured polys).

      FYI, this is what the Quake series does. It ends up being highly portable.

      -molo
    • Why not create a SDL target for GDK? The bulk of the work is already there (in the directfb target), you just need to implement setup/teardown. This way, you'll have both portability (SDL/OpenGL) and skinnability (GTK themes).

  • Why not use C++ (Score:5, Interesting)

    by bsmoor01 ( 150458 ) <`seth' `at' `beere.org'> on Thursday October 14, 2004 @10:34PM (#10531593)
    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++?


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

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

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

          • True, but a game for an 1.8MHz microcontroller won't be very complex as far as design. Basically, it's programmer time and effort versus computer power. Programmer time is much more expensive for anything except mass-market products. In short, on a today's PC, it's better to program in a higher-level, possibly less efficient language.

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

              • Did he really? I mean, I enjoy those old games BECAUSE they're not very complex as far as design ;-)
              • First, an NES has a relatively powerful graphics processor. So it isn't exactly an 8-bit microcontroller application. 8-bit micros appeared long before the NES. Second, I've yet to see a Doom port or an MMORPG for the NES. Third, none of the homebrew NES stuff is even close to the real capabilities of the NES -- it's more like Atari 2600 games.

                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

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

                • First, an NES has a relatively powerful graphics processor.

                  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.

                  So it isn't exactly an 8-bit microcontroller application. 8-bit micros appeared long before the NES.

                  I seem to recall those micros also using auxiliary chips. Could be wrong here...

                  Second, I've yet to see a Doom po

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

          Amen! The correct way is of course to write the engine in somethign fast


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


          1. DUH. Wrappers are implied here. They can even be automaticlly generated, if the C++ library in question doesn't already provide them.
          2. "Mu." One can use plenty of C++ without using OO... but since the discussion is about GUIs, which are inherently OO, it'd be kinda moot.
          • What wrong with plain c? OO languages aren't suitable for everything.


          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)

      by EzInKy ( 115248 )
      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

  • what you kind of want is GLUI.... (Score:4, Informative)

    by johnjones ( 14274 ) on Thursday October 14, 2004 @10:36PM (#10531608) Homepage Journal
    see Gui toolkits [geocities.com]

    GLUI would be a good one GLUI website [unc.edu]

    try it out

    regards

    John Jones
    --
    http://www.johnjones.me.uk/
    • 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 ;)

      • 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. (Score:4, Informative)

    by Anonymous Coward on Thursday October 14, 2004 @10:37PM (#10531617)
    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.

  • I always just use OpenGL for my TUI, I don't need one of those new-fangled GUI things.

    yiesh, kids these days.

  • Evaluations of some toolkits supporting OpenGL (Score:5, Informative)

    by jncook ( 4617 ) on Thursday October 14, 2004 @11:04PM (#10531798) Homepage
    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
    • 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 expensi
      • "In the end, Qt wins if you can afford it."

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

          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
      • In my experiences with the wxWidgets code, I found it to be actively maintained, even more actively supported, and not rife with #ifdefs.

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

      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)

    by presearch ( 214913 ) on Friday October 15, 2004 @12:13AM (#10532184)
    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 [tqworld.com]

    • Re:Invent a new wheel (Score:3, Insightful)

      by Watcher ( 15643 )
      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
      • 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.

        • Re:Invent a new wheel (Score:3, Insightful)

          by Watcher ( 15643 )
          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

    • GUIs are not easy (Score:3, Insightful)

      by UnConeD ( 576155 )
      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 arr
  • I thought that years ago I read someone ranting about how he started writing a game (FreeCiv, I thought) in C and realized later that without any OOP facilities the project had gotten out of hand and he was debating whether he should rewrite it in C++ so that expanding it and maintaining it would be easier. But when I went to FreeCiv.org to doublecheck my memory I couldn't find any info on it and their compiling requirements only call for C, see?

    Specific compiling requirements

    All:

    1. ANSI C compiler (gcc

  • GTK + gtkglarea (Score:4, Informative)

    by photon317 ( 208409 ) on Friday October 15, 2004 @12:45AM (#10532322)

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

    Als

  • write your own or use C++ (Score:3, Insightful)

    by nickos ( 91443 ) on Friday October 15, 2004 @03:57AM (#10533104)
    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!

  • Had a similar problem... (Score:3, Informative)

    by AlXtreme ( 223728 ) on Friday October 15, 2004 @04:52AM (#10533306) Homepage Journal
    this list [free-soft.org] contains both toolkits for OpenGL and others, but you're right: C OpenGL UI toolkits aren't very common. PUI [sourceforge.net], GLUI [unc.edu], GLOW [sourceforge.net], the more well-known OpenGL TKs are all C++.

    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)

    by tod_miller ( 792541 ) on Friday October 15, 2004 @07:15AM (#10533735) Journal
    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

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

      • As far as I saw - he was writing a graphical component to his 'engine' or whatever he was doing. I just pointed to a resource - he can adapt the code or whatever.

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

  • SDL + OpenGL + GUI (Score:3, Informative)

    by ggambett ( 611421 ) on Friday October 15, 2004 @10:36AM (#10535121) Homepage
    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 [mysterystudio.com] 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 [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!
  • It seems to have disapeared off the net, but there was a project on lisdl.org called SymphonieNG Link [libsdl.org] 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 contro

  • You might check out blender's sourcecode.... (Score:3, Informative)

    by Zphbeeblbrox ( 816582 ) <zaphar@gmail.com> on Sunday October 17, 2004 @11:25PM (#10553819) Homepage
    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 [blender3d.org]
  • Macintosh System 6 Toolkit Applications
    IBM CGA Games with PC Speaker audio
    Mouseless User Interfaces

    ... and other technologies which are twenty years obsolete....
  • DevMaster [devmaster.net] has an engine comparison database [devmaster.net] you should check out. User reviews, prices, features, etc.

    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.

Slashdot Top Deals

Genetics explains why you look like your father, and if you don't, why you should.

Close