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