Question about redrawing the background

[ExarKun]

Hi!

So this is probably a very basic question and I'm sure it has been answered before, but I wasn't able to find anything. So I recently started doing some SFML and I have a general question about the way things are redrawn each frame. Currently what I have been doing (and what I found in tutorials all over the net) is that you clear the screen with any color, redraw the background and then redraw whatever else you have.
So as a simple example: Let's say I have some random image as a background and a player sprite. What I do right now is use Window.clear() and then I draw the background image and afterwards the player sprite.

Now what I wonder is, isn't there some way to only clear the sprite? Even when talking about a game running at 60 fps it seems awfully inefficient to redraw the background 60 times a second when you really only need to clear the sprite. I thought that maybe there was a way to sorta layer several windows on top of each other. So you'd have one with the background which you never clear and one for the player sprite which you do clear.
Is something like that possible or is it really the default way to clear the entire screen once every frame?
I'm just having a hard time imagining a NES redrawing the background 30 times a second.

Thanks in advance and sorry again for asking what is probably a very basic question. I just couldn't find any answers.

[korczurekk]

1. You don't need to clear window if your background covers whole view.
2. Are you writing software for NES?
3. What you propose is extremely inefficient, you should be more concerned with stuff that actually matters, use profiler before any attempt on optimization.

[Hapax]

There is actually a way to prepare the background once and then use it, sure, but, since the whole window needs to completely updated every cycle, it's most likely that just drawing the image directly is more efficient.

Anyway, the 'way' would be to draw to it the background (single image or multiple images/layers). Then draw the render texture to the window (probably using a sprite/quad) each cycle before all your sprites. Note that this still requires the background to be drawn before the sprites every cycle but allows the construction of a single background from many parts to occur only once. If your background is a single image (as you did actually mention), there's little use for this method

Remember that the window should be completely updated and refreshed every single cycle/tick/frame. Graphics cards expect this sort of arrangement now. If, however, you are programming for a different system such as SNES, this would probably be impossible to do. If you are programming a SNES-like game on modern hardware, however, you need to follow the 'rules' of modern hardware.

[ExarKun]

Thank you very much for both of your quick replies!
I am not programming for retro hardware, but rather a retro game on modern hardware. However, my question was of a more general nature rather than actually related to the current state of my project. I just used a very basic example to get my point across. I was just curious if there were any alternatives to the way I'm currently doing it/learned to do it from tutorials.

Thank you very much Hapax, I think what you described in your 2nd paragraph Is exactly what I need. I think that'll be a huge help moving forward. Also thanks for the insight into hardware! Always love to learn new things.

Thanks again for answering my question. Really didn't expect such great answers in so little time!

[Hapax]

No worries. Pleased it helps you.

Note that using the render texture will not help with performance - it will, in fact, be slower (still not noticable, of course) - but it does allow the entire render texture to be drawn with a shader, for example. In fact, if you had a static background but wanted to construct it from parts, you could create the image and store it in a standard texture (since it's only done once) and then use that to draw the background (with a sprite/quad). This boils down to having a single texture drawn to the window each cycle (whether you use the render texture or not) so if your background texture is a single image loaded from a file, use it directly if it doesn't need any processing.

Basically, draw everything that you can see every time.

To draw in a similar way to 'retro' hardware, you may want to create or use some form of intermediate stage. That is, some object (for example) that can take your input in the way the retro-style input would be and convert it into the display you expect. Note that that intermediate object would still need drawing every cycle but may be able to be updated when needed.
For example, if the retro display you wanted to use was text-based (or grid based), you could consider something like Selba Ward's Console Screen:

(click to show/hide)

There may be other libraries for more fluid screen otherwise you might just have to make what you need for yourself!

[Mario]

The basic idea is that most modern hardware is basically able to redraw the background without using significant time (unless it's very complex, like a huge tilemap or something like that).

If you think your background drawing is too slow and there aren't significant updates between frames, just render your background to a sf::RenderTexture and then use a sf::Sprite to actually (re-)draw the cached background every iteration.