This is amazing, I’m shocked by the speed you’ve achieved. Last year I took an old landscape rendering program from a type-in program created by David Lawrence in the Acorn User magazine. With optimisation and converting to 6502, I got this sort of image:
As you can see from the timer, it is very slow in comparison to what you’ve done. I’m still relying on BASIC’s built-in triangle drawing but it would take a miracle to get it down to similar speeds.
Thanks for sharing the code, I did spot a couple of potential speed-ups in relation to the line drawing code. Given that each byte in the screen memory represents two neighbouring pixels, I noticed that your drawing code is always masked e.g.
Code: Select all
lda (plotposition),y:and #%01010101:ora maskedcolour:sta (plotposition),Y:iny
If we could avoid masking some of the time, that would get down to
A reduction from 18 cycles to 8 cycles, so very tempting if it works from a good proportion of lines drawn. We can’t just rely on ordering of drawing from right to left to not mask the right pixels and mask the left because of the drawing order in layers from front to back.
In the diagram above, I show two possible scenarios. First to explain the colours. The bottom layer of green and red is the previous layer drawn, so the heights will be in the buffer. The blue and yellow are the current layer being drawn, so would want to make as fast as possible.
In the left hand case, we can draw the yellow first without masking because when the blue is drawn, it will fill up the left pixels, so can be done without masking. In the right hand case however, we can see that drawing the yellow without masking would mess up the already drawn green pixels where they overlap.
Optimisation opportunity #1
The answer would be to compare the height of the left and right columns from the height buffer. Then call an unbuffered version of the line drawing routine for the one which starts highest and the buffered version for the lower one.
Optimisation opportunity #2
Then another step in complexity but also performance could come from noting that where the current layer has an overlap between the left and right pixels, we can draw them both with one byte by combining the colours with appropriate masks. That would mean for part of the drawing we just have the 8 cycle code instead of using the 8 cycle for one side plus the 18 cycle masked drawing on the other. The code would take another step in complexity in managing the different combinations.
Now I’ve added dashed lines for each scenario. Above the lines, we can draw everything with a single 8 cycle call per screen row, using the combined colours. That would overdraw on one side but with no consequence as that side will eventually be drawn properly as we go further up the screen. Below the line would need to use the masked drawing as before.
All good fun, thanks for the inspiration to look into this topic. I won’t try to implement these for now in case you are planning some changes but would be happy to try if you didn’t want to.
)
Maybe it is too intensive to pad out into a full game as is but full screen, real-time isn't everything. I can imagine the basic technique having some kind of use in a Beeb game. Perhaps in some kind of small viewport, in conjunction with something less intensive. Maybe some kind of cityscape rather than landscape where the degrees of movement might seem more natural (because city blocks have a lot of right angles).
