I can't speak from experience, but I think it would still be more performant to use the standard Spectrum screen layout for a backbuffer, as long as you're just drawing row-by-row up or down the screen. INC H is always going to be faster than LD A, L: ADD A, 32: LD L, A, and with the default Spectrum layout you only need to handle special cases every 8 rows. The main advantage I can see from a linear buffer is consistency/ease of use, rather than performance.
(There is a method using Gray codes that eliminates the need to add 32 for a linear buffer, but it only really works for drawing bitmaps, not vector graphics.)
Mucking about with 3D
Re: Mucking about with 3D
If you can afford the memory, it's really efficient to have a 256x256 back-buffer (or make it two 256x128 back-buffers).
The point is you arrange the bytes in vertical strips. Then you add 1 to move down a pixel, and add 256 (+1 to the hi-byte) to move right 8 pixels.
Though you then need an optimal routine to copy it to the main screen.
You could have a look at this thread on another site about optimising line-drawing in machine code:
https://www.worldofspectrum.org/forums/ ... g-lines/p1
The point is you arrange the bytes in vertical strips. Then you add 1 to move down a pixel, and add 256 (+1 to the hi-byte) to move right 8 pixels.
Though you then need an optimal routine to copy it to the main screen.
You could have a look at this thread on another site about optimising line-drawing in machine code:
https://www.worldofspectrum.org/forums/ ... g-lines/p1
Re: Mucking about with 3D
I've used that technique myself in some of my demoscene productions. A 16x16 tile screen (2 bitplanes) with vertical strips to have Y linearly accessible and X by increasing the high-byte.Joefish wrote: ↑Tue Apr 07, 2020 12:40 pm If you can afford the memory, it's really efficient to have a 256x256 back-buffer (or make it two 256x128 back-buffers).
The point is you arrange the bytes in vertical strips. Then you add 1 to move down a pixel, and add 256 (+1 to the hi-byte) to move right 8 pixels.
Though you then need an optimal routine to copy it to the main screen.
ZX Soft - ALIEN(BUGFIX) - GB Soft - Demoscene
Re: Mucking about with 3D
Wow, that's a nifty bit of lateral thinking! I hadn't considered have a rotated back buffer like that!
I have done Bresenham's algorithm in the distant past, and found it a very elegant idea.
Thanks guys! That's really interesting.
I have done Bresenham's algorithm in the distant past, and found it a very elegant idea.
Thanks guys! That's really interesting.
Re: Mucking about with 3D
My last game https://bobs-stuff.itch.io/sokobaarn used a vertical linear back buffer (VLBB) to speed things up given the amount of overdraw. And my current dev. of Melkhior’s Mansion is also using one for the exact same reasons. It’s heavy on the memory, but you can use the extra 64 bytes per column to store other data, look-up tables, colours (whatever), so it isn’t wasted.
Re: Mucking about with 3D
Good point. If you did all your drawing in the bottom 3/4 of the buffer then the top 1/4 of the buffer could be used as 32 page-aligned look-up tables, each up to 64 bytes long (e.g. 32 address entries). So any screen row, attribute row, sprite-indexing, function-indexing etc. tables could go there.
When I was playing around with 3D I did waste some memory but made it easier to synch with the raster. I only rendered a 256x128 view so only needed half of the buffer. But I programmed it so that on the refresh cycle, it would wait for an interrupt, then erase the half of the buffer it wasn't using. By the time it had done that, the timing was just behind the raster, so it could copy up the 256x128 chunk it had just drawn to the main screen without any tearing. Then it'd swap to rendering on the half that was just erased. Wasteful to use two buffers instead of one, but it made the synching a whole lot easier to manage.
And anyway, apart from the code, 3D objects need far less memory to define compared to lots of sprite animations.
When I was playing around with 3D I did waste some memory but made it easier to synch with the raster. I only rendered a 256x128 view so only needed half of the buffer. But I programmed it so that on the refresh cycle, it would wait for an interrupt, then erase the half of the buffer it wasn't using. By the time it had done that, the timing was just behind the raster, so it could copy up the 256x128 chunk it had just drawn to the main screen without any tearing. Then it'd swap to rendering on the half that was just erased. Wasteful to use two buffers instead of one, but it made the synching a whole lot easier to manage.
And anyway, apart from the code, 3D objects need far less memory to define compared to lots of sprite animations.
Re: Mucking about with 3D
do you have a copy of this file? the link is broken
i started programming the spectrum when i was 8 :-
1 plot rnd*255,rnd*175
2 goto 1
1 plot rnd*255,rnd*175
2 goto 1