Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
New menu system
11-05-2005, 03:01 AM
Post: #1
New menu system
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...
Visit this user's website Find all posts by this user
Quote this message in a reply
11-05-2005, 05:20 PM
Post: #2
New menu system
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
Find all posts by this user
Quote this message in a reply
11-05-2005, 07:53 PM
Post: #3
New menu system
Your list sounds good to me... and I agree with gianni, too....
Find all posts by this user
Quote this message in a reply
11-07-2005, 10:08 AM
Post: #4
New menu system
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>
Visit this user's website Find all posts by this user
Quote this message in a reply
11-07-2005, 10:30 AM
Post: #5
New menu system
sounds good, although the signals bit isn't necessary
Find all posts by this user
Quote this message in a reply
11-07-2005, 01:33 PM
Post: #6
New menu system
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.
Visit this user's website Find all posts by this user
Quote this message in a reply
11-07-2005, 02:09 PM
Post: #7
New menu system
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.
Visit this user's website Find all posts by this user
Quote this message in a reply
11-07-2005, 02:33 PM
Post: #8
New menu system
Quote: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
Find all posts by this user
Quote this message in a reply
11-07-2005, 03:10 PM
Post: #9
New menu system
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.
Visit this user's website Find all posts by this user
Quote this message in a reply
11-07-2005, 03:10 PM
Post: #10
New menu system
I think implementing a full GUI system like that is too much work for a game so we could look to implemented systemsIn order to view links, you must have to reply to this thread.
Find all posts by this user
Quote this message in a reply
11-07-2005, 03:23 PM
Post: #11
New menu system
There is a In order to view links, you must have to reply to this thread..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.
Visit this user's website Find all posts by this user
Quote this message in a reply
11-07-2005, 10:56 PM
Post: #12
New menu system
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.
Find all posts by this user
Quote this message in a reply
11-08-2005, 10:30 AM
Post: #13
New menu system
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...
Visit this user's website Find all posts by this user
Quote this message in a reply
11-28-2005, 01:26 PM
Post: #14
New menu system
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). Smile
Visit this user's website Find all posts by this user
Quote this message in a reply
11-28-2005, 07:24 PM
Post: #15
New menu system
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).
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)