When to call clear()

[carton83]

Is it a good idea to call clear() at the start of my gameloop, have the game go through all the logic that updates positions of sprites & what not, and then call draw() & display() at the end?   

I've just been doing clear(), draw(), and then display() all at the end of my loop.  I'm not thinking of changing that, I'm just curious.

[eXpl0it3r]

clear() should be called just before you draw() which should be followed by display().
It's always a good idea to separate rendering und logic, i.e. you have a section where all the inputs and other game logic parts are handled and then you got a section where you draw everything. Whether the order is now logic, draw or draw, logic doesn't really matter that much. I usually go with logic() and then draw(), since to me it makes more sense to first calculate the new positions and then draw, rather than drawing and then calculating the next position.

[carton83]

That's what I thought.  What are possible side effects of having your logic inbetween your clear() call and you draw()/display() calls?

What prompted this question is that while following SuperV1234's Arkanoid tutorial I noticed that they have their clear() call at the top of their game loop and their draw()/display() calls at the bottom.  Admittedly it's a very short loop, but it made me wonder none the less.

[eXpl0it3r]

Forgot double buffering... Nothing to see here... 

I most it doesn't matter much, however if you think about that most/a lot of time is usually spent on the logic part for one frame, calling clear at the beginning will leave the screen empty for the whole logic calculation.

For example (wild guesses) (at 60fps = 16.6ms/frame):
Black - 00ms - clear()
Black - 01ms - input handling
Black - 04ms - physic simulation
Black - 08ms - AI calculations
Black - 12ms - draw()
Black - 15ms - display()
Image - 16ms - end of loop

As you see, you'll end up with only a very short time where the window is actually displaying an image. Since our eyes can't really notice the difference between one quick frame flash per 16ms or a full image over 16ms it's not an issue, however even though we can't really notice the difference it's still possible that our brain/subconscious "sees" one, especially for action packed games.

In essence nobody would probably write:
logic()
draw()
display()
clear()

[AlexAUT]

As you see, you'll end up with only a very short time where the window is actually displaying an image. Since our eyes can't really notice the difference between one quick frame flash per 16ms or a full image over 16ms it's not an issue, however even though we can't really notice the difference it's still possible that our brain/subconscious "sees" one, especially for action packed games.

Ahm what? Calling clear() doesn't clear the current framebuffer of the window (frontbuffer). It only clears the backbuffer, because SFML is using double buffering.
You would notice the "early" clear only if you call it in this order:

Clear()
Display() // But i guess nobody would call here display 
Logic()
Draw()
Display();

So calling clear after the logic is just to seperate game logic and rendering. I also saw a project where the guy is using this pattern:

logic()
draw()
display()
clear()

It has no sideeffects.


AlexAUT

[Nexus]

however if you think about that most/a lot of time is usually spent on the logic part for one frame, calling clear at the beginning will leave the screen empty for the whole logic calculation.

The screen is only updated at display(), otherwise you would see constant flickering. But I still think it's a good idea to gather the draw calls together.

[carton83]

I'm really glad I asked this question!  Thanks everyone who has added to the conversation so far!

If you guys want to continue the conversation then by all means go ahead!  I'm enjoying it.