Hi, I just wanted to share some thoughts regarding the event handling and main loop I had about two or even three years ago, but since then never found the time and motivation to realize them. The problem is, the architectural change is very fundamental.
Right now the main loop is in UI::Panel, but should actually be in WlApplication. Another problem is that the button clicks in the main menu are handled through return types. I suggest a design where a new GUI class takes control of the GUI and is independent from the Widelands simulation (just displays results from simmulation). So in the main loop the simulation is run first (which now is the think function in UI::Panel) and then the GUI is drawn. The GUI class is also responsible for keeping a stack of FullscreenMenus to implement the "Back" buttons easily. To switch from the main menu to another menu, the new menu is simply put on top of the stack, when it is removed the element "below" becomes active again. This design also makes loading a game from within another game and a "next campaign" button quite easy: Clear the GUI stack and initialize a new game. No need to code that information in return types, since the single main loop will always run in WLApplication and there are no longer nested main loops like today. I hope I could explain my idea clearly. Of course there are some problems that stopped me from implementing it: - The loading screen: I did not find an easy way to make it compatible with my new design and keeping it responsive/not freezing. My idea was to split the loading process into small tasks using lambda functions and run them in between draw calls. However I had a hard time understanding the loading process. - The modal story dialogs: They stop the game on a very basic level, by running their own main loop. I think it is enough to just set the game speed to 0. - Simulation and presentation are very tightly coupled. The suggested design facilitates and requires a stricter separation. These are the problems I still remember. I had a branch that managed to successfully start the tutorial with this new design, but it was really messy to do all the necessary changes and it is such a central part of the game that I was to afraid to continue. And of course my studies required more attention and I just followed Widelands passively. Maybe now is the time to come back. Best, Matthias On 05.08.2015 17:12, Fòram na Gàidhlig wrote: > I am working on a new branch to handle keypresses. This let me to do > some refactoring on the return codes, to give them all names rather than > using plain numbers. > > At the moment, I have 2 different types of named codes: > > 1. Two const int values in UI::Panel as generic codes (dying_code, > ok_code) [1] > > 2. An enum class in FullscreenMenuBase with Widelands-specific codes > (kTutorial, kSinglePlayer etc.) [2] > > I think we should have one global enum class with all the return codes > in it, and use it as the argument/return type for Panel::run() and > Panel::end_modal(). This way, we could get rid of all plain numbers and > hodgepodge scattered enums permanently via type safety. > > However, we want to keep ui_basic from being Widelands-specific. So, > where is the best way to put them? > > > > [1] > https://bazaar.launchpad.net/~widelands-dev/widelands/bug-1480937/view/head:/src/ui_basic/panel.h#L91 > > [2] > https://bazaar.launchpad.net/~widelands-dev/widelands/bug-1480937/view/head:/src/ui_fsmenu/base.h#L43 > > _______________________________________________ > Mailing list: https://launchpad.net/~widelands-dev > Post to : widelands-dev@lists.launchpad.net > Unsubscribe : https://launchpad.net/~widelands-dev > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~widelands-dev Post to : widelands-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~widelands-dev More help : https://help.launchpad.net/ListHelp
