Original Post
Where can I find information on ParaGUI besides their site? There seems to be no easy to understand tutorial type information for this :(
🔒 Locked
ParaGUI?
Advertisement
I had some troubles understanding it as well and at the end I decided that I didn't need something as complex as what they provide. All I really needed were just buttons so I created my own system. What do you need for your GUI? I can post some of the code I have if you want it.
Quote:
Original post by Rob Loach
What do you need for your GUI?
Well I suppose I need to design it. I was looking for an easy-to-use GUI that was friendly with SDL but it doesn't look too hopeful. I'm having trouble designing my GUI, what the key elements are, how to handle 'focus', etc. I'm sure I'll get specific questions as I start planning.
Mine is actually pretty badly done (in my opinion). I'm working on an asteroids clone that uses the engine's GUI system for the main menu:
-click to enlarge-
It is kind of run like a state machine. You have your base GUI object class which has properties and methods of every GUI object. From that you have derived classes to be more specific about each object, how it's drawn, how the user interacts with the control, everything like that. When you want to add a GUI object to the class, you make a class and derive it from the desired class object. You then add the object to the current state (I have a function called AddGUIObject() which is part of the state class) and it throws all events from the user to the control if 1) it has focus or 2) it's interaction with the mouse. It turns out to look like this when creating GUI object:
Again, these functions are called from the state machine when it's needed. If you have a state machine up and running, you'll easily understand how to get this system up and running. Actually, I think I'll give you that code. The GUI system I have up is pretty damn big....
Once you have all the states defined, you can then call the SetState function and the engine manages calling all the correct functions and everything. Once you get that state machine up and running, it'll really help when getting that GUI system going.
-click to enlarge-
It is kind of run like a state machine. You have your base GUI object class which has properties and methods of every GUI object. From that you have derived classes to be more specific about each object, how it's drawn, how the user interacts with the control, everything like that. When you want to add a GUI object to the class, you make a class and derive it from the desired class object. You then add the object to the current state (I have a function called AddGUIObject() which is part of the state class) and it throws all events from the user to the control if 1) it has focus or 2) it's interaction with the mouse. It turns out to look like this when creating GUI object:
class MainMenu : public System::GUI::Menu { // The main menu is a GUI menu // To initialize the control void Initialize(){ // Add some items to it AddItem("Start Game"); AddItem("Options"); AddItem("Highscores"); AddItem("Exit"); ItemSpacing(20); // Change look Items.BackColour(180,10,10,170); Items.HoverColour(220,10,10,250); Items.BorderColour(0,0,0,255); Items.TextColour(0,0,0); // Location Width(200); Height(40); x(System::Width/2 - Width()/2); y(50); } // When an item is selected void Select(std::string item){ if(item == "Start Game"){ // Start the game } else if(item == "Options"){ System::SetState(OptionsState); } else if(item == "Highscores"){ System::SetState(HighScoreState); } else if(item == "Exit"){ System::Going = false; // stop the application } }};Again, these functions are called from the state machine when it's needed. If you have a state machine up and running, you'll easily understand how to get this system up and running. Actually, I think I'll give you that code. The GUI system I have up is pretty damn big....
void SetState(State* state); class State{ public: virtual void Enter(){ } virtual void Update(){ } virtual void Draw(){ } virtual void DrawAfterGUI(){ } virtual void KeyDown(int key){ } virtual void KeyUp(int key){ } virtual void MouseButtonDown(int button){ } virtual void MouseButtonUp(int button){ } virtual void MouseMotion(){ } virtual void Exit(){ } virtual void Initialize(){ } bool Initialized(){ return m_initialized; } bool Initialized(bool init){ return m_initialized = init; } protected: bool m_initialized; private: };// Then to use it you have all your different game state:class CMainMenuState : public System::State { public: void Initialize(); void Update(); void Draw(); void DrawAfterGUI();};Once you have all the states defined, you can then call the SetState function and the engine manages calling all the correct functions and everything. Once you get that state machine up and running, it'll really help when getting that GUI system going.
A simple GUI I am creating for my own game uses something close to Robs method but I use a GUI manager class to handle creation of GUI objects and passing events to them. The base gui object class has 2 virtual functions: drawguiobj() and handleevent(). Each derived class like a frame window has it's own version of how it is drawn and is responisble for drawing it's children and handling events meant for it or passing them on to it's children. Right now I only have frame windows, edit boxes (single line), progress bars, and am working on buttons right now.
Something I found to be most helpful in making this not so slow is that the parent objects create their own surface to be rendered to and then render thier children to that surface then that surface is rendered to the screen every frame and is only updated when something changes. This greatly reduces the number of calls to SDL_BlitSurface/frame which while profiling my code is definitely the biggest hog because I easily get a good 10-15 fps boost from doing this instead of redrawing the whole gui window each frame.
Try it yourself, blit a 20x15 tilemap of 32x32 tiles to the screen for a minute and then check out the profile time, then blit that tilemap to an offscreen surface once then just keep blitting the snigle surface to the screen for a minute and see which one produces the better results.
On the obvious side SDL_BlitSurface comes with some overhead so of course calling it more often will be more expensive. On the not so obvious side there is also work being done (although minimal) to offset the next tile being drawn so it shows up in the right place. This is of course a non-practical example because in a scrolling game such that I am making, the map changes so much it actually creates more overhead but in gui situations where things change maybe once per second or even less often then this is a huge time saver.
BTW, I highly recomend the use of SDL_gfx. Took me a few minutes to figure out how to use the command line compiler for vc 6 to create the dll and lib files but it sure is worth it. I use SDL_gfx for the primitives like lines and circles which come in very handy for gui type things.
I hope at least some of that made sense because it is seeming to me I am spending an awful long time getting things right for a "simple" gui which I want to be able to use for in-game editor tools while I am developing it. I am thinking the hardest part will be a scrollable listbox where I can select an object (think open/save/save as file dialog). Good luck :)
Something I found to be most helpful in making this not so slow is that the parent objects create their own surface to be rendered to and then render thier children to that surface then that surface is rendered to the screen every frame and is only updated when something changes. This greatly reduces the number of calls to SDL_BlitSurface/frame which while profiling my code is definitely the biggest hog because I easily get a good 10-15 fps boost from doing this instead of redrawing the whole gui window each frame.
Try it yourself, blit a 20x15 tilemap of 32x32 tiles to the screen for a minute and then check out the profile time, then blit that tilemap to an offscreen surface once then just keep blitting the snigle surface to the screen for a minute and see which one produces the better results.
On the obvious side SDL_BlitSurface comes with some overhead so of course calling it more often will be more expensive. On the not so obvious side there is also work being done (although minimal) to offset the next tile being drawn so it shows up in the right place. This is of course a non-practical example because in a scrolling game such that I am making, the map changes so much it actually creates more overhead but in gui situations where things change maybe once per second or even less often then this is a huge time saver.
BTW, I highly recomend the use of SDL_gfx. Took me a few minutes to figure out how to use the command line compiler for vc 6 to create the dll and lib files but it sure is worth it. I use SDL_gfx for the primitives like lines and circles which come in very handy for gui type things.
I hope at least some of that made sense because it is seeming to me I am spending an awful long time getting things right for a "simple" gui which I want to be able to use for in-game editor tools while I am developing it. I am thinking the hardest part will be a scrollable listbox where I can select an object (think open/save/save as file dialog). Good luck :)
I've used ParaGUI with some reasonable amount of success in a previous project because i needed a rather robust GUI to handle it (a strategy game). I spent the better part of a year tearing that lib apart. The best documentation you'll find is the sample programs that are provided with it in the /test folder. Those help a lot. They are simple enough that they can be dissected. You can also get the regular Doxygen documentation as well, but i think it is for version 1.02 at the latest. Most of it is still usable. You can PM if you need it and there is no newer version. I have it on my HD still.
here's how bad i managed to mangle ParaGUI:
[Hey, those screenshots almost make me want to pick up the project again. They look pretty good :-D ]
here's how bad i managed to mangle ParaGUI:
[Hey, those screenshots almost make me want to pick up the project again. They look pretty good :-D ]
Quote:Memory would be a huge issue with this system. If you store the whole map/GUI in memory, you'll end up with a huge amount of repeated data, some of which you wouldn't be using anyway if the control/tile isn't on the screen. The "overhead" you're talking about offsetting the tile would be a simple multiplication (TileX * TileWidth) and I don't think that would be worth changing to have the large amount of memory required to store copies of information that's already in memory. K.I.S.S. Also, what if your controls are changing appearance rapidly? You're going to have to re-draw the objects anyway.
Original post by evillive2
Something I found to be most helpful in making this not so slow is that the parent objects create their own surface to be rendered to and then render thier children to that surface then that surface is rendered to the screen every frame and is only updated when something changes. This greatly reduces the number of calls to SDL_BlitSurface/frame which while profiling my code is definitely the biggest hog because I easily get a good 10-15 fps boost from doing this instead of redrawing the whole gui window each frame.
Try it yourself, blit a 20x15 tilemap of 32x32 tiles to the screen for a minute and then check out the profile time, then blit that tilemap to an offscreen surface once then just keep blitting the snigle surface to the screen for a minute and see which one produces the better results.
On the obvious side SDL_BlitSurface comes with some overhead so of course calling it more often will be more expensive. On the not so obvious side there is also work being done (although minimal) to offset the next tile being drawn so it shows up in the right place. This is of course a non-practical example because in a scrolling game such that I am making, the map changes so much it actually creates more overhead but in gui situations where things change maybe once per second or even less often then this is a huge time saver.
SDL_gfx is very handy. I've been using it as a base framework for all non-graphic controls. If you're using Dev-C++, I compiled a DevPak for it which is available here.
Quote:Hah, I took a look at it through their website [smile].
Original post by leiavoia
...
I've been working on a GUI system which mirrors the functionality discussed in Mason McCuskey's DirectDraw GUI tutorials one, two, three, and four.
It's heavily integrated with my tile-based RPG engine, but if you would like to take a look at it, you're more than welcome. I'm considering open-sourcing my engine once it's complete, anyways. :)
It's heavily integrated with my tile-based RPG engine, but if you would like to take a look at it, you're more than welcome. I'm considering open-sourcing my engine once it's complete, anyways. :)
Quote:
Original post by Rob Loach
Memory would be a huge issue with this system. If you store the whole map/GUI in memory, you'll end up with a huge amount of repeated data, some of which you wouldn't be using anyway if the control/tile isn't on the screen. The "overhead" you're talking about offsetting the tile would be a simple multiplication (TileX * TileWidth) and I don't think that would be worth changing to have the large amount of memory required to store copies of information that's already in memory. K.I.S.S. Also, what if your controls are changing appearance rapidly? You're going to have to re-draw the objects anyway.
**snip***
Like I said above, the map thing isn't a practical example and i am not sure why I used it to be honest (did you try it?), but the gui parts are not huge memory hogs. I realize I probably didn't explain very well so let me go into it a bit more. Only the top level gui objects contain a new surface. Their children get drawn on that surface using client rects based on the 0,0 of their parent's surface. So far I only have need of 2 relatively small frame windows that handle their own children like textboxes and progress bars but I am sure that will change. Also my gui components don't rapidly update. The most it updates is when I am typing into a textbox which isn't often (and won't eb much in the actual game) and then input focus is handed back to the game when I click back on the game screen.
I am still working on it and I am sure I will come into a lot more snags but I will post some of it in my journal when I get it decent enough to where I won't be mocked too harshly :)
The main point although I didn't stick to it in my original post or here either for that matter was that for plain old SDL (no OpenGL if I read the OP's post right) it is slim pickings to find something with your specific needs and writing your own (unless you absolutely need something as robust as paragui) is basicly what most people end up doing anyway. And besides, there is always the pre-rendered buttons and text label approach :)
Hope I didn't confuse anyone more than necessary...
I have a SDL library that has a built in GUI that you can look at. Comes with an example source and such for creating controls.
http://www.delphisanctuary.com/metacipher/xaero/libraries.php
Works really well. And has a really easy to use Event/Message system. You can see a tutorial for creating a button here:
http://www.delphisanctuary.com/metacipher/xaero/articles.php?CatID=2&ArtID=4&action=View%20Article
Anyway, I hope that helps.
http://www.delphisanctuary.com/metacipher/xaero/libraries.php
Works really well. And has a really easy to use Event/Message system. You can see a tutorial for creating a button here:
http://www.delphisanctuary.com/metacipher/xaero/articles.php?CatID=2&ArtID=4&action=View%20Article
Anyway, I hope that helps.
Quote:
Original post by RhaalI was looking for an easy-to-use GUI that was friendly with SDL but it doesn't look too hopeful.
Perhaps you should try Guichan: http://guichan.sourceforge.net/
I was also searching for an GUI for OpenGL, but the most guis I found were really confusing to use and had too many features, that I didn't need. But Guichan is really nice and, with some tweaking, really fast under OpenGL.
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement