Are there any guides around for how to code a basic UI or menu/window system for a game?
What I have in mind is just something functional like in a shoot 'em up where maybe you'd want a menu to pop up every so often to let the player choose an upgrade or some such. Another thing might be an inventory screen or even how to just implement a main menu properly.
I can think of a few ugly ways that it might be possible by checking mouse coordinates etc. but I don't really have a clue about how to go about doing it in a practical and logical way that allows efficient customization to various different situations.
There must be some good links to stuff like this, but I haven't been able to find anything sufficient yet for a long time. I'd be intending to use it in games made with DirectX if that matters much.
Coding Basic Game UI/Menus
Here's one book that I have in my collection:
DirectX9 User Interfaces - By Alan Thorn
This book basically builds a UI from the ground up using DX9. It's an "old" book, so I am unsure if this author has upgraded his material to include the latest DX releases. Nonetheless, it does give you a working example that you can play with.
OK... Now that the recommendation is out of the way, my main gripe with this book is that it still relies on using the windows message queue. Perhaps this is the way such systems are built, but I'm working on a UI, using some ideas from this book, which doesn't rely on using the message queue.
So, if you're fine incorporating message queues with DirectX then, check this book out. But regardless, it does give useful insights into how a DX driven UI could be implemented.
DirectX9 User Interfaces - By Alan Thorn
This book basically builds a UI from the ground up using DX9. It's an "old" book, so I am unsure if this author has upgraded his material to include the latest DX releases. Nonetheless, it does give you a working example that you can play with.
OK... Now that the recommendation is out of the way, my main gripe with this book is that it still relies on using the windows message queue. Perhaps this is the way such systems are built, but I'm working on a UI, using some ideas from this book, which doesn't rely on using the message queue.
So, if you're fine incorporating message queues with DirectX then, check this book out. But regardless, it does give useful insights into how a DX driven UI could be implemented.
Are you set on implementing it yourself? There's several good GUI libraries out there you could look at that let you just throw in a nice looking menu and get back to making your real game, instead of spending time reinventing the gui wheel for the hundredth time.
Just an option.
Just an option.
I shamelessly copied how the windows message system works for creating buttons and handling click messages and such.
It's intuituve and pretty simple when you strip away all the shite you know you'll never need.
The panels and buttons draw themselves using grey rectangles and the first font that was ever loaded. Unless you overide it and draw your own which of course you will as soon as you get em working.
It's intuituve and pretty simple when you strip away all the shite you know you'll never need.
The panels and buttons draw themselves using grey rectangles and the first font that was ever loaded. Unless you overide it and draw your own which of course you will as soon as you get em working.
Author
Quote:Original post by karwosts
Are you set on implementing it yourself? There's several good GUI libraries out there you could look at that let you just throw in a nice looking menu and get back to making your real game, instead of spending time reinventing the gui wheel for the hundredth time.
No, I wouldn't mind any way that worked.
What are these GUI libraries?
Quote:Original post by CodeStorm
Here's one book that I have in my collection:
DirectX9 User Interfaces - By Alan Thorn
I'll see if I can give that a look then.
Quote:Original post by Rubicon
I shamelessly copied how the windows message system works for creating buttons and handling click messages and such.
It's intuituve and pretty simple when you strip away all the shite you know you'll never need.
The panels and buttons draw themselves using grey rectangles and the first font that was ever loaded. Unless you overide it and draw your own which of course you will as soon as you get em working.
Might have a look at that... sounds like it could be complicated, I never liked the look of Win32 >_>.
How do the grey rectangles work exactly? Is it something like filling a certain coordinate area of the screen with grey depending on the button location? Does it ever use images at all?
Another bump for rolling your own. GUI's are a complex beast, but you learn a lot by working through it, and the topics (trees, picking, event handling) are very usefull in game dev.
I've read the Thorne book, and it's a great resource for the hows of GUI, but as mentioned relies on the windows msg queue, especially WM_PAINT. But with a bit of work you should be able rework it into something more useable. I replaced the drawing code with screen space quads, so i can use a pixel shader to get the look and feel I want, and use the event handling capabilities of my engine to pass input to the gui.
I've read the Thorne book, and it's a great resource for the hows of GUI, but as mentioned relies on the windows msg queue, especially WM_PAINT. But with a bit of work you should be able rework it into something more useable. I replaced the drawing code with screen space quads, so i can use a pixel shader to get the look and feel I want, and use the event handling capabilities of my engine to pass input to the gui.
If you want to use an existing one I would suggest you ClanLib which you can find at http://clanlib.org/wiki/Main_Page.
If you want to roll your own and have something working soon I would suggest you to have a look at the tutorial here: http://sol.gfxile.net/imgui/. It uses the IMGUI pradigm which some people see as a bad design, but it is quite easy to implement and also very easy to use. It is also used by the Unity people (just as a reference).
I was recently also on the verge of adding a GUI to my what-will-become-a-game-someday and decided for the IMGUI approach and I am *very* happy with it so far. I would recommend you to start with it and should you need something else you can still switch to something more complex.
If you want to roll your own and have something working soon I would suggest you to have a look at the tutorial here: http://sol.gfxile.net/imgui/. It uses the IMGUI pradigm which some people see as a bad design, but it is quite easy to implement and also very easy to use. It is also used by the Unity people (just as a reference).
I was recently also on the verge of adding a GUI to my what-will-become-a-game-someday and decided for the IMGUI approach and I am *very* happy with it so far. I would recommend you to start with it and should you need something else you can still switch to something more complex.
I wasn't on about overiding the actual windows system, just writing something like it.
You have functions like "CreatePanel" which a factory class makes and remembers and in fact draws all the panels with a single call to "DrawStuff" as you do your present.
There is also an update function called during present which checks where the mouse is and what control it clicked and sends event messages to a pure virtual function you have to supply to the creator. This gets inputs in a similar way to wndproc but is obviously far more customised to be what you actually want.
Or you could have more virtuals instead of messages, for example there would be a Panel::OnControlClickedIn(Control* TheControl) function. Theres merit in either method. The former is easier to retrofit new stuff into, the latter is generally more OOP like.
Sounds complicated but it's really not. It only took a few days to get the basics right and then you can nibble at it and add controls as you feel the need. And because it doesn't rely on any platform dependences (assuming you have a generic drawrect function for default behaviour) then you can tweak it to exactly how you want it over years and keep on reusing it forever.
Of those couple of days, you'd spend that long getting used to a 3rd party lib that you'd then have little or no direct control over.
You have functions like "CreatePanel" which a factory class makes and remembers and in fact draws all the panels with a single call to "DrawStuff" as you do your present.
There is also an update function called during present which checks where the mouse is and what control it clicked and sends event messages to a pure virtual function you have to supply to the creator. This gets inputs in a similar way to wndproc but is obviously far more customised to be what you actually want.
Or you could have more virtuals instead of messages, for example there would be a Panel::OnControlClickedIn(Control* TheControl) function. Theres merit in either method. The former is easier to retrofit new stuff into, the latter is generally more OOP like.
Sounds complicated but it's really not. It only took a few days to get the basics right and then you can nibble at it and add controls as you feel the need. And because it doesn't rely on any platform dependences (assuming you have a generic drawrect function for default behaviour) then you can tweak it to exactly how you want it over years and keep on reusing it forever.
Of those couple of days, you'd spend that long getting used to a 3rd party lib that you'd then have little or no direct control over.
Author
Quote:Original post by Burnt_Fyr
Another bump for rolling your own. GUI's are a complex beast, but you learn a lot by working through it, and the topics (trees, picking, event handling) are very usefull in game dev.
Quote:Original post by fng
If you want to roll your own and have something working soon I would suggest you to have a look at the tutorial here: http://sol.gfxile.net/imgui/. It uses the IMGUI pradigm which some people see as a bad design, but it is quite easy to implement and also very easy to use. It is also used by the Unity people (just as a reference).
I was recently also on the verge of adding a GUI to my what-will-become-a-game-someday and decided for the IMGUI approach and I am *very* happy with it so far. I would recommend you to start with it and should you need something else you can still switch to something more complex.
Yeah... I might try my hand at making my own. I have some months to get to grips with it for a project for college anyway, so that's always a plus.
Quote:Original post by Rubicon
I wasn't on about overiding the actual windows system, just writing something like it.
Ya, I just meant trying to understand just exactly how Win32 works has always been a bit confusing for me... so reverse engineering might be hard.
Quote:Original post by Rubicon
You have functions like "CreatePanel" which a factory class makes and remembers and in fact draws all the panels with a single call to "DrawStuff" as you do your present.
There is also an update function called during present which checks where the mouse is and what control it clicked and sends event messages to a pure virtual function you have to supply to the creator. This gets inputs in a similar way to wndproc but is obviously far more customised to be what you actually want.
Is that roughly how you did the UI in Great Little War Game?
That looks pretty cool and it's approximately the kind of thing I'm looking to create. A pop-up window to choose unit production and whatnot that would make strategy games and other games with a bit of depth possible.
Quote:Original post by RubiconOf those couple of days, you'd spend that long getting used to a 3rd party lib that you'd then have little or no direct control over.
True, if I could manage it in a similar amount of time, doing it by hand would be a much better option.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
