Doyou guys use any GUI library ? or do u hardcode it urself ?

[yanuart]

Hi, I come to the stage in game development which I loath the most.. GUI Programming !!!
yes.. making gui is soo not fun, so I wonder if there's a good GUI library that'll work on DX platform (no.. I don't want the DX gui) which is robust and powerfull enough ?

ps : I've looked the net and find CEGUI, but the building process is so frustating I almost give up and here I am trying to look for another.

[Bad Sector]

I prefer to hard-code it myself... but then again i like writing GUIs :-)

For my tools, i use BSGUI, an SDL/OpenGL-based GUI library i'm writing (and made it open source under the MIT license, so anyone can grab the code and use it as (s)he desire). Here is a shot of the latest release.

For the game itself, since it doesn't rely on OpenGL, i can't use that. Currently in my framework there are only the basics. I'm leaving it for the end, since it's one of those things i've done many times and can do in a single night. Also it won't be as advanced as BSGUI - it'll only contain some basic controls such as text, images, inputboxes, buttons and sliders - no windows, no scrollers, no clipping stuff, no tranparency, etc.

[ErikH2000]

I made my own after a brief stint researching SDL/ParaGUI. I think there is usually one of two problems with GUI/widget packages when writing games with them. Either they do way more than you need and contain a corresponding amount of unwanted complexity, or they do so little that you'll say "I could write this in one weekend!" and roll your own (but actually take 20 weekends ).

What do you need to do? I would say write it yourself if you need simple stuff like showing some text and buttons on the screen. If you needed a bunch of widgets, (i.e. combo boxes, list boxes, spinners, etc.), scrollable widget-containing areas, multiple windows... then you may want to look at GUI libs.

-Erik

[yanuart]

i'm trying my best to incorporate buttons only in my game but there's a need to use textbox to submit online highscore.
I was wondering is it wise to make an application to submit online highscore which is separated from the game.

[soniCron]

I was wondering is it wise to make an application to submit online highscore which is separated from the game.

No.

[msg too short]

[Kai Backman]

I used CEGUI at one point, which is a really great toolkit. But for my purposes it turned out to be complex in the wrong places. In the end I'm using a custom library. Here are my experiences on the subject:

- I found that I needed the most control in regards to the interaction itself, how to handle mouse presses, keypresses and such. This part is totally custom.
- I also needed pixel precise graphics, but I didn't want to write the rasterizers myself. So I'm using AntiGrain for rendering the graphics into a RGBA memory block on the CPU and then blitting the whole block to the graphics card (I bit like most 2D games handle their graphics). I also use Freetype combined with AntiGrain for the font rendering.

I disagree that you need to use a ouside toolkit when the UI grows more complex. I know several projects that happily use CEGUI or similar for the UI, and if your UI is simple enough it can work nicely. But if you have a complex UI you mostly need to write it yourself. Look at MS Word as an example, they have a custom GUI toolkit (not the standard Windows one) ..

[PeterM]

I've also not yet found a toolkit that works like I want.

It seems many GUI toolkit writers are trying to emulate a windowing environment, whereas I just want text, buttons with fancy rollovers, text input and the occasional list box. All in a fixed place, not inside a pretend window. Like a game, not an OS!

I also want to write the renderer part to fit my codebase. If the library could ask me to load the images and so on, tell me where to draw them, that would be swell.

[mwtb]

I'm not sure I follow what the problem is. Most gui libraries will share characteristics with the desktop gui libraries because they solve common problems. There's nothing peculiarly "OS" about windowing or event-driven interfaces and there's nothing stopping you having one screen-sized window filled with hard-coded widgets in the libs I'm aware of.

Perhaps you're being blinded to the ability to do the simple things you want because of the inherent ability to do much more?

[soniCron]

I'm not sure I follow what the problem is.

I think his problem is that most GUI libraries include window management functions and the like. I think he just wants buttons, text, maybe checkboxes. For that, I can't blame him. I'd rather spend 20 minutes learning a quick GUI library than learning the intricacies of a 19MB codebase. Of course, in that case, writing a small custom library wouldn't be too hard.

[NuriumGames]

I've been looking for one recently, and http://guichan.sourceforge.net/ seems fine but is an early beta. Haven't used it yet, but tested it and is very simple. It does what IMHO a game gui should do, not more nor less.

Has graphics support for SDL, Allegro and OpenGL and can be easily (very easily) adapted to other renderers.

It seems many GUI toolkit writers are trying to emulate a windowing environment, whereas I just want text, buttons with fancy rollovers, text input and the occasional list box. All in a fixed place, not inside a pretend window. Like a game, not an OS!

I also want to write the renderer part to fit my codebase. If the library could ask me to load the images and so on, tell me where to draw them, that would be swell.

Well, GuiChan is for you PeterM as this is what it does. Also you can put the controls in a window or in a fixed place.

[PeterM]

There's nothing peculiarly "OS" about windowing or event-driven interfaces and there's nothing stopping you having one screen-sized window filled with hard-coded widgets in the libs I'm aware of.

Perhaps you're being blinded to the ability to do the simple things you want because of the inherent ability to do much more?

Probably :-)

In the end I just rolled my own, and like others suggest, it just took a few hours. It will probably take a bit longer still though, since I've yet to add the fancy effects for polish.

[PeterM]

Well, GuiChan is for you PeterM as this is what it does. Also you can put the controls in a window or in a fixed place.

Wow, it does indeed look just like what I need! I had a browse through the API, and it's really clean and nice.

Thank you indeed! Guess I missed that one when I Googled last time.

[Gnatinator]

I use my own special brew of gui classes for my buttons and scrollbars.

Although this Guichan looks really nice and clean. I gotta check it out.

[ManuelFLara]

I'm using the PopCap Framework for my next game and it includes a very good GUI system with some widgets. I've added some more and support to more complex things like making the system data-driven, defining the widgets and their styles through XML files.

[Robert Cummings]

I found the popcap gui stuff unbelievably confusing and pointlessly convoluted, so I dumped it. I just didn't understand the damn thing.

[PeterM]

I think that's because it's not been refactored as often as it should have been. I got the impression that open-sourcing it was definitely an afterthought, which is fair enough - their main aim is to make money.

[Musenik]

I've posted a Python minimalist GUI (based on PyGame) at my website. The next version of Faces-n-Features will have better documentation, but it's very clean. One example program show's it's simplicity. The other show's what can be done with it. An earlier version was used to create The Witch's Yarn. The idea behind it was to supply basic tools and functionality without constraining a design.

[ErikH2000]

Some musings that aren't terribly directed...

It is really hard to convince a game programmer to use a GUI lib. The nature of these libs is that as they do GUI tasks the "right way" they must become an entire framework for programming inside of. So instead of functions like:

DrawButton(BUTTON *pButton);
IsMouseOverButton(int x, int y, BUTTON pButton);

...you get framework-style functions like:

RegisterButton(BUTTON *pButton);
OnMouseOverCallback(WIDGET *pWidget, int x, int y);

As a GUI lib author, when you start making your lib do more things, the first thing you want to get control of and abstract away from the lib user is the input collection. I.e. instead of relying on the lib user to collect the input and call functions to do things like change input focus or animate mouseover states, you want to grab the input and do all that stuff yourself by default.

As a GUI lib user, it can be maddening to lose control of these things and be forced to learn new ways to fit into the framework. So more often than not, people dump the GUI lib and write their own. Game programmers, especially, who indulge their ego whims more often than say database application programmers. If they have to fit into a framework, then it might as well be their own.

I wrote the most beautiful GUI framework (an internal proprietary thing for another company), documented to the max, handholding my users, updating it in response to feedback. Bleh. All I heard was "oh, it's too complicated. I'm just going to write my own thing that is exactly the same as what you wrote, but better because I wrote it."

-Erik

[mwtb]

Having written one or two GUI systems myself and used several UI libraries, I still feel there's something being missed when people look at large UI libs and don't see the basic render context, widgets and events structures there to be used. When I had a quick look at GuiChan the class heirarchy looked like most windowing UIs, just with fewer subclasses. It's not really simpler, just smaller and less fully featured -- which is fine, of course.

The first time I wrote a UI, I started from a highly procedural "I just want something simple" standpoint. It didn't take long to realise that the approach was brittle and difficult to modify. Then I wrote an event-driven UI with pseudo-objects in C, and other people complained that it was too complicated pretty much off the bat even though it was fairly small. I've seen at least three attempts by people to rewrite windowing style UI libraries with the intention to produce something "simple" and every time they've ended up with something that was essentially equivalent, just not standard (and mostly broken in one way or another).

It takes more than a few minutes with an average UI library to work out how it ticks, sure, but once you get one, it doesn't generally take long to figure out another, and simple things generally are simple to achieve once you get past the lack of familiarity.

[James C. Smith]

Doyou guys use any GUI library ? or do u hardcode it urself ?

I rolled my own many years ago. If you just need a few basic thinks like a clickable button and maybe some text input then you should be very easy. Assuming you already have the ability the read mouse input and draw bitmaps on the screen, you should be able to write simple classes like this in 4 hours or less. I prefer this over importing and learning someone else’s elaborate GUI system. Just roll your own. It's easy.

However, if you know you will need many type of widgets and support for things like feign languages and interactive layout tools then I would not reinvent the wheel for all that stuff. In this case, it would be worth using an open source GUI library.

But for most game it should be sample to roll your own custom solutions that fits your game and your framework well.

By the way, I don't understand your use of the word "hardcode" in this context.

[ErikH2000]

The first time I wrote a UI, I started from a highly procedural "I just want something simple" standpoint. It didn't take long to realise that the approach was brittle and difficult to modify.

YES! That is just how it worked with me too on my first GUI project.

Then I wrote an event-driven UI with pseudo-objects in C, and other people complained that it was too complicated pretty much off the bat even though it was fairly small.

I see this "anti-complexity" attitude too often. It doesn't matter how well you think out and present your design--it it takes more than a few hours to get, developers with short attention spans start making noises like you overengineered it. Seeing this happen as an author, it's made me really reluctant to criticize something somebody else wrote for being too complicated. This is just the first kneejerk reaction a developer has when looking at someone else's unfamiliar code. There are also many solutions to problems that, technically speaking, are more complex than they need to be, but far better choices for long-term maintenance.

There was this Australian dude named Mike that would always make this noise like he was a huge genius and he had all these weird libraries of his that he took with him from project to project and advocated. And then I actually talked to him and looked at his libraries in-depth, and it turned out he really was a huge genius and his libraries were worth figuring out and reusing. But everywhere he went, there was this constant idiot noise about how his stuff was too complicated and only Mike could understand it. Programmers are just lazy.

I've seen at least three attempts by people to rewrite windowing style UI libraries with the intention to produce something "simple" and every time they've ended up with something that was essentially equivalent, just not standard (and mostly broken in one way or another).

Yep, yep, yep. I hear you.

Most developers need more patience and willingness to learn somebody else's code. It's a hugely valuable thing.

-Erik

[vjvj]

I tried about four different gui libs before finally deciding it'd be easier to just roll my own. As has been stated already, the actual framework itself isn't hard at all to write.

However, I did end up using an external lib for font rendering (FTGL). One thing I was dead set on was using freetype fonts in case we end up doing any localization or porting. I'm not sure if I'll be shipping with FTGL yet, but integration was pretty darn painless and (unlike some of the other libs I tried using) it actually compiled out of the box without any fiddling.

[soniCron]

By the way, I don't understand your use of the word "hardcode" in this context.

My initial impression is that he thinks of programming somewhat like this:

• Get GPL'd libraries.
• "Soder" GPL'd libraries together to make a bigger framework.
• Any actual programming would be "hardcoding".

EDIT: That sounded a little condescending. What I mean to say is, libraries are "chips", the program is the "motherboard", and anything not provided in the function of the "chips" is "hardcoded". A very progressive method of development (though nothing new) I believe.

[Hiro_Antagonist]

I put together my own GUI framework for Land of Legends, and plan on improving it in my future games.

Re-using an existing codebase was basically a non-option for me, because I don't know of any existing .NET GUI framework,s, and even if a good one existed, I would most likely have to change my whole approach to graphics loops, control (mouse/keyboard) handling, etc, in order to accomodate it.

If you're going to write your own (which, frankly, is what I would recommend,) then I suggest you first study them. I think I did a fairly good job, because I'd had lots of exposure to windows/web models, but I would have done even better if I'd read/studied more before I started.

-Hiro_Antagonist

[Pyabo]

i'm trying my best to incorporate buttons only in my game but there's a need to use textbox to submit online highscore.
I was wondering is it wise to make an application to submit online highscore which is separated from the game.

You don't need a textbox for this... Just be creative and think about how arcade games handle it.

[soniCron]

You don't need a textbox for this... Just be creative and think about how arcade games handle it.

That's a little backwards, considering computers have keyboards and all.

[vjvj]

That's a little backwards, considering computers have keyboards and all.

Yep, doing it arcade style would probably be annoying in a PC game... But at the same time it's probably still a good idea to have a backend that doesn't rely on keyboard input just in case a console port becomes a reality for you.

[soniCron]

But at the same time it's probably still a good idea to have a backend that doesn't rely on keyboard input just in case a console port becomes a reality for you.

If that's the case, then only in rare circumstances would you need a GUI library (or to even roll your own). You'd entirely be using buttons.

EDIT: Nah. I'm wrong.

[svero]

We have a really basic one built into our engine which does buttons, and text editing. That handles 99% of what I do. Other stuff like wheels and draw bars etc.. we just code when we need.