Got some scattered questions regarding rolling your own GUI system. I have my own game engine with a renderer and window/input handling in place but no GUI stuff yet.

1. Setting up a window and reading mouse/keyboard input involves win32 api. I know the api is archaic but is it unreasonable to try build GUI controls (buttons, text boxes, menues) ontop of it? Dosn't newer versions of windows ship with some new UI libraries?

2. Checking whether buttons are clicked can simply be done by reading the mouse position to see if it is within area of the button whenever WM_LBUTTONDOWN is posted?

3. How are more complex controls such as drop-down menues implemented?

4. (DX11) What is the best/most flexible way to render text? Say you got a text box. It is easy enough to render the box, but any arbitrary text inside it? What about different sizes/fonts? Word wrap?

5. (DX11) Since GUI is rendered ontop of the ingame-graphics, you could just render directly into the backbuffer after all 3D-rendering has been done?

I'll take a shot at a couple of your questions,

1. Whatever API you feel most comfortable with is the best API to use for GUI creation. Creating a GUI in Win32 can be a bit tiresome due to the age of the API, but everything you posted is well within the scope of the API. I may be mistaken, but most of the GUI libraries on the Windows platform build, and extend on the base functionality provided by Win32.

4. There are a few ways of doing it. You could dedicate a quad per letter, or you could try your hand at vectorized text.

5. How I normally do it is to render it last as you said. But then use a special pass through vertex shader that omits any special world space transformations, and keeps my HUD elements in NDC space. If your talking about GUI elements on monitors, and displays In Game. You may want to look into render to texture.

Marcus Hansen

1) for a game I wouldnt use win32 api for gui elements - especially if you have got a dx renderer

2) it would probably be better to translate the windows input messages away in to some structure than can be polled or a set of callback functions or something similar. Probably the easiest thing would be to make a struct to represent a key - a char to know which key and a bool or int to show if it is pressed or not - and then have an array of these keys that get set every frame based on window messages. In other parts of the game you would just poll in to this array to see if a button is pressed or not. There is actually a pretty decent article on input here on gamedev

http://www.gamedev.net/blog/355/entry-2250186-designing-a-robust-input-handling-system-for-games/

3) a pretty simple way to do drop downs is by using callbacks - your buttons should probably have some kind of callback so they can do something when pressed, you could just create a callback that creates another ui element on top of the button. It would also be a good idea to have a parent/children tree structure within the ui system so that elements can be parents or children of other ui elements.

4) Rendering text using fonts without any libs is not easy. True type fonts store their data in vectorized form which would mean you need to figure out how to read in the format and convert the font to a set of glyphs for rendering for whatever size/style you are trying to render.

Another option is to use a utility like angel codes bitmap font generator to generate a bmp image file from a font, size, and style.

Take a look a freetype if you havent - it can do all the hard stuff for you - you can use it to easily generate a texture atlas for almost any font at a size and use that atlas to render the glyphes.

5) You dont have to do anything special - render the text like any other gui element. You probably would render all gui elements after your geometry as you said that you do.

1) Games don't use the Windows API. Typically they use the rendering engine and a programmer having a basic understanding about how an OS draws things to the screen for it's windows and such. For example, if you're using DirectX, then you'll need to roll your own API, along with the drawing code specifically for Directx.

2) This is pretty easy, but it's not easy if you suck at linear algebra. The computer doesn't know what your screen is. It has absolutely no context about what coordinates are, or when something is in the area of another. That's all dependent on the programmer to add this in. You already got it down on how it's done. Checking if the mouse is within the area of the button. That is saying that you need to do some analytical geometry to see if the mouse's pointer is actually within a button's covered area on the screen.

3) Normally by event calls. The drop down effect is just the effect of an animation during the rendering process.

4) Don't do this one yourself. The basic way can be found on tutorials. For fonts and general GUI use... you'll want a library. Because this is a pain in the ASS to do.

5) Typically you can render it when ever the hell you want as long as it's visible to the viewer. But most games do in fact just render your GUI directly after all the 3D rendering is done. Usually with a second camera set to Orthographic viewspace.

http://www.rastertek.com/tutdx11.html

Sorry about the link not being hyperlink. for some reason the computer at work is blocking me.....

This is a good place to look for DX11 engine stuff. In the list is a section for 2D rendering and font. This is the basics of any GUI.

I'm currently working on my own DX11 GUI, but I have a complete DX9 you can look at if you like.

Some notes for you to think on,

Button presses.

Don't trigger your events on left button down. Trigger them when the state goes from down to up. The reason behind this is simple. Assume your game is running at 60hz. The average player presses the left button for about 200mS. So if all you trigger on is the left button being down, you could potentially send 10 - 15 button press events when you only want one.

Text rendering.

The best way I have found of handling text is signed distance field fonts. You can get away with a lot less font's in memory as they allow you to scale up with great accuracy. I personally don't like scaling fonts down, I can see artifacts when I do that, but scaling up is great and saves a lot of memory, time, etc.

Yes it will take you a bit longer to get text rendering, but it is worth it in the long run.

Complex gui items.

There are no complex gui items. What you are thinking of is actually a collection of simple gui items. Make sure your base design allows for this and you will be fine.