New menu system

[thelusiv]

Alright it's time to start discussion the details of the new menu system. I think it should:<ul><li>be navigable by keyboard, mouse or joystick device<li>have reusable widgets<li>options give visual feedback on their status even before selection<li>be easy to read and use<li>be based roughly on the old menu system</ul>Is there anything I'm leaving out? I have started a new branch in SVN under branches/menus-v2/. Ideas welcome...

[gianni]

It would be great to implement slide widgets for setting parameters like sound volume, future weight balance of the car, changing car, display setting resolution, changing parameters for gears (like GT4), etc..Gianni

[joevenzon]

Your list sounds good to me... and I agree with gianni, too....

[thelusiv]

Yes Gianni is thinking along the same lines as me. Here's a few widgets that'd be nice to have:<ul><li>sliders for float values like volume<li>radio buttons<li>check boxes<li>scrollable lists<li>buttons<li>text boxes<li>labels<li>mouseover tooltips</ul>other important elements of a good gui which we need:<ul><li>flexible layout - can be changed by editing a text file (already have this - just must be extended for new features when they're written)<li>widgets should be able to be placed anywhere<li>signals should be used to trigger callback functions on events (button press, mouse cilck, etc.)<li>we should be able to bind a variable in the game to a widget that returns a value without doing any coding</ul>

[joevenzon]

sounds good, although the signals bit isn't necessary

[thelusiv]

If we don't use signals/callbacks, how will we know when to service a particular GUI element? I guess we could do it based on input. But even then, let's say we have a button and we want to see if the mouse has clicked on it. Then we have to go through every single instance of a widget (at least on the current page) to see if that widget is affected by the click (or keypress or whatever). The biggest pain about signals/callbacks is simply that they're not that easy to write, but once you get them figured out, they're very convenient.

[thelusiv]

I thought of something else this new menu system needs to be able to do. It should be able to set a given widget to be enabled or disabled so that certain options can be 'blocked off' when others which conflict with it are selected.

[gianni]

Here's a few widgets that'd be nice to have: * sliders for float values like volume * radio buttons * check boxes * scrollable lists * buttons * text boxes * labels * mouseover tooltips

But do you want implement all? It take a lot of work and time!What about use an existing game engine like Irrlicht (it's very fast, simple to use and made in C/C++).http://irrlicht.sourceforge.net/Gianni

[thelusiv]

Hmmm, well Irrlich does a lot more than just a GUI, it is a full OpenGL toolkit, which would duplicate a lot of the functionality already in VDrift.The trouble with using a library for a GUI is always that it is either very big and tries to take over your application, or that it has a strange license, or that it is not very well written, or doesn't do exactly what you want. Also, a lot of times it is not cross-platform, even if it uses SDL or something many times the authors don't test on many platforms so the code is not really cross platform after all. Thus it takes a lot of effort to use many of the existing SDL based GUI libraries. I have yet to find one that satisfies all my requirements for VDrift in terms of portability, performance, simplicity, and quality.Also, to add yet another thing to the list of things the menu system must be able to do: Dialog boxes, or pop-up windows which contain widgets. These will be mostly for situations where the user's attention needs to be drawn to something.

[Nenillo]

I think implementing a full GUI system like that is too much work for a game so we could look to implemented systemshttp://http://guichan.sourceforge.net/screenshots.shtml

[thelusiv]

There is a huge list of GUI libraries/toolkits here.What I'm thinking about doing, if I can't find one that is simple enough, is simply writing a GUI library that fits VDrift's needs (separate from VDrift itself), and then using that.

[joevenzon]

Callbacks are for situations when you want to be able to (in code) pass a function to be called by someone else's code. In our case, we're writing all of the code anyway, so it's not necessary. I can describe it in more detail over IM if you want.My opinion about using an external GUI library is a big thumbs down. Those GUI libs are often hard enough to set up and use that it takes about the same amount of time to code your own (if you're a fast coder). It just sounds easier to use someone else's code, but I've found it rarely is. Plus, you're adding another dependency, which I think is a big no-no, unless it's really worth it. In our case, the functionality we need from a GUI isn't huge, so we should write our own.

[thelusiv]

I see what you mean about callbacks now, they're not really needed in this situation...and I agree about libraries. Rarely do they do exactly what's needed and easily...

[thelusiv]

I've been working on the new gui classes for a week or so now and things are coming along nicely. All the widgets I planned are done except for TextBox and ListBox. I also added two "wheel" type widgets - these just have a vector of strings which are displayed as options and a vector of strings or floats (thus two types) that holds the values that correspond to each option. On the left of the wheel's option display is a left arrow, on the right a right arrow; these are used to change the option by clicking on them with the mouse or using the left/right arrow keys while this widget is selected.Right now only a few menus (mostly options) are implemented, the positioning of the widgets is a little off because they can't be centered yet, and likewise the areas where each widget can be clicked is a hard-coded box that doesn't always exactly fit the widget (again because i don't know how wide the widgets are). When there's some kind of font.Width and font.Height functions these things will get fixed.Things that still need to be done:<ul><li>make more graphics for widgets (button background, slider wedge and slider cursor, real wheel arrows instead of symbols, new page background graphics)<li>finish implementing all the menus<li>implement joystick support<li>handle mouse wheel events to change widget values<li>add a function which updates the gamestate and other things when one of the OK buttons is pressed (currently only updates settings)<li>add sounds that can be played when widgets are used ("click" when a button is pressed or toggle changed, some kind of more passive sound for widget select)</ul>If you want to help out, you could look around for good free menu sounds or create some of your own original ones, or help write menu definition files. Now that most of the code is complete for the gui the menu files are the biggest time consumer. The format is pretty simple, use the other menus in data/lists/new-menus/ as examples...and don't forget to add any menus you create to data/lists/new-menus/menus and data/lists/new-menus/SConscript (as I have a few times).

[thelusiv]

Just finished adding all the graphics for the widgets that have been implemented so far. They're only halfway through, though. I still have to make the gui handle both key up and down events, as well as mouse button up and down events and change the graphics accordingly (currently the buttons don't change when clicked/selected, they should "sink in" when a key/button is pressed and return to normal when the key/button is released).