Regular readers of my blog may be aware of the complicated history of the GUI backend in DwarvesH. Right now I am using a mishmash of regular Irrlicht widgets and widgets from my own custom lightweight GUI system created specially for the game.
Such a system is not going to cut it for release, and I removed all references to Irrlicht GUI code. The entire game now uses my own custom set of widgets. These widgets only rely on Irrlicht for drawing primitives and reading the user input, so it is very easy to port it to any toolkit under any platform.
Changelog:
- Irrlicht no longer used for GUI.
- Custom GUI system received a focus handling system. It is very rudimentary, but it does the job it has to well. Testing will iron out bugs and maybe I will expand upon it a little.
- A fairly competent keyboard event handling system is in place to send key codes to widgets. It is slightly held down by the subpar focus system implementation in cases where key presses must be sent to the currently focused control
- ListBox new custom widget, replacing the Irrlicht one. It handles item operations and responds to keyboard and mouse events. Does not have a scrollbar yet.
- Dropdown combobox Irrlicht widget removed and it will not be replaced with an equivalent custom widget. I evaluated my GUI and right now I do not need this widget. I was using the Irrlicht one simply because it was available, not because it was needed. The layout for some windows was adjusted, replacing dropdowns with listboxes.
- Rudimentary EditField custom widget added, replacing Irrlicht one. It is rudimentary because it does not yet handle the plethora of keyboard commands it should and does not support copy and paste.
- All widget classes now have proper final names. Custom and Irrlicht widgets names sometimes clashed, so I had classes like Label and Label2. Now there is only one set of widgets and names no longer end in "2".
- Mystery bug updates. DwarvesH has a special run flag that allows you to skip all world setup and dive directly into a random generated map. This is what I use for testing. Surely you do not believe that I click though N windows before I can dive into the game, do you? This flag is almost always turned on for me. But when I turn it off, the main menu is displayed and I can create a custom world. I noticed that when running the game with the flag off, once I get to my map, there is a steep FPS drop (around 100). Some resource must remain active during these menus that is a real performance bottleneck. I repeatedly failed to find the bug. Now, with the new GUI system the bug seems to have disappeared by itself. The map renders at the same speed with both setting of the flag. On the other and, I am experiencing a flat 20 FPS drop in both modes. I must investigate further. Something is still fishy around here.
- INI file has new field for bits per pixel and vertical sync. The Irrlicht documentation claims that it can ignore the vertical sync flag silently. And so it does. Maybe it respects the flag only in fullscreen mode. Or maybe I must buy it flowers first. Take it out to a nice dinner. More investigation is required. Bits per pixel seems to be respected, not way to truly tell.
- Removed the awkward top level control "activation".
- Classed associated to top level windows no longer have a widget member variable to host all children widgets. These classes inherit now from the TopWindow class.
Except for that strange bug and Irrlicht not doing what I tell it to, I am very happy with the way the GUI code is progressing. The code is much cleaner now that only one widgets system is in place. It still needs a lot of time to mature, but by version 0.3 I'm sure it will suit my needs perfectly. That is if I do not change the widgeting system! Again!
I'll leave you with a single screenshot of the GUI without Irrlicht. Notice the look of the widgets and the layout, not the generally outdated content of the window that has not been updated wit the new design for the game (but will be during theis pre-alpha phase):
I like it, just one suggestion. To help with the immersion of the game, could you see if you could add different textures to the GUI. One that would have brown stone back ground, Steel buttons, or something else like that. Maybe even have it scripted so users can define different textures for there preferred game layout. It might be a little post alpha idea, but it could add a lot more crispness and finished look to the game.
ReplyDeleteBTW, loven this game so far.
I actually added background images to panels only (a steel texture) a couple of hours before you added your comment. You will see it in the next post. It is only phase one of adding a new look for panels. I had concept art of the way I want panels to look for months now. The reason you don't see it in game is that someone is working very slowly. Not me.
ReplyDeleteRight now I have no plans to have scripted GUI skins. This is something you add after the game is ready. But the GUI textures are PNG files that can be edited by the user. As long as you do not change the size and layout of the textures, you can create your own custom "skin" by simply editing the correct textures.
well this looks different :)
ReplyDeletegood job with the clean-up.