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
