Quote:
Originally Posted by Master484
Although in theory the idea is fascinating, because the previous frame always approximately contains the same image that we are going to draw next
|
That's a wrong assumption, or a misconception what "approximately" means in this context. Imagine walking in z-direction in the game. The zoom factor for every column changes and, because of perspective, the columns also move horizontally. No wall pixel will stay in its place, at least not in an easily predictable way.
You might think of something like video motion compensation, where blocks of pixels are moved to approximate the next frame. But that's not possible here, predicting the next frame would be
much slower than just rendering it.
What could work: There are sometimes large parts of the image that are not textured - floor and ceiling. One could divide the screen in 16 or 32 pixels wide vertical stripes, determine the maximal distance from the center in y for each stripe, and do c2p and clearing only on that part. But there's a number of disadvantages: Depending on your chunky buffer layout, this might be rather hard to do; you have to call the blitter for c2p much more often (
n times for every stripe, instead of
n times for the whole image), which introduces some overhead - more if you use interrupts, less if you do copper waits, but in the latter case you have to be careful with frame boundaries (copper list is restarted at vertical blank); it improves only some cases (lot of floor & ceiling), but not all - so the frame rate could be quite unsteady, albeit on average higher. Probably not that desirable for a game. On the other hand, if you have a lot of columns with a high zoom factor (so close to a wall), you might in general see less enemies and other sprites, which speeds up rendering and could compensate for this.