Interesting. It's riveting how simple ideas don't come to mind sometimes. It could surely help with code duplication, if something had to be executed regardless of stack position. I do think it's at the expense of a little bit of clarity, but I think it's worth it.pgimeno wrote: ↑Thu Jun 06, 2019 1:19 amI've now taken a look at other similar libraries. Yours is the only one I see that has separate event handlers while running in the background, which seems interesting. However, I wonder if it wouldn't be better calling the same callbacks but letting them know whether they're on the background or not, and passing back whether the event was handled.
That was one of my main concerns while writing this. I wanted to be able to have each menu as a gamestate (changed the name BTW ) and also to be able to pause without hassle. Ultimately I decided update, input and draw had to be controlled separately. At first I was also obliging gamestates to be objects (with a .new function), but later I realized that meant whenever a menu opened a new object had to be created. Instead, now you can save a menu gamestate in a variable and just push it in the stack whenever you want, pretty much without cost.pgimeno wrote: ↑Thu Jun 06, 2019 1:19 amI don't like the idea of having the game screen stacked on top of the menu screen; I don't think the menu has to be preserved as if it was "paused" while you are playing and "resumed" when you finish. Also, if setting a pause state doesn't call the draw method of the previous stack, handling anything but a full-screen pause is going to be more complicated than adding the pause as another state in the current stack.
I'll definitely look into implementing your suggestion, if you have any more of them nice ideas I appreciate it