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 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 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 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 >>> >>> >>> >> > > >
