You cannot depend on using dirty rects at all. As soon as you flip the backbuffer to the front, the contents of what used to be the front can now be potentially totally trashed. The graphics card might use an entirely different portion of memory for the next frame which could contain any kind of junk data. That's why you have to either redraw the whole screen or do a cls. You might be getting what seems to be maintained backgrounds when you flip, but this is in now way reliable and on many systems it's not going to work. Some systems have multiple buffers beyond double-buffering which would totally mess up your system, and especially in OpenGL you have 0 guarantee that the buffer content is preserved. There is no point at all doing dirty rects because you have to manually preserve the backbuffer e.g. copy it into an image or redraw the whole frame anyway.
Also when you issue commands to the graphics card ie via the OpenGL or DirectX driver, for the most part using Max2D you are in what's called `immediate` mode whereby what you draw is sent to the driver right away, at the time you ask for it, but it is not necessarily DRAWN at that time. The card/driver can buffer a whole bunch of commands and in some cases may not draw *anything* until you do a flip(). So if you are seeing your flip time be different depending on how much is drawn, you can be fairly sure that *your system* is caching the drawing commands and doing them all at once when you call flip(). To remedy this you might try to get all your graphics commands done as early as possible in your game loop, and then try glFlush() for OpenGL, which tells it to start drawing if it hasn't already. That might then allow the driver to do the drawing in parallel to other stuff you're doing with the cpu, which might make it faster. It sounds as though on your system it is waiting for the flip request before it starts to draw, meaning that for the remainder of your game loop where the cpu is doing stuff the gpu is doing nothing.
I would also recommend making sure that your textures are not bigger than the maximum supported texture size on your computer, which in OpenGL is glGetEnv(GL_MAXIMUM_TEXTURE_SIZE,Varptr(MySize)). It will be at least 64 but it is limited on some cards. If the card's max texture size is smaller than the size you're asking for, it is going to create extra slowdown. You'd be better off breaking your images down into, say, chunks of 256x256. Bearing in mind, that will also add overhead, but might be less than what you save.
Also bear in mind that the graphics drawing speed is *highly* determined by the speed of your graphics card. 800x600 is quite a high resolution, compared to when games used to be 320x240. You might be just running into the limitations of your graphics card and how fast it can draw and how fast it can flip.
If you don't need to use alphablending for all objects *switch it off*. It will switch off the blending hardware which takes more time.
If you don't need to rotate or scale your objects smoothly, DO NOT load them as FILTEREDIMAGE. You don't need the extra overhead of interpolation.
If you don't need to use floating point coordinates for image placement, use int's, it may be faster to draw.
You might implement, instead of dirty rects, a `draw only the parts of the images that show`, so that you don't `overdraw` on top of stuff you've drawn already. You'd need to use a drawimagerect type of thing.
16-bit color can be faster for the backbuffer but the textures might still be stored as RGBA8888 (32-bit). I find on my system that 16 is no faster than, and sometimes slower than, 32-bit. The graphics card is optimized for best performance in a particular mode that they think is most popular.
Writing your own OpenGL/DX code will likely let you use features or switch on/off features that you can't with Max2D that may give you more speed. Also if you know you're drawing several objects that are similar or related, you can gain speed with less overhead by not having a glBegin() glEnd() wrapped around every single quad which is the case with Max2D.
Also when you issue commands to the graphics card ie via the OpenGL or DirectX driver, for the most part using Max2D you are in what's called `immediate` mode whereby what you draw is sent to the driver right away, at the time you ask for it, but it is not necessarily DRAWN at that time. The card/driver can buffer a whole bunch of commands and in some cases may not draw *anything* until you do a flip(). So if you are seeing your flip time be different depending on how much is drawn, you can be fairly sure that *your system* is caching the drawing commands and doing them all at once when you call flip(). To remedy this you might try to get all your graphics commands done as early as possible in your game loop, and then try glFlush() for OpenGL, which tells it to start drawing if it hasn't already. That might then allow the driver to do the drawing in parallel to other stuff you're doing with the cpu, which might make it faster. It sounds as though on your system it is waiting for the flip request before it starts to draw, meaning that for the remainder of your game loop where the cpu is doing stuff the gpu is doing nothing.
I would also recommend making sure that your textures are not bigger than the maximum supported texture size on your computer, which in OpenGL is glGetEnv(GL_MAXIMUM_TEXTURE_SIZE,Varptr(MySize)). It will be at least 64 but it is limited on some cards. If the card's max texture size is smaller than the size you're asking for, it is going to create extra slowdown. You'd be better off breaking your images down into, say, chunks of 256x256. Bearing in mind, that will also add overhead, but might be less than what you save.
Also bear in mind that the graphics drawing speed is *highly* determined by the speed of your graphics card. 800x600 is quite a high resolution, compared to when games used to be 320x240. You might be just running into the limitations of your graphics card and how fast it can draw and how fast it can flip.
If you don't need to use alphablending for all objects *switch it off*. It will switch off the blending hardware which takes more time.
If you don't need to rotate or scale your objects smoothly, DO NOT load them as FILTEREDIMAGE. You don't need the extra overhead of interpolation.
If you don't need to use floating point coordinates for image placement, use int's, it may be faster to draw.
You might implement, instead of dirty rects, a `draw only the parts of the images that show`, so that you don't `overdraw` on top of stuff you've drawn already. You'd need to use a drawimagerect type of thing.
16-bit color can be faster for the backbuffer but the textures might still be stored as RGBA8888 (32-bit). I find on my system that 16 is no faster than, and sometimes slower than, 32-bit. The graphics card is optimized for best performance in a particular mode that they think is most popular.
Writing your own OpenGL/DX code will likely let you use features or switch on/off features that you can't with Max2D that may give you more speed. Also if you know you're drawing several objects that are similar or related, you can gain speed with less overhead by not having a glBegin() glEnd() wrapped around every single quad which is the case with Max2D.