Mucking about with 3D

The place for codemasters or beginners to talk about programming any language for the Spectrum.
Post Reply
User avatar
djnzx48
Manic Miner
Posts: 729
Joined: Wed Dec 06, 2017 2:13 am
Location: New Zealand

Re: Mucking about with 3D

Post by djnzx48 »

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.)
User avatar
Joefish
Rick Dangerous
Posts: 2042
Joined: Tue Nov 14, 2017 10:26 am

Re: Mucking about with 3D

Post by Joefish »

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
User avatar
Ersh
Manic Miner
Posts: 480
Joined: Mon Nov 13, 2017 1:06 pm

Re: Mucking about with 3D

Post by Ersh »

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.
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.
Firefox

Re: Mucking about with 3D

Post by Firefox »

Wow, that's a nifty bit of lateral thinking! I hadn't considered have a rotated back buffer like that! 8-)

I have done Bresenham's algorithm in the distant past, and found it a very elegant idea.

Thanks guys! That's really interesting.
User avatar
bobs
Microbot
Posts: 106
Joined: Thu Dec 28, 2017 8:26 am
Location: UK
Contact:

Re: Mucking about with 3D

Post by bobs »

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.
User avatar
Joefish
Rick Dangerous
Posts: 2042
Joined: Tue Nov 14, 2017 10:26 am

Re: Mucking about with 3D

Post by Joefish »

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.
User avatar
777
Manic Miner
Posts: 512
Joined: Fri Jun 26, 2020 11:23 am
Location: sw uk

Re: Mucking about with 3D

Post by 777 »

MonkZy wrote: Mon Apr 06, 2020 1:12 pm
3d-cube-asm-v1-2.tap
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
Post Reply