Quote:
Originally Posted by zero
And you think that will be faster than just a copperlist for colour changes a sprite positioning (no bitplane DMA for sprites).
|
I didn't say that, I was simply saying that my intention is to start with tried-and-tested methods which, frankly, I stand a chance of understanding.
With a bit of luck we'll have the basis for a simple tech demo sometime early next year - I certainly intend to stick it up on GitHub, so if you want to take it and try implementing your idea, you'd be more than welcome to!
[PS. I do understand how bitplanes work, sir... As I said, the idea is to do it with multiple passes, drawing the road first (while noting object positions), then blitting the horizon/sky, finally drawing the objects in reverse. The objects blitted over the road will reset the planar values in that case I believe...]
[PPS :
Quote:
Originally Posted by zero
Please do. [show the images demonstrating the Lotus road technique]
|
OK, so in my earlier post I showed the single-bitplane image used as the blit source (this is Lotus 2, but the principle is the same):
Quote:
Originally Posted by TuRRIcaNEd
|
If I understand this correctly, the following two images show what is generated with the alternate-scanline copper switch turned off. Firstly with a white kerb (COLOR01 = white or light grey) :
Then with a red kerb (COLOR01 = red, then dark grey for the tarmac, then red again for the opposite kerb):
With the copper alternating those values at the required number of scanlines you get this :
Note that the "kerb" is relatively thick horizontally compared to the road markings (at least 4px until some way into the distance). As I understand it this is probably to allow for the OCS/ECS copper's 4px "resolution" when it comes to mid-scanline palette changes.
]