Re: Attempts at 3d on the Sam?

[Thomas Harte]

Well I'll certainly have to consider investing in some back issues of  
Sam Revival. I'm pretty confident that I just bought one of your old  
Sam's on eBay, so I'm suddenly with a real machine again, at least  
temporarily. Though I think I'm going to have to contact you privately  
concerning that, and to make some enquiries about Quazar products. And  
at the minute I'm suddenly broke due to a sudden life change (new job,  
new city, no relocation package).

Anyway, relevantly to this list, I've been thinking about it a bit  
more and I'm not really sure what to do. I think I'm settling on one  
of two paths:

Attempt at "high framerate" 3d (by which I mean, maybe 10 fps if  
lucky). This would probably mean a vector based game, either a first  
person maze crawler or a simple space shooter. If the former then  
probably I'd throw fixed height walls and portals at it, meaning that  
the maze itself would have perfect hidden face removal, giving the  
impression of solid, albeit all black, walls. In either case, I guess  
other mini-optimisations are stuff like only using 4 colours and using  
palette switching so that the frame buffer only needs to be 'cleared'  
every fourth frame. Or only a quarter needs to be cleared each frame,  
if you prefer.

Attempt at "low framerate" 3d (with Freescape-style interaction).  
Obviously I've just been studying the Freescape engine, but I don't  
think it's the optimal way of doing things on the Sam — 3d graphics  
are a classic time/space trade-off and the Sam has at least 5 times as  
much RAM as the old Spectrum 48 kB, plus it's probably acceptable to  
have short loading breaks between sections of the world. So then I  
fall back on everything I learnt doing software 3d on the PC about ten  
years ago, and I think maybe the best way to go is relatively simple,  
separated rooms (as per Freescape), but with a BSP for each, then do a  
front to back render into a much simplified RLE based s-buffer  
(simplified because you can always be certain that pixels that have  
already been painted don't need to be painted again, so really you're  
just gap fitting). But then I'm thinking either that precision  
problems will be hellish or that I'll have to use some 3 or 4-byte  
number format and some really expensive multiplys & divides.

In reality, I'll probably just think about it all for a long time and  
do nothing. But I'd love to hear other's comments/thoughts in case I  
do manage to push through.

Incidentally, what are good timings for multiply and divide on a z80?  
If I can stick to something relatively compact like 8.8 fixed point  
then multiplication doesn't seem to be a problem as I can just use one  
of those (x^2)/4 table solutions reducing it all to a couple of table  
lookups and two or three adds and subtracts, but dividing looks like  
it'll eat quite a few cycles.

On 8 Apr 2008, at 14:58, Colin Piggot wrote:
Thomas Harte wrote:
I've just discovered pyz80 and am having a fresh bash at some Sam
projects. As I'm simultaneously working on a Freescape interpreter  
for
the PC, my thoughts have inevitably turned to 3d on the Sam, even if
it means a Freescape-style non-realtime display.

Cool!


besides Stratosphere, the F16 demo and that brief gameover bit in
Dyzonium, are there any other playable segments of games that
demonstrate 3d graphics? I know there are some demos with bits of 3d
graphics, but I figure that spending 256 kb on getting the fastest
possible rotating cube isn't a helpful guide.

The game over segment of Dyzonium was all precalculated as far as I  
can
remember, not processed in realtime.


has it been established whether the animated gifs of Chrome featured
on http://www.samcoupe.com/preview.htm represents the speed at
which the game would play on a real, unexpanded Sam?

No, I had just made the animated gifs from screens drawn up by some  
of my
early test routines.


is there any speed advantage to using the ROM routines such as
JDRAW, JPUT and/or JBLITZ? I appreciate that they are more general
case than routines that it makes sense to write for a game, but as I
understand it the ROM is uncontended?

The ROM is uncontended, but you would still be faster to write your  
own
optimised routines, tailored specifically to exactly what you want  
to do.
With Stratosphere I came up with a whole set of faster line drawing  
and
clearing routines, which for example took advantage of the  
undocumented
instructions to split IX and IY into four 8 bit registers, and for  
clearing
it just cleared a byte, and didn't worry about nibble pixels.


To be honest, I can imagine that something like Chrome could be done
with a live update since most of the display doesn't change between
most frames (it's just a bunch of vertical strips of colour that  
quite
often change height and occasionally change colour), and the
algorithms that are commonly used to calculate scenes such as that in
Chrome make it really cheap to calculate out a minimal list of the
required changes.

I had come up with quite a lot of tricks that would have made Chrome  
as fast
as it could. Solid walls 2 pixels wide, so you are dealing with just  
byte
values and not nibbles, and means walls could be quickly extended/ 
shrunk
when drawing the next frame. There's a 9 page article about the work  
I had
done on Chrome in issue 16 of SAM Revival magazine with more info.

Colin
======
Quazar : Hardware, Software, Spares and Repairs for the Sam Coupe
1995-2008 - Celebrating 14 Years of developing for the Sam Coupe
Website: http://www.samcoupe.com/