   do you need to render everything?
  Do you need to render the screen every frame (in directX/c++), which could end up well over a couple hundred times a second. What about rendering to the screen only  when the screen changes, and just the bit that changes. Having to draw a whole background that often seems like a waste.If an object just moves a little on the screen than just that object should be redrawn and the required background, not the whole screen .Is there a more efficient way to go.if( PeekMessage( &uMsg, NULL, 0, 0, PM_REMOVE ) ){ TranslateMessage( &uMsg );DispatchMessage( &uMsg );}   else{render();PS not paint call   
  Modern graphics cards are quite effecient at drawing the entire screen every frame. As long as you haven't got any fill-rate burning effects I wouldn't worry about it too much. What you really SHOULD avoid though is rendering all your objects all the time. Every self-respecting 3D engine should use at least frustum culling. You could enhance that with spatial structures, like octrees etc... and occlusion culling + some kind of LOD.For most 3D apps that should give you enough headroom for at least 500000 poly scenes.Hope I've been able to help,Jeroen   ;  jagguy - the approach of just redrawing the moved sprite and the required background is a technique known as dirty rectangle animation, where each frame the program keeps track of rectangles that need updating (i.e. are "dirty") and just draws them.This used to be a very popular technique when computers were slower at drawing but is pretty much redundant now.From your other posts, I think you are writing a 2D tile based side scroller at the moment. My most recent 2D side scroller on a 500mhz P3 with a 64meg graphics card could cheerfully draw 500-600 32x32 tiles every frame (i.e. the whole screen twice) and still not catch up with the vertical retrace so still manage optimal performance.Also, redrawing the whole screen each frame drastically simplifies a lot of the work that your program needs to do in terms of managing and tracking dirty rectangles and erasing "dead" items etc. Now that graphics cards have dedicated CPUs, it is better to pass as much work over to the card as possible to free up your system CPU to run stuff like AI, collision detection and so on.If you are experiencing performance problems, I would look elsewhere in your program first before trying to reduce the number of tiles you are drawing each frame.HTH   ;  I didn't mean to limit the topic to my specific program but the replies have been interesting.Maybe not for most 2d games but rendering all the time for 3d scenes seems silly. Some 2d scenes it us easier to render the whole screen, and a little bit on the outside because it is less complicated than working out the exact area to clip. My 2d scenes get well over 600fps with a whole screen tiled, with plenty of room to move. However tat is with a tile size of 32 , a tilessize of 8 dramatically slows down to 100-200 fps.;  In 3D games it does not render every object already. You as the player just don't know that. Game engines used for 3D games often cut apart the geometry into a polygon soup. They do this through space partioning algorithms, such as octrees, quad trees, BSP trees, and Kd-trees.They cull out triangles that are not on the screen or behind objects through occlusion culling and frustum culling. Quad trees can also be used in 2D games to do basically the same thing. In frustum culling objects not within the line of sight of the user will not be rendered. This cuts down the required time to render a frame.They also often use such things as octrees to help increase the speed of collision detection.   ;  Well, I'll input on this. Currently, many major games use frame limiters to help GPU issues. Most limit around 30-33 fps. This is actually faster than our film cameras run, aroun 24 fps. So if your game gets 100 fps you are doing great. Currently you can make a game that will almost never slow down a GPU. Only the most intensive games that have lots of particles showing at all times and such will slow down the entire computer. Doom 3 for example only uses a lot of power because of all the particles, this is where shifting all you can to the video card counts. All major game engines now redraw the entire screen as it is the most effecient because of the video card technology. This is why video cards have gotten faster and bigger. The more VRAM the more things you can pass to the video card. So, really, don't worry about the performance unless it drops below 30 fps. But for a 2d game, you should be fine.   ;  q) doesn't a API like directX automatically uses the vram and unless you specifiy to use system memory eg win32 controls then not using vram isn't an issue.q) I have been using directX and doesn't that do an automatic background culling of polygons , which cannot be seen. I thought this was the case so correct me about me directX automatic culling if I am wrong.   ;Quote:Original post by jagguyq) I have been using directX and doesn't that do an automatic background culling of polygons , which cannot be seen. I thought this was the case so correct me about me directX automatic culling if I am wrong.No it doesn't. That is differen't from frustrum and occlusion culling techniques.   ;  If you really want to not redraw your 2D screen every frame it's quite possible, but as already have been said it's not very often necessary on a modern PC. What you would do is simply check what objects have been moved and calculate a square around the last position and the new one (of course adding the objects bounding square/circle/whatever) and then only redraw that portion of the screen. Unless you move a lot this would speed things up a bit, and it's even functions to do just this in the J2ME API for mobile platforms.Culling objects in a 3D engine that are outside of the screen, called Frustum Culling, works best if you can cull large groups of polygons instead of going "should this poly be drawn? no. should this poly be drawn? no.".Quote:q) doesn't a API like directX automatically uses the vram and unless you specifiy to use system memory eg win32 controls then not using vram isn't an issue.I'm not 100 on this + i'm an OpenGL person, so please guys, do correct me if i'm totally wrong!I think the VRAM is used for textures, vertex data and such, but it's not just how much VRAM you got that matters, it's how you pass your data to it.One of the major bottlenecks when coding GFX is transfer from RAM to VRAM. In OpenGL you can either "send" your data to the GFX card one vertex at a time (called immediate mode) or send a whole batch of vertices to it once. The latter is usually faster. It's about grouping vertices and data with similar "behaviour" (in lack of better word) together.Perhaps this was a bit of topic, but i thought it should be explained =)This file explains better what batching is and why this technique is used.   ;  If you want to avoid re-rendering everything in a 3d scene, just Google for "rendering imposters". That type of approach typically only matters for large scenes. For small scenes, or basically anything 2d, it's far more efficient to just redraw everything.   