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/
