   SDL: Necessary to re-draw the ENTIRE screen?
  I'm relatively new to SDL and I'm working on a 2-D top-down shoot 'em up in C++.  The basic game engine is done, and I'm at the point where I want to add a large panel on the screen that will contain score, lives, etc.  However, for the most part, it seems like I'll only need to re-draw the "game" portion of the screen.  Does SDL require me to re-draw the ENTIRE scene every single frame?  Or can I selectively re-draw only that which is being changed?It seems like it would be inefficient to have to continuously re-draw the graphics framing the game, but in the SDL examples I'm looking at, it looks like EVERYTHING is being re-drawn every frame.Thanks in advance!   
  Welcome to the "Game loop", SDL isn't the only one that uses this, think about it, what happens if there is no game loop, the program will just run all the code and end with usually "return 0", now think if you move a graphic on the screen, well something has to clear the graphic and draw the background again, or you would have a smudged looking graphic that moved and no background there, so yes you would have to redraw every frame. I hope this clears this up for you, maybe someone else could explain this better.   ;  You don't have to.. but unless you want really efficient code, or need better performance most people just live with it. When not drawing the entire screen every frame complications arise due to double buffering. If you only draw to one buffer and not the other the screen will flicker.In single buffering, if you draw something to the frame buffer and don't clear it at the beginning of the next frame, then whatever is on them will stay. So the problem then arises when you have something you are drawing every frame moving across something that's static and your not drawing. The moving object will leave a trail of pixels across the screen unless you do some bliting(blitting is copying chunks of arrays to another location). so one solution would be to have two sprites for every sprite that is going to move. In one of these sprites you save the area of the screen this sprite is going to occupy. In the other sprite you have the actual sprite. Each frame you draw the original background back from one sprite, store the background from where the sprite is going to be placed, then draw the sprite to the screen.Other solutions involve XORing and different blitting techniques. The good news is sdl will do pretty much all of this for you. Look up SDL blitting's documentation.Edit: lol I forgot the most important part. If your using hardware accelerated surfaces, just draw every frame because every other case uses more cpu cycles then hardware accelerated blitting.http://kevinlocke.name/inquiry/sdlblitspeed/sdlblitspeed.php   ;  You certainly don't have to re-draw everything every frame, but this complicates the game a lot, and probably for minimal benefit.The basic idea when not re-drawing everything is to realize that you only have to redraw parts of the screen that something moved off of or (potentially) moved on to.  For example, if you have a fixed-screen (i.e. the map doesn't scroll) tank game and your tank moves, you would only have to redraw the background that the tank obscured at its old position, and then draw the tank at its new position.In a more complicated game (perhaps one involving a map that can scroll), however, you will basically end up redrawing everything anyway.   ;  @hallucinogenic, TntricksterThanks for your replies. It sounds like this is going to be more work than it's worth to try and implement something like this, especially for a 2D game where performance probably won't be an issue.  So for now, I won't worry about it.   ;  There are two easy ways you can do what you want.#1) Draw your panel on it's own surface/buffer, instead of on the screen. Draw the text, buttons, etc... Only re-draw it when something changes.Then, instead of redrawing every item in it, every frame just draw the surface/buffer you drew it onto. One blit of a medium-sized surface is alot better than blitting every button, and the panel background, and generating then blitting all the text, every frame.#2) Draw your panel on the screen only when it changes, and use SDL_SetClipRect to ensure nothing draws over it. Use SetClipRect again when you are ready to re-draw the panel.Either method would work well, and should be a cinch to implement.   