Give with one hand, take with the other....
So, we've got our ultra smooth scrolling at a cost of barely any cycles. We're laughing right, this is going to be a piece of cake? Well, no. All those savings come at a price and that price is a big increase in complexity.
A static bitmap display has some nice properties, locating the next byte to the right is a simple INC HL instruction (or even an INC L if we're careful) which makes drawing nice and easy. Moving vertically is slightly more tricky, but it's consistent and thus not too much of a strain.
When we start hardware scrolling the screen, things get a bit messy. The display memory starts to wrap around and we can no longer rely on simple calculations, even moving one byte to the right now potentially involves significant maths and we can say goodbye to all those precious cycles. That's bad, so it's necessary to look closer at how the wrap affects screen addressing.
Essentially, it divides the screen into at most three separate areas; a top and bottom area which we know will be internally contiguous and a single character high row on which we will have to deal with the address wrap. All of our drawing routines need to be aware of this, using high speed instructions where possible and falling back on slower code when we don't get a choice.
As if that weren't enough, recall that to get pixel perfect precision we introduced a second buffered display. This is drawn shifted across by a single pixel to compensate for the lack of finesse we achieved in hardware. This means that for absolutely everything we draw, be it sprites or background tiles we need to be able to draw it with pixel precision. And naturally the CPC's pixel format isn't exactly designed to make that easy.
Kinda makes nicking that crushingly slow Speccy routine look tempting, doesn't it?
A static bitmap display has some nice properties, locating the next byte to the right is a simple INC HL instruction (or even an INC L if we're careful) which makes drawing nice and easy. Moving vertically is slightly more tricky, but it's consistent and thus not too much of a strain.
When we start hardware scrolling the screen, things get a bit messy. The display memory starts to wrap around and we can no longer rely on simple calculations, even moving one byte to the right now potentially involves significant maths and we can say goodbye to all those precious cycles. That's bad, so it's necessary to look closer at how the wrap affects screen addressing.
Essentially, it divides the screen into at most three separate areas; a top and bottom area which we know will be internally contiguous and a single character high row on which we will have to deal with the address wrap. All of our drawing routines need to be aware of this, using high speed instructions where possible and falling back on slower code when we don't get a choice.
As if that weren't enough, recall that to get pixel perfect precision we introduced a second buffered display. This is drawn shifted across by a single pixel to compensate for the lack of finesse we achieved in hardware. This means that for absolutely everything we draw, be it sprites or background tiles we need to be able to draw it with pixel precision. And naturally the CPC's pixel format isn't exactly designed to make that easy.
Kinda makes nicking that crushingly slow Speccy routine look tempting, doesn't it?
posted by XeO3-CPC at
9:17 pm
0 Comments:
Post a Comment
<< Home