Hi there...
I was wondering if it was possible to redraw changing parts of the frame instead of redrawing each frame from scratch. For example:
The map in each frame is almost never changing. The sprite might change, so, you could create a "sprite background buffer", which stores the pixels that the sprite is occupying , and every time the sprite's animation or position change, you simply restore the "sprite background buffer" - i.e. remove the sprite -, then write sprite into the new position, or using the new animation.
Wouldn't that speed things up a lot?
yours sincerely
mkaatr
I was wondering if it was possible to redraw changing parts of the frame instead of redrawing each frame from scratch. For example:
The map in each frame is almost never changing. The sprite might change, so, you could create a "sprite background buffer", which stores the pixels that the sprite is occupying , and every time the sprite's animation or position change, you simply restore the "sprite background buffer" - i.e. remove the sprite -, then write sprite into the new position, or using the new animation.
Wouldn't that speed things up a lot?
yours sincerely
mkaatr
mkaatr, the update technique you describe is very common in desktop style applications. In some types of applications it is potentially advantageous. However, the potential downside to that approach is that it becomes very complex track and update only changed regions of your screen/window client area. Especially, as the amount of things moving and animating increases. In fact, for many types of games, the overhead (CPU and memory usage) of tracking update regions would end up causing the game to run slower than simply blasting the whole scene each time.
Another consideration is consistent frame rending latency. If you're rendering everything for each frame of animation, you're likely getting more consistent performance between frames. You're executing similar code paths each time and you're reducing the branching your code has to do. This is not only good for consistency, but it also helps reduce the hiding places for bugs.
Another consideration is consistent frame rending latency. If you're rendering everything for each frame of animation, you're likely getting more consistent performance between frames. You're executing similar code paths each time and you're reducing the branching your code has to do. This is not only good for consistency, but it also helps reduce the hiding places for bugs.
This technique is called "dirty rect" updating and was common prior to the times when computers were fast enough to draw the entire frame anew each time. The reasons why most people don't do dirty rect updating anymore are twofold:
1) It doesn't work for 3D, because any change in the camera location or angle requires a complete redraw, not just a "scroll", due to the perspective projection, and
2) It is always more interesting to have everything animating, like trees blowing slowly in the breeze and so on, so typically you always use the horsepower you have to make as much stuff on the screen animate as possible, if only subtly.
We will be animating as much as we can in Handmade Hero, so we won't be using dirty rect updating even though we are 2D. However, we will do some things to minimize redraw, such as pre-compositing part of the background that does not change frequently (the ground, etc.) so we don't have to recompute it every frame, which is similar in spirit to dirty rect updating (you can think of it as "dirty layer" updating, perhaps... rather than it being about regions of the screen, it's about layers of the screen and whether or not they need to be recomputed)
- Casey
1) It doesn't work for 3D, because any change in the camera location or angle requires a complete redraw, not just a "scroll", due to the perspective projection, and
2) It is always more interesting to have everything animating, like trees blowing slowly in the breeze and so on, so typically you always use the horsepower you have to make as much stuff on the screen animate as possible, if only subtly.
We will be animating as much as we can in Handmade Hero, so we won't be using dirty rect updating even though we are 2D. However, we will do some things to minimize redraw, such as pre-compositing part of the background that does not change frequently (the ground, etc.) so we don't have to recompute it every frame, which is similar in spirit to dirty rect updating (you can think of it as "dirty layer" updating, perhaps... rather than it being about regions of the screen, it's about layers of the screen and whether or not they need to be recomputed)
- Casey
It still counts for software buffers. But frontbuffers, hw-buffers suffers from a constant overhead to every call. You can do 4000 pixel particles in backbuffer for 1 pixel in frontbuffer, under GDI. But you can still do 1000 frontbuffer clears, for just 1 softbuffer clear, in HD. Its a bit weird.
The general principle is that that there is "stuff" which mostly doesn't change between frames. Dirty rect updating is a simple realisation, but the principle can be applied in modern games too.
In 3D, for example, it's generally true that the objects which you saw on the last frame are the objects which you will see on this frame for the most part, and if that's not the case (e.g. extreme motion, scene change, whatever), you can generally tell in advance.
Physics simulation is a similar story: if two objects are close in one frame, they're probably close in the next frame too. You can use this to speed up collision detection.
In 3D, for example, it's generally true that the objects which you saw on the last frame are the objects which you will see on this frame for the most part, and if that's not the case (e.g. extreme motion, scene change, whatever), you can generally tell in advance.
Physics simulation is a similar story: if two objects are close in one frame, they're probably close in the next frame too. You can use this to speed up collision detection.