A bad case of the jitters

[nhmllr]

So usually during gameplay, through every run of the game loop I draw loads of new stuff onto the screen
However, I just implemented a pause feature
It’s exactly what you expect: press “P”, the screen darkens, and it says “Game Paused”. Press “P” again and the game play resumes. Nothing special.
All I did was encapsulate the rendering/updating block in an “if(paused){…}” and make a basic method to update whether “paused” should be true or not. You get the idea

Now, here’s the weird part. I only draw the pause screen ONCE, when the game is initially paused, not every step. It seems like a bit of a waste to draw the same thing over and over again when it’s not changing.

The drawing works, but the screen jitters a lot. What I mean is that, if the player character is moving while “P” is pressed, through the darkened screen you can see the game world jolt back and forth very quickly.
Also, the “pause screen” (which is the darkened screen and the text) flickers on and off very quickly.

Now, why should this happen? I’m 100% sure that there’s no rendering code that escaped the “if(paused){…}” and I only draw the paused screen ONCE (when the played initially hits “P”)

So why is this happening? Is this a peculiarity of OpenGL? How can it be fixed?

Thanks

[Riven]

There are two buffers in OpenGL: the one that is displayed and the one that you draw into.

When you stop drawing into the ‘draw buffer’, and you call Display.update(), you keep switching between which buffer is visible. One of your buffers is darkened, the other shows the last buffer that you rendered your ‘game’ into.

To fix it: either make sure both buffers are black or stop calling Display.update() when you pause the game.

[Sickan]

@Riven

There are two buffers in OpenGL: the one that is displayed and the one that you draw into.

When you stop drawing into the ‘draw buffer’, and you call Display.update(), you keep switching between which buffer is visible. One of your buffers is darkened, the other shows the last buffer that you rendered your ‘game’ into.

To fix it: either make sure both buffers are black or stop calling Display.update() when you pause the game.

You would probably have to call Display.processMessages() instead to keep it responding to things like closing the window.

[nhmllr]

@Riven

There are two buffers in OpenGL: the one that is displayed and the one that you draw into.

When you stop drawing into the ‘draw buffer’, and you call Display.update(), you keep switching between which buffer is visible. One of your buffers is darkened, the other shows the last buffer that you rendered your ‘game’ into.

To fix it: either make sure both buffers are black or stop calling Display.update() when you pause the game.

Right, but here’s the thing: the “if(paused){…}” contains both the regular rendering code and the regular updating code (as in updating the positions of objects and what not). It seemed like I was killing two birds with one stone.

(Also, when I say I “darken” the screen, I do this: I have a 1x1 sprite of a translucent black pixel, and I draw it over the regular display such that it covers everything. It’s nothing special)

Now, you say that I should make sure both buffers are black, but how can I manipulate the buffer that I’m not using?

Thanks

[sproingie]

It’s pretty much SOP in OpenGL to just always re-draw the current frame. I doubt a static pause screen is going to chew up much CPU, but if you’re really concerned about it, render to a FBO then refresh that using a lower framerate like 5fps.

[Sickan]

@nhmllr

@Riven

There are two buffers in OpenGL: the one that is displayed and the one that you draw into.

When you stop drawing into the ‘draw buffer’, and you call Display.update(), you keep switching between which buffer is visible. One of your buffers is darkened, the other shows the last buffer that you rendered your ‘game’ into.

To fix it: either make sure both buffers are black or stop calling Display.update() when you pause the game.

(Also, when I say I “darken” the screen, I do this: I have a 1x1 sprite of a translucent black pixel, and I draw it over the regular display such that it covers everything. It’s nothing special)
Thanks

Why don’t you just set the GL color and draw a rectf over the whole display?

[Riven]

@sproingie

It’s pretty much SOP in OpenGL to just always re-draw the current frame. I doubt a static pause screen is going to chew up much CPU, but if you’re really concerned about it, render to a FBO then refresh that using a lower framerate like 5fps.

Newbie walks in, is advised to use FBOs and is never seen again

[nhmllr]

@Riven

@sproingie

It’s pretty much SOP in OpenGL to just always re-draw the current frame. I doubt a static pause screen is going to chew up much CPU, but if you’re really concerned about it, render to a FBO then refresh that using a lower framerate like 5fps.

Newbie walks in, is advised to use FBOs and is never seen again

yeah… This is my first Java game and it’s mostly so I can learn the language. Also, I think the way I’m doing it should work.
The other thing about my “draw once” method is that it simplifies a lot of code for a different problem: textboxes. I left that out in my initial post because it seemed extraneous, but I have the same problem for when I draw rpg-esque textboxes (and want the game to stop). So for the sake of my sanity, I’m going to ignore FBOs for now but keep them tucked in the back of my head. Thanks, though

NOW: I was looking at the Display API and I found the “swapBuffer()” method, so I’m gonna see if I can make this all work using that and come back here later with a progress report

(As to why I’m doing the 1 pixel over the screen approach, I was planning on doing something more elegant later once I get this up and running)

[nhmllr]

Okay cool. I read the API more and figured out that what you guys suggested was the best (put Display.update() into the block and call Display.processMessages() otherwise)

It works!

Thanks to everybody!