Slick Forums

This might useful. How about adding setters/getters for pausing the update/render call on the StateBasedGame. The Pre- and Post-Calls will not be changed. So the developer can "pause" the game for debugging or menus better.

If no one is against it, I will implement it and push the change.

_________________
Current Projects:
Mr. Hat I
Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!

Would this only apply to the current state? It wouldn't allow us to start/stop a different state to have 2 states running at the same time, right?

I fail to see how this would be helpful, but if it isn't difficult to implement and you see a possible use for it, I say go for it. Just make sure the update() and render() methods can be paused separately.

_________________
My indie games: http://cmagames.webs.com

That was what I was going to do (seperate pause for update and render).

Here are some useful use-cases:

• open debug panel. debug panel runs over the game and the game still updates it entites so when you press a key it will update the game what you don't want
• pause the game for genrel menus. A lot of games have a menu which pops up on ESC for exiting the game and so on
• using pre/post calls to make update the way you want. Currently update/render are final. you can't override them (maybe we just make them public only again this would be okay too). But if you could, you can manage updating an rendering to states more easily. (You can do this right now to by using the post update method to call anoter states update)

It just makes mor sense to just stop the current state from updating then using the container pause method. which pauses all.

_________________
Current Projects:
Mr. Hat I
Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!

But this feature is rather useless for games that just don't need something like this or that would die due a freezed updated loop.

It would be a better option in my opinion to implement this as additional GameState implementation.

PausableGameState or something like this. Just to avoid cluttering the implementations of Slick with features that are just used in some cases.

Nitram

_________________
http://illarion.org

That may be true but I also never use Tiled and think of it as a rather useless thing Of course not all people need this, but those you want to completly ignore updating and rendering a state. Making into GameState or abstracting it means three things which imho are not so good:

1. You need a cast to check if the state is a PausableGameState and the set it to true.
2. This will only pause the state, not all states. It about having a global property.
3. A PausableGame itself needs checks if should be updated.

Again it's about pausing a state. If you just want that make a boolean in your state for instance. It's about being able to ingore the actual game for a minute. This is extremly helpful for debugging just making a genrel stop. It's not so easy to implement it on your own. Since Kev thought it would be a good idea to make update and render BOTH final in StateBasedGame.

I hope you understand what I mean :/

_________________
Current Projects:
Mr. Hat I
Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!

You never use Tiled, neither do I and I still hope its thrown out of the slick-core at some point

I don't want to talk down your proposal, I am just thinking about the best way to implement it.

In my opinion that would be a "Pausable" interface that defines the functions required to control the pause states (pause/unpause/setPause/isPaused/what_ever_else). This one then can be implemented in the BasicGameState and maybe in a upcomming Pauseable game? To get a nice abstraction level and a clean way to implement any sort of pauseable "systems". I expect this to become handy if you need to pause additional systems once the game/gamestate is paused. Like a pathfinding/particlesystem (that could run threaded).

Nitram

_________________
http://illarion.org

Will yay, We could just mak an interface and add to the GameState and StateBasedGame. I think this is a good idea. It's also more flexible. The thing is how to we difference between pausing update/render?

I suggest the following Interface:


We can also use setter and getter. What do you think?

_________________
Current Projects:
Mr. Hat I
Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!

I would not add the interface in any case to "GameState" or "StateBasedGame". But to the Basic- implementations of these two classes. So the main implementations remain "clean".

If you want you could add additional interfaces, liks PausableGameState and PausableStateBasedGame that merge the Pauseable interface and the GameState or the StateBasedGame interface.

To the Pauseable interface I would just set the methods:
void pause();
void unpause();
void setPaused(boolean);
bool isPaused();

This way the interface can be used extremly flexible. And after all you can't pause the render loop of a application. OpenGL images are volatile, if you stop to render them you get artifacts most likely. But with the freeze of the update loop the image that is rendered should remain the same again and again.

Nitram

_________________
http://illarion.org

Yay of course, stopping the render would lead to... nothing... a black screen xD (if you clear every frame that is). The thing is, you can't just make "PauseableStateBasedGame". As said. Kev makde the methods final.

I think we should removes this. Slick should be useable and making a method final in that case was not a good choice since making your own StateBasedGame class is basically copying code. Also the Transitions rely on the StateBasedGame class Mabye here a Interface to pass would be better too...

Well anyway, so we make a Interface Pausable with the methods you mentioned, and I would suggest, adding them directly to the current StateBasedGame, in the end it's really just a boolean and I don't want to copy the code just for one boolean... And of course removing the final from the init/update and render method. So the Developer can override them?

_________________
Current Projects:
Mr. Hat I
Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!

I was for some reason under the impression that the StateBasedGame is... a interface. Guess I was wrong there. This renders my idea for the state based game void of cause.

So as you said I suggest you change the StatedBasedGame so it implements the Pauseable interface.

As implementation detail I suggest a final implementation for the functions pause() and unpause() that does nothing but calling setPause(boolean) with true or false. This way its clear what function needs to be overwritten in order to add additional things to the default behavior of the pause stuff.

EDIT:
The init and update being final is in general a good idea. Because a StateBasedGame is really nothing but a relay to the current state forwarding all calls to this state. Looking from this perspective you could even implement the whole pauseable stuff as final, as the only thing done by setting the paused flag will be that its state is forwarded to the current GameState. And at this point the developer can overwrite what ever is wanted. There is no real need to overwrite the functions of the StateBasedGame itself.

Nitram

_________________
http://illarion.org

Consider the many different ways a user may want to implement "pausing":

• User wants to stop all updating/rendering when paused, and simply display PAUSED until the game is unpaused
• User wants to stop all updating/rendering to the current state when paused; yet other states (Menu, Help, About) are still active
• User wants to block all input (except the pause key) but let render/update continue
• User wants to block all rendering but let update continue (not as common)
• User wants to switch states on pause
• User wants to switch states on pause but continue updating the other state behind the scenes
• etc.

Will the new changes make it easier for users to implement whatever pausing mechanism they choose? Or will it tie them to a particular genre/style? Is it something better suited for an extension?

Hard to judge without seeing any code at this point. I guess the big question is how will the end user implement it?

So okay, my idea is this:

Make an Interface like this:

So render really should be paused too. Actually is the art of trolling if we would tell teh dev: "Hey man, you can pause update but not render, but SLick2D is very flexible".

Both the GameState class and the StateBasedGame implement this Interface. So to stop a game state, one just gets it by ID and pauses it. And he can also global pause all state updating/rendering by using the StateBasedGame methods. So the user has full controll ofver what to stop. And also making uodate and render at least not final. It's simply not good design because we force the dev to to use our transition system and our way to treat states. This is very static and the only way out is to copy all the code from StateBasedGame into your own code.
I also suggest not making the pause methods final. final is nice to say: "Yay, I'm pretty sure that this can be final since no one ever will have a better idea then me". But that's not us. Slick2D should be flexible in that manner.

If the user can switch states while pausing... this is a good question. Of course not hard to implement but it's a good idea. So one state is paused and we switch to another keeping the old one paused, then return to that state. Much like a Menu <-> Gameplay Thingi.

Question is. Has anybody an idea how we implement this into the Gamestate? Currently update and render are both abstract. My idea is to check that in the StateBasedGame. if it's paused. don't call the states update/render method.

_________________
Current Projects:
Mr. Hat I
Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!

My problems with the pauseUpdate() and pauseRender() is that is reduces the flexibility of the Pausable interface a lot. There are parts that could use this interface, where there isn't such a thing as a render loop and a update loop.

My problem with freezing the render loop is that the image that is rendered is volatile. Means if its not constantly updated the graphic card/OS is allowed at any time to throw parts of it or the entire image away leaving either artifacts or a black screen behind. That happens especially in cases if the drawing area is resized or in case its part of a window that gets minimized. Also a hibernation cycle usually damages this image.

For the state based game. I really don't see this class as more then a relay to the states. This class itself shouldn't stall the update and render loop at all. It just calls the functions of the current state as usual. But it has to ensure that every state is informed of the current paused-state.
Means the StateBasedGame maintains the current state of the paused flag and forwards it upon change of the pause state and upon change of the current game state to the active game state. The gamestate itself is at liberty then to do what ever is needed with the paused information. This way you get the maximal flexibility as you can do what ever you like with the paused information inside your states.

Nitram

_________________
http://illarion.org

We are talking about pausing the gameloop here. And this gameloop has always a update and a render call. Always. So it does not reduce any flexibility, at least I can't see it... What else do you want to pause? if it's just something you would do in your game, then I think you should recondisder the word flexible. We have an Interface which allows the user stop rendering and updating by will, how can this reduce flexibilty...?

Also there no "artifacts" at all. Threre must be something wrong with your render loop it thats the case. I just tested it with PBuffer, FBO and der normal Framebuffer. If I ignore rendering the screen just blacks out. If I enable it, it renders everything normal. How could this get wrong? update does only define how something should be rendererd and, render renders.... nothing more. A also did not clear the screen and the effect was obvious... it was the last valid stuff drawn to the framebuffer.

No StateBasedGame hase explicit methods for NOT ONLY forwarding to the states. This is the great idea of it. YOu have pre/post-update/render methods with which you can work. These enable:

• Post-Proccessing by binding the Buffer in preRender.
• Enable overlay for postRender
• Enable self controlled update stuff. (I use a GameDelta class which can modify the delta for slow down effect and then pass these into the game state)
• bla bla you get my point

This is why - as davedes also suggest - the user might want to stop ALL updating or rendering. Again this does not reduce flexibilty at all. If I would just do it like you suggest, we lose flexibilty. Since to stop all updating in a valid way we need to iterate over all states an pause them. Which is... well stupid, since we already have our nice StateBasedGame where we could control this (Also States are in a HashMap without type, so it would also be slow to iterate over all states compared to just flip a bool).
If we take the possibilty, we are trolling the user. Think of it. The user sees the method pauseUpdate() and thinks :"Nice I can stop all updating for states and check debugging or whatever", but it just forwards this to the current state. This ist noch flexible at all, sorry.

_________________
Current Projects:
Mr. Hat I
Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!

If you clear the screen at every frame then sure. You just get a black screen.

But still I fail to see the reason why you need to freeze both separably. If you want the current state to do... nothing. Why don't you just switch to another state. I can't see the difference.

Nitram

_________________
http://illarion.org