Yeah Awesomium is pretty cool, but it's basically just embedding chromium in your game, and you're using it to render HTML/etc to bitmaps in RAM, which you can then copy into textures. A good general solution, but very bloated for simple HUDs.

At the moment, I'm using librocket, which is kind of similar, in that it's kind of based on HTML and CSS, but plugs into your engine's renderer directly (or D3D/GL directly).

since the gui of a game should really reflect the look and feel of a game, i've always created custom gui components for each title. granted, they're all off the same code base and work the same way, but each uses the sprite and text primitives in the graphics library to do a custom front end.

a gui library with user defined bitmaps for the front end wouldn't be too hard to code up. just combine a hotspot/action area lib, with a gui lib backend, and calls to draw sprites. of course, its a lot easier when you have all that stuff already sitting on your hard drive, or you've written one so many times you could do it in your sleep (and sometimes do - ever code so much you dream about code?).

i remember back in the day when i was first addressing this issue. i guess i take my little collection of GUI components so for granted i don't even notice it. once i have the artwork, i can cobble together the GUI for and entire game in a day.

see that's the thing, once you reach that critical mass of code in your developer's toolkit, all of a sudden everything becomes easy (well, easier...) cause a lot of it is just combine this thing with that to make a new thing, and you already have all the parts.

using my in-house libs i could probably have a lib like that posted in 24 hours. and that's even taking the time to write the hotspot manager.

i've been using in-house stuff pretty much since day one, as there WERE no 3rd party libs when i started (before directx even!). i actually used to sell my in-house libs, but haven't since the dawn of the days of watcom C. recently i've been contemplating releasing them for free. i figure more user feedback will help improve the design, so i get better libraries to work with, and so do the users, a win-win. only possible since i use them for games, and no longer as end products themselves. They were originally sold as a way to further monetize the company's codebase assets. But the demand for StarTrek and Caveman sims far outweighs the demand for low level C++ game libraries.

is it really that bad out there? embedded web parsers? yuk! just thinking of the inefficiency makes my skin crawl!

Thanks dilyan_rusev, I found that one recently, but forgot what it was called! I've been meaning to evaluate it against Rocket.

Ok,but happens when you actually want to show something over the actual rendering of the game?

With Rocket and Scaleform (and I assume it's the same with Coherent), you're in complete control of when and how different 'documents' are rendered. You can draw them to your backbuffer right after drawing your scene, or draw them to a texture that is then displayed on an object in the world, etc...

Unlike Awesomium, they render documents by making GL/D3D calls (or calls to your own renderer), so rendering happens on the GPU, and you can control it.

is it really that bad out there? embedded web parsers? yuk! just thinking of the inefficiency makes my skin crawl!

Awesomium is a almost an embedded version of the Chrome web browser, Coherent is similar, Rocket is based around HTML/CSS but from scratch (and has no JavaScript support).
The Goliath of the genre is Scaleform, which started out as a fork of an open-source Flash player! Plenty of big AAA games have UI's that are basically running on Flash!

Why would someone choose such an inefficient solution?
Because the GUI usually isn't a bottleneck -- if you're spending 10ms on AI and 1ms on GUI, then optimising the GUI down to 0.5ms doesn't really affect your frame times at all anyway.
Also, people who work in UI-land for a living are very likely to be extremely proficient with HTML/CSS and Flash. These tools are industry standards for them. Instead of having to use some half-baked NIH system, they can use the same content generation tools that everyone else in the UX industry is using.
You're sacrificing negligible performance in order to gain a better workflow, and "free" tools (as in Adobe has teams developing them, so you don't need to make your own UI editors).

once i have the artwork, i can cobble together the GUI for an entire game in a day.

You should get a job in games UI then -- people get paid $80k over the course of an entire year to make just part of a game's GUI

i've discovered the you can do most game GUIs with just a few components: a popup menu, a string entry dialog, and maybe a text file viewer. beyond that, everything else is usually custom display screens or custom interaction screens.

for example in Caveman, the 3d rpg/sim i'm working on right now, it has a popup menu that doubles as a message box - a menu with a title (the message), and one option: ok

the popup menu can also be used for large multi-line messages. you just make the title and each option a line in the message, then make the last option "ok". the menu only goes away if they click the "ok" option. a text file viewer is used for 20 lines of text or more. there are custom screens for: stats, skills, and inventory. the "trade" screen is about the only custom interaction screen. everything else is done with menu() and getstring(). the code for menu and getstring are generic except for the drawing of the dialog background and the text. for each game, i copy - paste - edit a new version with new background and font drawing code. now THERE's a component i should see if i could make more generic. once again, its would be easy if it used the rest of the in-house library for fonts and sprites and such.

the menu uses a menu string "object" which is generic. it has "methods" like newmenu(title_string) and addmenu(option_string) then the "boilerplate" code with the game specific sprite and font code uses the menu "object" to draw the menu and handle the pick and return a value (the number of the option clicked: 1 thru whatever).

getstring is "boilerplate" code, with game specific sprite and font code. it just displays a prompt and lets the user enter a string.

viewfile() is generic boilerplate code with game specific background and font code. nothing fancy, just a screen that displays a text file, you can scroll up and down, and select done/close.

all custom screens are done with drawsprite, txt, getmouse and isin. isin(x,y,a,b,c,d) returns 1 if x,y is in the area a,b to c,d. handy for checking results from getmouse to see if the user clicked on a "hotspot" on a custom GUI screen.

You should get a job in games UI then -- people get paid $80k over the course of an entire year to make just part of a game's GUI

and they're STILL buggy and slow? <g> (just kidding).

believe i or not, i passed on a 400K a year slot i could have landed at CGDC96. it would have meant relocating, and my S.O. at the time had a promising career here in D.C. although it was probably 10x what she was making at the time, I didn't even tell her about it. Ironic thing, we spit up two years later, by which time she was making over 60K a year. double ironic thing: the next year i made $198K in the market all in long term capital gains, while still doing the indie gamedev thing full time (overtime actually - such is life as a sole proprietor).