soundmud / soundrts

A real-time strategy audio game
http://jlpo.free.fr/soundrts
Other
44 stars 32 forks source link

the menus shouldn't freeze the game #93

Closed soundmud closed 6 years ago

soundmud commented 6 years ago

The menus and sub-menus tend to have their own event loop. As a result, the rest of the game freezes when the menus are in use. This might require a change in the architecture, hopefully a small one, where the events are dispatched by a common loop to various elements: menu, text console, game, etc. I will try to fix this. Suggestions are welcome. Note: sometimes, it might be useful to pause the game (if there is only one human player, for example).

thgcode commented 6 years ago

I think this could be trivial to implement. You could make an optional parameter on the menu pointing to the game interface and run the interface's mainloop from there (excepting the code that processes the keyboard and mouse). This could revert the https://github.com/thgcode/soundrts/commit/55b43a6ab50f19c5b71ca72eef1a7322d07a0ec9 commit, as it's a cleaner approach and could be implemented in the input_string function. However, this part I will let with you since I had some problems with the voice module in the menu and didn't know how to fix them.

thgcode commented 6 years ago

Or, as you said, make a central loop to handle everything. But in the end the two are very good ideas.

soundmud commented 6 years ago

Or maybe the menus should pause the game (different from the chat). Pausing the game for too long would allow other players to kick the player. So maybe no need to solve this precise issue, after all.

By the way, it's easy (and a bit messy) to call the game_menu method with a check_other_events callback parameter and call back check_other_events from the menu loop. I'll show it in a branch eventually. It's probably very similar to the trivial solution you have described.