Attempts at 3d on the Sam?
Hi, 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. I'm therefore curious about lots of things, and have a multitude of questions: — 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. — 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? — 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? 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.
Re: Attempts at 3d on the Sam?
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/
Re: Attempts at 3d on the Sam?
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
Re: Attempts at 3d on the Sam?
Thomas wrote: 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. What I did on Stratosphere to clear the previous frame was to draw over the previous set of vectors. What I did when a frame was drawn was to store all the line co-ordinates in a table, and then when clearing simply rattle through the table and draw over the lines with palette 0 and not bothering about pixel accuracy, just clear the full byte. Far quicker than attempting to clear the whole game area. 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, Easier to ignore programming for the 256K SAM if that's what you thinking with 'at least 5 times', always just assume the machine has the full 512K memory as that's what the sheer majority of software was written to use. Although saying that, 256K memory upgrades still sell so there is probably a fair few machines still tucked away with just 256K. 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. Oh don't say that! Give it a go if you have the time :) Out of the two ideas you came up with, I think the 2nd option - a freescape sytle system - with coloured solid walls in MODE4 would look really spectacular and would be something new on the SAM. 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. I used a lot of data tables and 8.8 fixed point maths on Stratosphere, and was going to do the same with Chrome. I'll have to hunt out old routines and see what I did come up with back then. 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/
RE: Attempts at 3d on the Sam?
Still fascinated by the subject. After many many wasted hours fiddling around with routines, I can see that realtime updated 3D on the SAM is possible, but haven't got the brainpower to finish off my buggy work... Howard (=Tobermory) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colin Piggot Sent: 08 April 2008 14:59 To: sam-users@nvg.ntnu.no Subject: Re: Attempts at 3d on the Sam? 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/ No virus found in this incoming message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.9/1364 - Release Date: 07/04/2008 18:38 No virus found in this outgoing message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.9/1364 - Release Date: 07/04/2008 18:38
Re: Attempts at 3d on the Sam?
Howard wrote: Still fascinated by the subject. After many many wasted hours fiddling around with routines, I can see that realtime updated 3D on the SAM is possible, but haven't got the brainpower to finish off my buggy work... I remember you released your Open3D disk on your website many years ago, which just had piles and piles of source code ... just wondering if you happen to have any screenshots of it actually rendering something? 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/
Re: Attempts at 3d on the Sam?
My original Sam only had 256K. And it really annoyed me later on when half the stuff on Fred wouldn't work, without warning. I think Gamesmaster programs were the worst offenders — you'd get the game clearly working, but with a bunch of monotone grey blocks moving around instead of the real graphics. Anyway, I think you're probably right that it makes more sense to attempt a slow Freescape-style adventure than a fast game. I've written a whole bunch of emulators that have a z80 core, but I've never written a substantial z80 program so trying to go all out on speed isn't realistic. Plus, it's an area that has otherwise been neglected in the Sam's library and it's a neat fit with my current PC project. Anyway, I've had a reasonably productive evening and have eight points demarking a cube spinning on screen, suggesting that my initial 8.8 x 8.8 - 8.8 implementation works, that my sine cosine tables have come out correctly formed and that what matrix code I have (just two functions — one to construct a camera matrix from the player's position and their view rotation in Euler angles, and one to apply the calculated matrix to points) is functional. I haven't implemented a divide yet, so there's no perspective. And what I have already takes a shocking ~105,000 cycles (measured empirically, using the Sim Coupe debugger) to completely draw a frame. But it's all first go code, so that probably isn't so bad. Hopefully I'll get a chance to do some more work sometime this week. I won't bore everyone with regular updates, but I'll certainly come back with a video if I get as far as anything graphically interesting, or if I encounter any problems I can't solve. On 8 Apr 2008, at 19:19, Colin Piggot wrote: Thomas wrote: 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. What I did on Stratosphere to clear the previous frame was to draw over the previous set of vectors. What I did when a frame was drawn was to store all the line co-ordinates in a table, and then when clearing simply rattle through the table and draw over the lines with palette 0 and not bothering about pixel accuracy, just clear the full byte. Far quicker than attempting to clear the whole game area. 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, Easier to ignore programming for the 256K SAM if that's what you thinking with 'at least 5 times', always just assume the machine has the full 512K memory as that's what the sheer majority of software was written to use. Although saying that, 256K memory upgrades still sell so there is probably a fair few machines still tucked away with just 256K. 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. Oh don't say that! Give it a go if you have the time :) Out of the two ideas you came up with, I think the 2nd option - a freescape sytle system - with coloured solid walls in MODE4 would look really spectacular and would be something new on the SAM. 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. I used a lot of data tables and 8.8 fixed point maths on Stratosphere, and was going to do the same with Chrome. I'll have to hunt out old routines and see what I did come up with back then. 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/
Re: Attempts at 3d on the Sam?
On 8 Apr 2008, at 14:35, Thomas Harte wrote: 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. I assume you're referring to Marc Broster's Dead Wild Cat demo on Fred 50, here? In defence of big pre-calculated tables: unless you have specific plans for other use of that memory, what's wrong with using the resources available to make your code run more quickly? — 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 speed gain from uncontended instruction RAM is a relatively small effect (especially for routines which write to the screen often, since any access to main RAM will round timings to the nearest 8 t-states if the screen is displayed). The ROM line drawing routines are written very much for being small; in MNEMOdemo 2 I wrote some line drawing routines which are significantly faster (I can't remember how much - probably a factor of 3 or so) at the cost of making them about 8 times bigger, which was still only a couple of k. Basically, by writing several routines each specialised for a small range of angles, you can remove some comparisons which otherwise get performed for every pixel. At the far extreme, you could generate code sequences to draw lines of specific and exact length and direction; a seperate routine for every individual line. This way, no run-time angle calculations at all would ever have to be performed. A quick back-of-the-envelope calculation suggests that a routines to draw every possible line up to 64 pixels in either x or y offset would take roughly 300k (plus a 16k table pointing to the location of each routine) so that could be a viable approach. Andrew -- --- Andrew Collier http://www.intensity.org.uk/ --- --
