Re: Attempts at 3d on the Sam?
Most of my thinking was just that if the left and right clip planes were freely positionable rather than hardwired to be at x = ±z then portal rendering would be extremely cheap. So if you're in a convex room A, which has one 'wall' W that is actually a doorway to convex room B then you can draw all of A, adjust the clip planes so that you're only allowing drawing to the left/right extent of W, then draw room B. And so on. With vertical fixed height walls you can get away with only supporting movable vertical clip planes. Of course, it'll look pretty jumpy if increasing precision in my matrix calculation stuff doesn't have a strong enough effect. But that's scheduled for after I've made some multiplication improvements. On Fri, Jul 11, 2008 at 10:58 AM, Colin Piggot <[EMAIL PROTECTED]> wrote: > Thomas Harte wrote: >> Oh, but it did also occur to me that I could create a convex-sector >> and vertical portal Wolfenstein-type thing for just an extra couple of >> multiplies per vertex. >> >> Then maybe use coherence stuff to produce a filled display, >> so you're mostly just extending or shrinking already filled areas of >> the screen frame-to-frame rather than having to carry the costs of a >> full redraw. Which I think you said was what Chrome was up to? > > Yes, Chrome was just going to extend or shrink what was already drawn there, > and redraw complete strips only when there had been a sprite drawn over the > top. > > It was something I was thinking of - your maths could be used for that sort > of style of 3D engine, and sounds like you have all the bases covered > already! Essentially, just hold a map with the 2D wall positions, your maths > code would then calculate which walls were visible and where, then just draw > the walls - either vector or filled. > > 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?
Thomas Harte wrote: > Oh, but it did also occur to me that I could create a convex-sector > and vertical portal Wolfenstein-type thing for just an extra couple of > multiplies per vertex. > > Then maybe use coherence stuff to produce a filled display, > so you're mostly just extending or shrinking already filled areas of > the screen frame-to-frame rather than having to carry the costs of a > full redraw. Which I think you said was what Chrome was up to? Yes, Chrome was just going to extend or shrink what was already drawn there, and redraw complete strips only when there had been a sprite drawn over the top. It was something I was thinking of - your maths could be used for that sort of style of 3D engine, and sounds like you have all the bases covered already! Essentially, just hold a map with the 2D wall positions, your maths code would then calculate which walls were visible and where, then just draw the walls - either vector or filled. 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?
Oh, but it did also occur to me that I could create a convex-sector and vertical portal Wolfenstein-type thing for just an extra couple of multiplies per vertex. That'd mean you could use vectors to draw the outlines of walls but everything would be clipped so that there was no ability to see through walls; they'd look solid but all the same colour. The camera would need to be kept level anyway, so you could throw in some more explicit vertex mirroring and probably up the framerate. Then maybe use coherence stuff to produce a filled display, so you're mostly just extending or shrinking already filled areas of the screen frame-to-frame rather than having to carry the costs of a full redraw. Which I think you said was what Chrome was up to? If you wanted filled graphics then I guess you'd be looking at fixed height walls or arbitrary angle. So it wouldn't be exactly like Wolfenstein - you'd lose texturing but gain flexibility in shape. I think that's best attempted as a fork of the code though, so if I attempt it at all then it'll be after everything else is neatly tied up. I continue to dither over whether to switch to Jam from Pyz80. On Thu, Jul 10, 2008 at 7:36 PM, Thomas Harte <[EMAIL PROTECTED]> wrote: > I'm still chipping away at optimisations, little by little. I've been > distracted by my PC remake of the Freescape engine*, but haven't stopped > working on the Sam stuff. The code is now roughly 28% faster than the > version that I submitted for Sam Revival, and I'm not done yet. > > Filled polygons shouldn't be an insurmountable problem. In fact, they should > be noticeably faster than the version from before I switched to vector > outlines. The main problem is that not using the stack pointer for polygon > filling will obviously slow that down by a huge amount, but continuing to > use the end of frame interrupt for triple buffering and timing would lead to > the occasional stray four pixels of random colour. In fact, it'd be very > occasional because it'd only happen if the interrupt fired while the CPU was > drawing the last four pixels of a scanline. I guess the final decision on > what to do about that would depend on whether the engine was being used for > anything that was meant to be close to a realtime game. > > My suspicion is that something sufficiently sparse that didn't run > full-screen would actually be playable in real time with solid graphics. But > I've yet to try to prove it. > > Incidentally, having watched I, Of the Mask a few times, I think it has > exactly this problem — though obviously being a Spectrum game it leaves more > 16 pixels of junk on screen. I'm not completely sure though. > > In terms of the engine's functionality, I'd like to get Elite-style movement > (i.e. incremental rotations around local axes rather than Euler angles and > progressive global axes) in there before calling it 'complete'. > > For a game, I prototyped a tennis game but it didn't seem to be fun whatever > I did. So now I'm not really sure. > > * I know it's definitely not what this list is for, but Windows and OS X > betas are available from http://tinyurl.com/66wr29 > > On 10 Jul 2008, at 16:06, Colin Piggot wrote: > >> Thomas Harte wrote: >>> >>> I think I'm running out of optimisation ideas now, which is not to say >>> that there aren't any, just that I haven't had them yet and may never >>> have them. So it's time to start implementing an actual game. >> >> Anything in mind at this stage for a game, and how feesible would it be to >> impliment shading to the code as it stands? (going back to one of the >> original ideas of being like a Freescape style engine) >> >> >>> Would anyone be at all interested in my code, packaged as a public >>> domain library of functions? I'll probably eventually do that anyway, >>> but I'm curious. >> >> Yeap, certainly. I had a few ideas on what could be done with the maths >> sides alone. >> >> 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?
I'm still chipping away at optimisations, little by little. I've been distracted by my PC remake of the Freescape engine*, but haven't stopped working on the Sam stuff. The code is now roughly 28% faster than the version that I submitted for Sam Revival, and I'm not done yet. Filled polygons shouldn't be an insurmountable problem. In fact, they should be noticeably faster than the version from before I switched to vector outlines. The main problem is that not using the stack pointer for polygon filling will obviously slow that down by a huge amount, but continuing to use the end of frame interrupt for triple buffering and timing would lead to the occasional stray four pixels of random colour. In fact, it'd be very occasional because it'd only happen if the interrupt fired while the CPU was drawing the last four pixels of a scanline. I guess the final decision on what to do about that would depend on whether the engine was being used for anything that was meant to be close to a realtime game. My suspicion is that something sufficiently sparse that didn't run full-screen would actually be playable in real time with solid graphics. But I've yet to try to prove it. Incidentally, having watched I, Of the Mask a few times, I think it has exactly this problem — though obviously being a Spectrum game it leaves more 16 pixels of junk on screen. I'm not completely sure though. In terms of the engine's functionality, I'd like to get Elite-style movement (i.e. incremental rotations around local axes rather than Euler angles and progressive global axes) in there before calling it 'complete'. For a game, I prototyped a tennis game but it didn't seem to be fun whatever I did. So now I'm not really sure. * I know it's definitely not what this list is for, but Windows and OS X betas are available from http://tinyurl.com/66wr29 On 10 Jul 2008, at 16:06, Colin Piggot wrote: Thomas Harte wrote: I think I'm running out of optimisation ideas now, which is not to say that there aren't any, just that I haven't had them yet and may never have them. So it's time to start implementing an actual game. Anything in mind at this stage for a game, and how feesible would it be to impliment shading to the code as it stands? (going back to one of the original ideas of being like a Freescape style engine) Would anyone be at all interested in my code, packaged as a public domain library of functions? I'll probably eventually do that anyway, but I'm curious. Yeap, certainly. I had a few ideas on what could be done with the maths sides alone. 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?
Thomas Harte wrote: > I think I'm running out of optimisation ideas now, which is not to say > that there aren't any, just that I haven't had them yet and may never > have them. So it's time to start implementing an actual game. Anything in mind at this stage for a game, and how feesible would it be to impliment shading to the code as it stands? (going back to one of the original ideas of being like a Freescape style engine) > Would anyone be at all interested in my code, packaged as a public > domain library of functions? I'll probably eventually do that anyway, > but I'm curious. Yeap, certainly. I had a few ideas on what could be done with the maths sides alone. 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?
Sorry! Gmail identified this message and, so far, this message only as spam. So I haven't seen it until today... The only slight problem is that I'm dividing one fixed point 8.8 number by another, not one 8 bit number by another. Apart from having either a very coarse z-axis or a very short one, that would mean either that only objects at z=1 could rotate so that lines start from any pixel and, as a result, objects at further z values are incapable of being towards the outside of the screen, or that nearby objects were jumping all over the place. Much more than they already do (though I think I'm still mostly blaming limited sine table precision after several multiplies for that, but if implementing 2.14 fixed point for those limited parts doesn't fix it then I'll have to rethink). Anyway, one of the speed-ups I have recently made (subsequent to my Sam Revival submission) is a 64 kb table to turn perspective divides into multiplies. I'm actually using the table to get 64/z, doing a vector multiply with that on (x, y) then doubling x and adding half of its current value to y so as to multiply it by 1.5. Oh, except that I'm actually doing something like 62/z so as to avoid small clipping errors causing off-screen coordinates. All of that has more than halved the amount of time I spend on projection and finally made projection cost less than transform (which is 9 table-based multiplies and a lot of adding, and was the co-focus of this weekend's optimisation spree). I think I'm running out of optimisation ideas now, which is not to say that there aren't any, just that I haven't had them yet and may never have them. So it's time to start implementing an actual game. Would anyone be at all interested in my code, packaged as a public domain library of functions? I'll probably eventually do that anyway, but I'm curious. On Tue, Jun 3, 2008 at 4:51 PM, Geoff Winkless <[EMAIL PROTECTED]> wrote: > Talking about division through multiplication and a table lookup, On Tue, 3 > Jun 2008 08:28:21 -0700, "Simon Cooke" <[EMAIL PROTECTED]> wrote: >> Never implemented it, but the principle is sound. It's not tremendously >> different to a reciprocal table. > > I never implemented it on z80 but I did do the same on ARM (where it gives > you a massive win since there's a MUL instruction but no DIV). > > Without wanting to teach egg-sucking, it's fairly simple in concept: you > just multiply the two numbers then shift the result down. > > So to divide an 8 bit number in L by 14, you need to multiply by (256/14)= > 18(ish) then use the H register as your result... so that gives you > (effectively) > > L * (256 / 14) / 256 > > The 256's cancel each other out, so you end up with > > L * (1 / 14) > > Obviously there's a loss of accuracy but it does mean you can get away with > a table of 256 bytes for an 8 bit divide. > > My problem is you still end up having to do a multiply, which (on z80) is > way too slow. I'd be tempted to use a 64kiB divide table and to hell with > it. > > Geoff > >
Re: Attempts at 3d on the Sam? OT Jam Assembler
Hi Memory overflow error is when your org address has gone over 65535 or dump address has gone over 32767 if you had the command dump 1,70 or something like that. Hope this helps if not send me your code and I will have a look. Dave - Original Message - From: "Tobermory" <[EMAIL PROTECTED]> To: Sent: Saturday, June 07, 2008 11:23 AM Subject: RE: Attempts at 3d on the Sam? OT Jam Assembler Anyone else getting an error when compiling?: Error: C:\JAM\O3D\OPENsource.s: Memory overflow! At Line 42 This points to an include into the last page of my project. Any ideas David? Howard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Brant Sent: 30 May 2008 17:56 To: sam-users@nvg.ntnu.no Subject: Re: Attempts at 3d on the Sam? You can also import comet source directly into Jam Assembler from a SAM disk image or file. Dave Jam Assembler download http://myweb.tiscali.co.uk/stoneddesign - Original Message - From: "Andrew Collier" <[EMAIL PROTECTED]> To: Sent: Friday, May 30, 2008 10:39 AM Subject: Re: Attempts at 3d on the Sam? On 30 May 2008, at 00:33, Thomas Harte wrote: Did you produce any demos with Open3d that I could just load up and view, without having to assemble? I didn't own COMET back in the day, don't have a way to transfer disks to disk images anyway, and World of Sam lists it as "not yet approved" for distribution. Hi, It looks like Comet is available from Edwin's own website here: http://www.samcoupe-pro-dos.co.uk/edwin/software/comet/comet.htm Edwin - i would it be okay by you, if I enable the download on WOS as well? Cheers, Andrew -- --- Andrew Collier http://www.intensity.org.uk/ --- --
RE: Attempts at 3d on the Sam? OT Jam Assembler
Anyone else getting an error when compiling?: Error: C:\JAM\O3D\OPENsource.s: Memory overflow! At Line 42 This points to an include into the last page of my project. Any ideas David? Howard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Brant Sent: 30 May 2008 17:56 To: sam-users@nvg.ntnu.no Subject: Re: Attempts at 3d on the Sam? You can also import comet source directly into Jam Assembler from a SAM disk image or file. Dave Jam Assembler download http://myweb.tiscali.co.uk/stoneddesign - Original Message - From: "Andrew Collier" <[EMAIL PROTECTED]> To: Sent: Friday, May 30, 2008 10:39 AM Subject: Re: Attempts at 3d on the Sam? > > On 30 May 2008, at 00:33, Thomas Harte wrote: > >> Did you produce any demos with Open3d that I could just load up and >> view, without having to assemble? I didn't own COMET back in the day, >> don't have a way to transfer disks to disk images anyway, and World of >> Sam lists it as "not yet approved" for distribution. > > Hi, > > It looks like Comet is available from Edwin's own website here: > > http://www.samcoupe-pro-dos.co.uk/edwin/software/comet/comet.htm > > Edwin - i would it be okay by you, if I enable the download on WOS as > well? > > Cheers, > Andrew > > -- > --- Andrew Collier > http://www.intensity.org.uk/ --- > -- > >
Re: Attempts at 3d on the Sam?
Thomas wrote: > I've submitted to Colin a tiny little demo of the 'engine' up to the > point of the most recent youtube video and it is my current > understanding that it'll be on the disk with Sam Revival 22. Yeap, that'll feature on the coverdisk with 22, along an article from Thomas. The coverdisk will also feature Burglar Bob, the last commercial release by Jupiter Software which will have a bit of a graphical revamp for it's re-release. Another confirmed article is a look back at what happened to Manic Miner The Lower Caverns - a sequel of the classic Manic Miner that was to have featured new levels, improved graphics and new music, quite a lot of input to this article from people involved with some of the new levels only coming to light recently after sitting idle on a floppy disk for 13 years since they were drawn. The mag should be out in about 2 weeks time. 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?
I think I might have read that one while researching - the one in which the argument is basically "Wolfenstein 3d must be possible because all the individual parts of the engine are simple" versus "scrolling the screen is even more simple, but the Sam doesn't seem to have the horsepower for that"? At least this time I'm actually going to release some code. I've submitted to Colin a tiny little demo of the 'engine' up to the point of the most recent youtube video and it is my current understanding that it'll be on the disk with Sam Revival 22. Re: the precision issue, the location of each point ends up effectively being the sum of three numbers, each of them the product of at least three numbers. And each of my table based multiplications is likely to lose accuracy in at least the low bit, so the compounded loss of accuracy is almost certain to have a visible effect. I'm going to switch to a 2.14 fixed point scheme for matrix preparation. It'll cost a bit more per-object but no more per-vertex. And it's a much better idea if I want to implement proper local-axis rotations ala Elite rather than the hodge bodge of local and global axes that you get with Euler angles. On Fri, Jun 6, 2008 at 3:51 AM, Simon Cooke <[EMAIL PROTECTED]> wrote: > I'm amused... was just doing a search for some old friends on Google, and lo > and behold... we were talking about trying to get a good 3D renderer going > back in 1995. > > Some things never change ;-) > > Si > >
RE: Attempts at 3d on the Sam?
I'm amused... was just doing a search for some old friends on Google, and lo and behold... we were talking about trying to get a good 3D renderer going back in 1995. Some things never change ;-) Si
RE: Attempts at 3d on the Sam?
Talking about division through multiplication and a table lookup, On Tue, 3 Jun 2008 08:28:21 -0700, "Simon Cooke" <[EMAIL PROTECTED]> wrote: > Never implemented it, but the principle is sound. It's not tremendously > different to a reciprocal table. I never implemented it on z80 but I did do the same on ARM (where it gives you a massive win since there's a MUL instruction but no DIV). Without wanting to teach egg-sucking, it's fairly simple in concept: you just multiply the two numbers then shift the result down. So to divide an 8 bit number in L by 14, you need to multiply by (256/14)= 18(ish) then use the H register as your result... so that gives you (effectively) L * (256 / 14) / 256 The 256's cancel each other out, so you end up with L * (1 / 14) Obviously there's a loss of accuracy but it does mean you can get away with a table of 256 bytes for an 8 bit divide. My problem is you still end up having to do a multiply, which (on z80) is way too slow. I'd be tempted to use a 64kiB divide table and to hell with it. Geoff
RE: Attempts at 3d on the Sam?
Never implemented it, but the principle is sound. It's not tremendously different to a reciprocal table. Si -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Harte Sent: Monday, June 02, 2008 4:10 AM To: sam-users@nvg.ntnu.no Subject: Re: Attempts at 3d on the Sam? Two replies in one, please bear with me... Tobermory: 25 fps is probably more than my code is getting most of the time. Most of the time it varies between about 10 fps for a close-up view of the most detailed part of the Cobra Mk 3 to 50 fps for a middle distance or beyond view of the box. I think that "towards 20" is probably where it spends most time. The code only processes points that are connected to lines that may be actually visible (i.e. after hidden face removal, before clipping), so geometry costs go up and down as well as rasterisation. I'm still nothing like done on optimisation though, so hopefully things will improve. I agree that precision is visually lacking in some areas. I'm not sure if it's just the number formats I've picked or if I'm short-sightedly throwing it away somewhere. The Adder model at the start of the clipping video shows the most obvious problems, but it's tiny - something like 64 units across, i.e. 1/4 of a unit in the fixed point scheme. The Cobra Mk 3 is more like 256 units across so shows a lot less jumpiness when viewed so that it fills a screen for obvious reasons. Then the cube is 512 units across, which probably also helps to explain its superior appearance. I'm not sure if those units are the same as Elite units. I've grabbed the geometry from some VRML files of the Elite ships that I found on a fan page, not from the original source or anything that identifies itself as necessarily a direct derivative of it. So they probably do, but may not. The engine is currently limited to individual objects that are at most 1535 units across, but that's really only a limit on the maximum separation of geometry that is listed as clustered around a single point. In theory the code and data structures could allow for superset models that connect geometry from lesser models, but it'd probably mean transforming (but not projecting) points before the engine knows whether they'll actually be used. And the maximum length of a vector that can be clipped is still just 4095 units. Though by then we're talking about 1/16th of the entire playfield. It's very possible that the composite rotations are part of the problem. Sine and cosine tables are stored in the same 8.8 fixed point format as elsewhere, so building each rotation matrix involves quite a few operations that might lose accuracy that could be stored in the same amount of precision, and then when matrices are combined (one for each object, one for the camera) you possibly lose even more. I possibly need to think about using an intermediate higher precision for those stages. It'd cost quite a bit more (since those multiplies could no longer be table based as things currently stand), but those are all per-object costs and wouldn't affect the per-vertex costs. I'll see how speed is looking further down the optimisation path. I am doing the x/z and y/z first, but that shouldn't be a problem. I'm actually throwing away some of the low order bits after that calculation. The division gives numbers in the range -1 to +1 for both x and z, so in 8.8 fixed point that gives 512 possibilities. Probably a problem is that I've put the near clip plane at z = 0.25, so that the tiny, tiny Adder doesn't get clipped before it gets to a sensible size. So that effectively means that points on the near clip plane can only be accurate to the nearest four pixels regardless of exactly how the projection is calculated. I have clipping implemented so that it only costs five 16bit adds or subtracts per vertex and one 8bit bitwise or per line to determine when clipping isn't necessary and as a result to not pay anything for it. Simon Cooke: thanks for the link, obviously I'll have to read it before I can comment properly. Have you ever implemented whatever it suggests? On Sun, Jun 1, 2008 at 11:59 PM, Tobermory <[EMAIL PROTECTED]> wrote: > Looks really good if you ask me. In answer to your question a few days ago: > >>Did you produce any demos with Open3d that I could just load up and > view, without having to assemble? > > I think you're mistaking me for a proper coder!!! I never produced anything > worthwhile from it - decided I'd obviously bitten off more than I could > chew. In OPENtest.S there are a few little demos though - some rotation, > and a speed test. Wanted to see if I could ever get an acceptable > framerate, and it ran one object at about 25fps. I'll have a crack at > translating them. > > The interesting thing about your Eli
Re: Attempts at 3d on the Sam?
; orthogonal...? Alternatively it might be the process of doing 3 axes of > rotation each frame. > > The view frustum clipping is very impressive, as I was going for speed I > didn't even consider printing a polygon that didn't fall in front of the > camera, although I knew that would eventually cause problems if I tried to > render any suitably massive object that could be partially visible but also > fall partially behind the camera. > >> I didn't own COMET back in the day, don't have a way to transfer disks to > disk images anyway, and World of Sam lists it as "not yet approved" for > distribution. > > David's cross assembler looks amazing, I'll definitely have to check out > moving some large projects over. It would be nice to finish some of these > projects lying around(!) > > Howard > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Thomas Harte > Sent: 01 June 2008 19:54 > To: sam-users@nvg.ntnu.no > Subject: Re: Attempts at 3d on the Sam? > > I have nothing particularly interesting or new to say, but I've just > uploaded a couple more videos of my engine if anyone is interested. > One shows the current code running on a real Sam both with and without > a Mayhem accelerator (thanks to Colin Piggot for that one) and the > other shows the code running in Sim Coupe, but demonstrates the fact > that clipping works now and shows an object starting quite far away > and then moving towards the camera, so as to distinguish my code from > a limited-case demo effect. > > Real Sam, with and without Mayhem: > http://www.youtube.com/watch?v=4PDfVjsiBzY > Demo to show range, precision and clipping: > http://www.youtube.com/watch?v=s2P64_IiCZA > > On 29 May 2008, at 22:27, Tobermory wrote: > >> What version of O3D are you looking at? It looks like I mainly >> sorted it >> out in v 0.82. >> >> I went through pretty much the same process as you, considering a >> lookup >> table to be too time-costly if it was too large. It looks like I >> made a few >> odd choices as a result of trying to squash a perspective-correcting >> lookup >> table into a small space though, to its detriment: >> >> There are 128 X values ( -63 to 64) per Z=value, meaning even as >> close as >> possible to the camera (Z=0) the perspective correction would only be >> accurate to 2-pixel boundaries. I kept this accuracy for the Z-axis >> as >> well, so Z runs up to 1024 in steps of 2. 128 entries per X or Y >> value * >> 512 Z values = 65536 byte table. >> >> Makes sense so far, however this economy meant I couldn't use absolute >> values in the table, just offsets. So each entry is INT(RealX - >> CorrectedX). >> >> Not sure it's a great system because the size of the lookup table is >> unwieldy. The small range of values expected by the table meant a >> lot of >> messing around. If I was to repeat it I would probably look at >> using nice >> values in the equation >> NewX = OldX * S / (S + Z) >> >> You could easily make a table for the S/(S+Z) part - S is the >> perspective >> factor, and so would be unlikely to change frame-by-frame. >> (Although as the >> table might reasonably be 8-16K, this could be done at runtime, >> maybe go all >> 'fisheye lens' on one level...). The largest value here would be 1 >> and only >> if Z=0 is valid, if the view frustum puts the camera at Z=0 then >> it's not a >> problem. I'd keep this in 8.8 format, maybe even junk the whole >> number >> part. A quick on-paper tally says this might take up 150T-States. >> >> Next step is to work out a fast way of multiplying for the rest of the >> equation and the job's done. As you will be multiplying by n/256 >> this is a >> reasonable amount of My personal choice here would be to runs for a >> nice >> table again, but this time for a table of runnable code, not just >> values. >> Again, that's about another 100-150T-States. That would be an >> improvement >> on 2000 cycles you said at the beginning? >> >> >> Howard >> >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:owner-sam- >> [EMAIL PROTECTED] On >> Behalf Of Thomas Harte >> Sent: 27 May 2008 14:16 >> To: sam-users@nvg.ntnu.no >> Subject: Re: Attempts at 3d on the Sam? >> >> Just out of interest, having now checked it out - you mention on your >> Open3d disk that you were planning to implement 'perspective table
RE: Attempts at 3d on the Sam?
You might want to consider this method instead of a reciprocal table: http://swox.com/~tege/divcnst-pldi94.pdf See the book "Hacker's Delight" for a less opaque way of looking at this stuff :D Basically, though, it's a way of generating a table of constants that when multiplied with another value, is the same as division. Si -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Harte Sent: Thursday, May 29, 2008 4:34 PM To: sam-users@nvg.ntnu.no Subject: Re: Attempts at 3d on the Sam? I have 0.82 from NVG, though I've not strictly speaking been using it in that I haven't actually managed to make it do anything. Though closer inspection reveals that it offers to build new perspective tables rather than promising to implement them in a future version. I've also read your DOC files between then and now, albeit painfully using a quick 8 line BASIC program. The firs major difference between my engine and yours is that I don't use an 'S' variable. Z is always distance from the viewer, not distance from the screen. So my perspective transform is just: x' = 128 + 128*(x/z) y' = 96 + 96*(y/z) x and y range from -32768 to 32767 (well, -128 to 127 in fixed point) and z ranges from to 32767 (with similar fixed point proviso). I'm not persuaded that any less precise system is suitable for displaying multiple objects in the same world without resorting to Dead Wild Cat-style perspective cheats whereby objects have their own local perspective and then all vertices are scaled according to the distance of the object centre. A quick test of the obvious alternative projection scheme: z' = 1/z x' = 128 + 128*x*z' y' = 96 + 96*y*z' Makes me think that trying to wring out reciprocals with the same 8.8 fixed point as elsewhere isn't going to be precise enough. Probably the solution is to create a reciprocal table there with a greater precision for z. Should only cost 64 kb, and will definitely be cheaper than 2000 cycles. Right now though my focus is on features, not speed. I'm maybe a few hundred lines away from having an Elite-class 3d engine - I just need to polish off the frustum clipping and that means implementing a 10x10- >20 bit multiplication routine and a 20x10->10 division routine. Though I already pretty much have those but they shuffle bytes in a way that I can't use at the clipping stage since they're thinking in fixed point and this bit of the code isn't (or rather, it's more accurate if it doesn't). And I don't think that divide is really amenable to anything tablewise in Samworld since I can't really afford to drop any accuracy in clipping, obviously. Did you produce any demos with Open3d that I could just load up and view, without having to assemble? I didn't own COMET back in the day, don't have a way to transfer disks to disk images anyway, and World of Sam lists it as "not yet approved" for distribution. On 29 May 2008, at 22:27, Tobermory wrote: > What version of O3D are you looking at? It looks like I mainly > sorted it > out in v 0.82. > > I went through pretty much the same process as you, considering a > lookup > table to be too time-costly if it was too large. It looks like I > made a few > odd choices as a result of trying to squash a perspective-correcting > lookup > table into a small space though, to its detriment: > > There are 128 X values ( -63 to 64) per Z=value, meaning even as > close as > possible to the camera (Z=0) the perspective correction would only be > accurate to 2-pixel boundaries. I kept this accuracy for the Z-axis > as > well, so Z runs up to 1024 in steps of 2. 128 entries per X or Y > value * > 512 Z values = 65536 byte table. > > Makes sense so far, however this economy meant I couldn't use absolute > values in the table, just offsets. So each entry is INT(RealX - > CorrectedX). > > Not sure it's a great system because the size of the lookup table is > unwieldy. The small range of values expected by the table meant a > lot of > messing around. If I was to repeat it I would probably look at > using nice > values in the equation > NewX = OldX * S / (S + Z) > > You could easily make a table for the S/(S+Z) part - S is the > perspective > factor, and so would be unlikely to change frame-by-frame. > (Although as the > table might reasonably be 8-16K, this could be done at runtime, > maybe go all > 'fisheye lens' on one level...). The largest value here would be 1 > and only > if Z=0 is valid, if the view frustum puts the camera at Z=0 then > it's not a > problem. I'd keep this in 8.8 format, maybe even junk th
RE: Attempts at 3d on the Sam?
Looks really good if you ask me. In answer to your question a few days ago: >Did you produce any demos with Open3d that I could just load up and view, without having to assemble? I think you're mistaking me for a proper coder!!! I never produced anything worthwhile from it - decided I'd obviously bitten off more than I could chew. In OPENtest.S there are a few little demos though - some rotation, and a speed test. Wanted to see if I could ever get an acceptable framerate, and it ran one object at about 25fps. I'll have a crack at translating them. The interesting thing about your Elite rotation vid is that it seems a lot less accurate than I'd expect, does the brackets in your perspective equation x' = 128 + 128*(x/z) mean you're doing the x/z first? It seems smoother in the clipping vid although that might be just because the planes in the cube object are more orthogonal...? Alternatively it might be the process of doing 3 axes of rotation each frame. The view frustum clipping is very impressive, as I was going for speed I didn't even consider printing a polygon that didn't fall in front of the camera, although I knew that would eventually cause problems if I tried to render any suitably massive object that could be partially visible but also fall partially behind the camera. > I didn't own COMET back in the day, don't have a way to transfer disks to disk images anyway, and World of Sam lists it as "not yet approved" for distribution. David's cross assembler looks amazing, I'll definitely have to check out moving some large projects over. It would be nice to finish some of these projects lying around(!) Howard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Harte Sent: 01 June 2008 19:54 To: sam-users@nvg.ntnu.no Subject: Re: Attempts at 3d on the Sam? I have nothing particularly interesting or new to say, but I've just uploaded a couple more videos of my engine if anyone is interested. One shows the current code running on a real Sam both with and without a Mayhem accelerator (thanks to Colin Piggot for that one) and the other shows the code running in Sim Coupe, but demonstrates the fact that clipping works now and shows an object starting quite far away and then moving towards the camera, so as to distinguish my code from a limited-case demo effect. Real Sam, with and without Mayhem: http://www.youtube.com/watch?v=4PDfVjsiBzY Demo to show range, precision and clipping: http://www.youtube.com/watch?v=s2P64_IiCZA On 29 May 2008, at 22:27, Tobermory wrote: > What version of O3D are you looking at? It looks like I mainly > sorted it > out in v 0.82. > > I went through pretty much the same process as you, considering a > lookup > table to be too time-costly if it was too large. It looks like I > made a few > odd choices as a result of trying to squash a perspective-correcting > lookup > table into a small space though, to its detriment: > > There are 128 X values ( -63 to 64) per Z=value, meaning even as > close as > possible to the camera (Z=0) the perspective correction would only be > accurate to 2-pixel boundaries. I kept this accuracy for the Z-axis > as > well, so Z runs up to 1024 in steps of 2. 128 entries per X or Y > value * > 512 Z values = 65536 byte table. > > Makes sense so far, however this economy meant I couldn't use absolute > values in the table, just offsets. So each entry is INT(RealX - > CorrectedX). > > Not sure it's a great system because the size of the lookup table is > unwieldy. The small range of values expected by the table meant a > lot of > messing around. If I was to repeat it I would probably look at > using nice > values in the equation > NewX = OldX * S / (S + Z) > > You could easily make a table for the S/(S+Z) part - S is the > perspective > factor, and so would be unlikely to change frame-by-frame. > (Although as the > table might reasonably be 8-16K, this could be done at runtime, > maybe go all > 'fisheye lens' on one level...). The largest value here would be 1 > and only > if Z=0 is valid, if the view frustum puts the camera at Z=0 then > it's not a > problem. I'd keep this in 8.8 format, maybe even junk the whole > number > part. A quick on-paper tally says this might take up 150T-States. > > Next step is to work out a fast way of multiplying for the rest of the > equation and the job's done. As you will be multiplying by n/256 > this is a > reasonable amount of My personal choice here would be to runs for a > nice > table again, but this time for a table of runnable code, not just > values. > Again, that's about another 100-150T-States. That would b
Re: Attempts at 3d on the Sam?
I have nothing particularly interesting or new to say, but I've just uploaded a couple more videos of my engine if anyone is interested. One shows the current code running on a real Sam both with and without a Mayhem accelerator (thanks to Colin Piggot for that one) and the other shows the code running in Sim Coupe, but demonstrates the fact that clipping works now and shows an object starting quite far away and then moving towards the camera, so as to distinguish my code from a limited-case demo effect. Real Sam, with and without Mayhem: http://www.youtube.com/watch?v=4PDfVjsiBzY Demo to show range, precision and clipping: http://www.youtube.com/watch?v=s2P64_IiCZA On 29 May 2008, at 22:27, Tobermory wrote: What version of O3D are you looking at? It looks like I mainly sorted it out in v 0.82. I went through pretty much the same process as you, considering a lookup table to be too time-costly if it was too large. It looks like I made a few odd choices as a result of trying to squash a perspective-correcting lookup table into a small space though, to its detriment: There are 128 X values ( -63 to 64) per Z=value, meaning even as close as possible to the camera (Z=0) the perspective correction would only be accurate to 2-pixel boundaries. I kept this accuracy for the Z-axis as well, so Z runs up to 1024 in steps of 2. 128 entries per X or Y value * 512 Z values = 65536 byte table. Makes sense so far, however this economy meant I couldn't use absolute values in the table, just offsets. So each entry is INT(RealX - CorrectedX). Not sure it's a great system because the size of the lookup table is unwieldy. The small range of values expected by the table meant a lot of messing around. If I was to repeat it I would probably look at using nice values in the equation NewX = OldX * S / (S + Z) You could easily make a table for the S/(S+Z) part - S is the perspective factor, and so would be unlikely to change frame-by-frame. (Although as the table might reasonably be 8-16K, this could be done at runtime, maybe go all 'fisheye lens' on one level...). The largest value here would be 1 and only if Z=0 is valid, if the view frustum puts the camera at Z=0 then it's not a problem. I'd keep this in 8.8 format, maybe even junk the whole number part. A quick on-paper tally says this might take up 150T-States. Next step is to work out a fast way of multiplying for the rest of the equation and the job's done. As you will be multiplying by n/256 this is a reasonable amount of My personal choice here would be to runs for a nice table again, but this time for a table of runnable code, not just values. Again, that's about another 100-150T-States. That would be an improvement on 2000 cycles you said at the beginning? Howard -Original Message- From: [EMAIL PROTECTED] [mailto:owner-sam- [EMAIL PROTECTED] On Behalf Of Thomas Harte Sent: 27 May 2008 14:16 To: sam-users@nvg.ntnu.no Subject: Re: Attempts at 3d on the Sam? Just out of interest, having now checked it out - you mention on your Open3d disk that you were planning to implement 'perspective tables'. Can I enquire as to what form they were intended to take? I briefly contemplated a lookup table, indexed by 15 bit depth (my values are signed, but obviously points with negative z are never projected since they never appear) to produce a 2 byte fixed point reciprocal value, but it seemed I'd probably need to spend 15 bits on the fractional part to get decent precision, putting me in the realm of then having to do at least a 16x16 -> 32 multiply and pushing me towards the point where throwing 128 kb of RAM at the problem doesn't buy a justifiably large speed increase. On Tue, Apr 8, 2008 at 6:53 PM, Tobermory <[EMAIL PROTECTED]> 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... Howard (=Tobermory) -Original Message- From: [EMAIL PROTECTED] [mailto:owner-sam- [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 se
Re: Attempts at 3d on the Sam?
You can also import comet source directly into Jam Assember from a SAM disk image or file. Dave Jam Assembler download http://myweb.tiscali.co.uk/stoneddesign - Original Message - From: "Andrew Collier" <[EMAIL PROTECTED]> To: Sent: Friday, May 30, 2008 10:39 AM Subject: Re: Attempts at 3d on the Sam? On 30 May 2008, at 00:33, Thomas Harte wrote: Did you produce any demos with Open3d that I could just load up and view, without having to assemble? I didn't own COMET back in the day, don't have a way to transfer disks to disk images anyway, and World of Sam lists it as "not yet approved" for distribution. Hi, It looks like Comet is available from Edwin's own website here: http://www.samcoupe-pro-dos.co.uk/edwin/software/comet/comet.htm Edwin - i would it be okay by you, if I enable the download on WOS as well? Cheers, Andrew -- --- Andrew Collier http://www.intensity.org.uk/ --- --
Re: Attempts at 3d on the Sam?
On Fri, May 30, 2008 at 03:11:07PM +0200, Edwin Blink wrote: > >Edwin - i would it be okay by you, if I enable the download on WOS as > >well? > > Go ahead you have my permission. Thanks! The Comet page on WOS has been duly updated. Cheers, Andrew -- --- Andrew Collier http://www.intensity.org.uk/ --- -- r<2+ T<4* cSEL dMS hEn/CB
Re: Attempts at 3d on the Sam?
- Original Message - From: "Andrew Collier" <[EMAIL PROTECTED]> Edwin - i would it be okay by you, if I enable the download on WOS as well? Go ahead you have my permission. Edwin
Re: Attempts at 3d on the Sam?
On 30 May 2008, at 00:33, Thomas Harte wrote: Did you produce any demos with Open3d that I could just load up and view, without having to assemble? I didn't own COMET back in the day, don't have a way to transfer disks to disk images anyway, and World of Sam lists it as "not yet approved" for distribution. Hi, It looks like Comet is available from Edwin's own website here: http://www.samcoupe-pro-dos.co.uk/edwin/software/comet/comet.htm Edwin - i would it be okay by you, if I enable the download on WOS as well? Cheers, Andrew -- --- Andrew Collier http://www.intensity.org.uk/ --- --
Re: Attempts at 3d on the Sam?
I have 0.82 from NVG, though I've not strictly speaking been using it in that I haven't actually managed to make it do anything. Though closer inspection reveals that it offers to build new perspective tables rather than promising to implement them in a future version. I've also read your DOC files between then and now, albeit painfully using a quick 8 line BASIC program. The firs major difference between my engine and yours is that I don't use an 'S' variable. Z is always distance from the viewer, not distance from the screen. So my perspective transform is just: x' = 128 + 128*(x/z) y' = 96 + 96*(y/z) x and y range from -32768 to 32767 (well, -128 to 127 in fixed point) and z ranges from to 32767 (with similar fixed point proviso). I'm not persuaded that any less precise system is suitable for displaying multiple objects in the same world without resorting to Dead Wild Cat-style perspective cheats whereby objects have their own local perspective and then all vertices are scaled according to the distance of the object centre. A quick test of the obvious alternative projection scheme: z' = 1/z x' = 128 + 128*x*z' y' = 96 + 96*y*z' Makes me think that trying to wring out reciprocals with the same 8.8 fixed point as elsewhere isn't going to be precise enough. Probably the solution is to create a reciprocal table there with a greater precision for z. Should only cost 64 kb, and will definitely be cheaper than 2000 cycles. Right now though my focus is on features, not speed. I'm maybe a few hundred lines away from having an Elite-class 3d engine — I just need to polish off the frustum clipping and that means implementing a 10x10- >20 bit multiplication routine and a 20x10->10 division routine. Though I already pretty much have those but they shuffle bytes in a way that I can't use at the clipping stage since they're thinking in fixed point and this bit of the code isn't (or rather, it's more accurate if it doesn't). And I don't think that divide is really amenable to anything tablewise in Samworld since I can't really afford to drop any accuracy in clipping, obviously. Did you produce any demos with Open3d that I could just load up and view, without having to assemble? I didn't own COMET back in the day, don't have a way to transfer disks to disk images anyway, and World of Sam lists it as "not yet approved" for distribution. On 29 May 2008, at 22:27, Tobermory wrote: What version of O3D are you looking at? It looks like I mainly sorted it out in v 0.82. I went through pretty much the same process as you, considering a lookup table to be too time-costly if it was too large. It looks like I made a few odd choices as a result of trying to squash a perspective-correcting lookup table into a small space though, to its detriment: There are 128 X values ( -63 to 64) per Z=value, meaning even as close as possible to the camera (Z=0) the perspective correction would only be accurate to 2-pixel boundaries. I kept this accuracy for the Z-axis as well, so Z runs up to 1024 in steps of 2. 128 entries per X or Y value * 512 Z values = 65536 byte table. Makes sense so far, however this economy meant I couldn't use absolute values in the table, just offsets. So each entry is INT(RealX - CorrectedX). Not sure it's a great system because the size of the lookup table is unwieldy. The small range of values expected by the table meant a lot of messing around. If I was to repeat it I would probably look at using nice values in the equation NewX = OldX * S / (S + Z) You could easily make a table for the S/(S+Z) part - S is the perspective factor, and so would be unlikely to change frame-by-frame. (Although as the table might reasonably be 8-16K, this could be done at runtime, maybe go all 'fisheye lens' on one level...). The largest value here would be 1 and only if Z=0 is valid, if the view frustum puts the camera at Z=0 then it's not a problem. I'd keep this in 8.8 format, maybe even junk the whole number part. A quick on-paper tally says this might take up 150T-States. Next step is to work out a fast way of multiplying for the rest of the equation and the job's done. As you will be multiplying by n/256 this is a reasonable amount of My personal choice here would be to runs for a nice table again, but this time for a table of runnable code, not just values. Again, that's about another 100-150T-States. That would be an improvement on 2000 cycles you said at the beginning? Howard -Original Message----- From: [EMAIL PROTECTED] [mailto:owner-sam- [EMAIL PROTECTED] On Behalf Of Thomas Harte Sent: 27 May 2008 14:16 To: sam-users@nvg.ntnu.no Subject: Re: Attempts at 3d on the Sam? Just out of interest, havin
RE: Attempts at 3d on the Sam?
What version of O3D are you looking at? It looks like I mainly sorted it out in v 0.82. I went through pretty much the same process as you, considering a lookup table to be too time-costly if it was too large. It looks like I made a few odd choices as a result of trying to squash a perspective-correcting lookup table into a small space though, to its detriment: There are 128 X values ( -63 to 64) per Z=value, meaning even as close as possible to the camera (Z=0) the perspective correction would only be accurate to 2-pixel boundaries. I kept this accuracy for the Z-axis as well, so Z runs up to 1024 in steps of 2. 128 entries per X or Y value * 512 Z values = 65536 byte table. Makes sense so far, however this economy meant I couldn't use absolute values in the table, just offsets. So each entry is INT(RealX - CorrectedX). Not sure it's a great system because the size of the lookup table is unwieldy. The small range of values expected by the table meant a lot of messing around. If I was to repeat it I would probably look at using nice values in the equation NewX = OldX * S / (S + Z) You could easily make a table for the S/(S+Z) part - S is the perspective factor, and so would be unlikely to change frame-by-frame. (Although as the table might reasonably be 8-16K, this could be done at runtime, maybe go all 'fisheye lens' on one level...). The largest value here would be 1 and only if Z=0 is valid, if the view frustum puts the camera at Z=0 then it's not a problem. I'd keep this in 8.8 format, maybe even junk the whole number part. A quick on-paper tally says this might take up 150T-States. Next step is to work out a fast way of multiplying for the rest of the equation and the job's done. As you will be multiplying by n/256 this is a reasonable amount of My personal choice here would be to runs for a nice table again, but this time for a table of runnable code, not just values. Again, that's about another 100-150T-States. That would be an improvement on 2000 cycles you said at the beginning? Howard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Harte Sent: 27 May 2008 14:16 To: sam-users@nvg.ntnu.no Subject: Re: Attempts at 3d on the Sam? Just out of interest, having now checked it out - you mention on your Open3d disk that you were planning to implement 'perspective tables'. Can I enquire as to what form they were intended to take? I briefly contemplated a lookup table, indexed by 15 bit depth (my values are signed, but obviously points with negative z are never projected since they never appear) to produce a 2 byte fixed point reciprocal value, but it seemed I'd probably need to spend 15 bits on the fractional part to get decent precision, putting me in the realm of then having to do at least a 16x16 -> 32 multiply and pushing me towards the point where throwing 128 kb of RAM at the problem doesn't buy a justifiably large speed increase. On Tue, Apr 8, 2008 at 6:53 PM, Tobermory <[EMAIL PROTECTED]> 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... > > 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,
Re: Attempts at 3d on the Sam?
Just out of interest, having now checked it out - you mention on your Open3d disk that you were planning to implement 'perspective tables'. Can I enquire as to what form they were intended to take? I briefly contemplated a lookup table, indexed by 15 bit depth (my values are signed, but obviously points with negative z are never projected since they never appear) to produce a 2 byte fixed point reciprocal value, but it seemed I'd probably need to spend 15 bits on the fractional part to get decent precision, putting me in the realm of then having to do at least a 16x16 -> 32 multiply and pushing me towards the point where throwing 128 kb of RAM at the problem doesn't buy a justifiably large speed increase. On Tue, Apr 8, 2008 at 6:53 PM, Tobermory <[EMAIL PROTECTED]> 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... > > 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?
...er. "Unrealistic at a 21st Century framerate" is probably the correct elaboration. Freescape was fun, sure. I expect someone could do a pretty fabulous conversion of Sentinel or something. By the way - never did get any screenshots of O3D, although it would do some nice stuff at the time - it let me run around some blocks and stuff. I'll see whether anything's still working with it. Howard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Harte Sent: 09 April 2008 23:45 To: sam-users@nvg.ntnu.no Subject: Re: Attempts at 3d on the Sam? I don't see how a Freescape-style engine for the Sam is technically unrealistic. Please elaborate. On 9 Apr 2008, at 22:19, Aleš Keprt wrote: > Guys, please be realistic. 3D on Sam sucks. > /--- > Aley > > -- > > - Original Message - From: "Thomas Harte" <[EMAIL PROTECTED] > > > To: > Sent: Tuesday, April 08, 2008 3:35 PM > Subject: 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. > No virus found in this incoming message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.11/1368 - Release Date: 09/04/2008 16:20 No virus found in this outgoing message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date: 12/04/2008 11:32
Re: Attempts at 3d on the Sam?
Right. Nice troll. Stratosphere looks pretty good though eh? On 09/04/2008, Aleš Keprt <[EMAIL PROTECTED]> wrote: > > Guys, please be realistic. 3D on Sam sucks. > /--- > Aley > > -- > > - Original Message - From: "Thomas Harte" < > [EMAIL PROTECTED]> > To: > Sent: Tuesday, April 08, 2008 3:35 PM > Subject: 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?
You know that mayhem will open a few new possibilities ;) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Harte Sent: 10 April 2008 00:00 To: Adrian Subject: Re: Attempts at 3d on the Sam? I don't see how a Freescape-style engine for the Sam is technically unrealistic. Please elaborate. On 9 Apr 2008, at 22:19, Aleš Keprt wrote: > Guys, please be realistic. 3D on Sam sucks. > /--- > Aley > > -- > > - Original Message - From: "Thomas Harte" <[EMAIL PROTECTED] > > > To: > Sent: Tuesday, April 08, 2008 3:35 PM > Subject: 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. > APB Computer Services Ltd. Registered Address: 3 Springfield, Trevadlock, Congdons Shop, Launceston, Cornwall, PL15 7PW. Registration Number: 4942193. V.A.T. No: 826 0005 70 This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Re: Attempts at 3d on the Sam?
I don't see how a Freescape-style engine for the Sam is technically unrealistic. Please elaborate. On 9 Apr 2008, at 22:19, Aleš Keprt wrote: Guys, please be realistic. 3D on Sam sucks. /--- Aley -- - Original Message - From: "Thomas Harte" <[EMAIL PROTECTED] > To: Sent: Tuesday, April 08, 2008 3:35 PM Subject: 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?
Guys, please be realistic. 3D on Sam sucks. /--- Aley -- - Original Message - From: "Thomas Harte" <[EMAIL PROTECTED]> To: Sent: Tuesday, April 08, 2008 3:35 PM Subject: 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?
I'd not seen that demo previously. What is it using all that memory for? From the description of the tables being pretty easy to generate, it makes it sound like some of the 3d positioning is precalculated, but then he seems to think that he'd be able to save a lot of memory if he didn't have the speed of mode 4 pixel plotting to deal with. So maybe it's [parts of] the line drawing code? On 9 Apr 2008, at 01:49, Andrew Collier wrote: 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/ --- --
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/ --- --
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?
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?
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?
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?
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
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/
