widelands-dev team mailing list archive

[Matthias Horne <infomh@xxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~widelands-dev
> More help   : https://help.launchpad.net/ListHelp
>