I would be _hugely_ surprised if my code was anywhere near as fast as code could be. I would be similarly surprised if I ever run out of ideas for making it faster, at least with the amount of time I ever have for trying these ideas.
I recall having to buy a new membrane for my Sam back in the day... given that the original Sam I had also stopped outputting in colour at one point, I do wonder about the build quality. For the record, I'm actually quite knowledegable on some bits of Freescape, having written an OpenGL version that accepts original 3d Construction Kit files. Apart from the obvious stuff of being filled versus empty, a major difference is that the entire scene in Freescape uses 8 bit coordinates. So there's a limited precision on shapes and placement — my code uses 2.8 format for individual models and places them in a 16bit space, giving a much larger play area and precision on individual objects. I also allow individual objects to have local transformations (so, e.g., a ship may rotate on the spot independently of whatever the camera is doing). In Freescape everything is completely fixed. You actually gain quite a lot from completely fixed objects. Because you've no matrix composition step, precision is much less of a problem. The eye space coordinates of each point in my engine are the scalar combination of the result of three sets of four multiplications. The eye space coordinates of each point in Freescape are calculated with only three multiplications in total. In my engine most of the multiplications are done once per model rather than once per vertex as a natural consequence of matrix composition, but problems with accuracy nevertheless require larger fields to be thrown at the problem. I've never looked at the original code, but I'll bet Freescape uses 8bit matrix entries and a 512 byte f(x) = (x^2)/4 table with x in 8bit and f(x) 16bit, meaning that the transform from object to eye space is extremely cheap. And neatly set up for the weird addressing modes of 6502s. That all being said, I want to get the best performance because I want to have done the best job I can. That being said, writing the code is obviously just for the puzzle solving fun, so stealing someone else's code wouldn't really be useful. On Fri, May 28, 2010 at 3:40 PM, Roger Jowett <[email protected]> wrote: > http://www.worldofspectrum.org/infoseek.cgi?regexp=^Freescape$&phrase&loadpics=1 > > freescapes are all here and look mostly 48 > pity tthe search criteria cant handle more than one option... > > On 28 May 2010 15:37, Roger Jowett <[email protected]> wrote: >> chris asked me to delete the ix and iy from the lemmings code! >> it would have taken me years! mind you my sam keybaord membrane was >> wokring in 92! now i have atom lite and no keybaord membrane working >> from 3 machines! >> you seem to be optimising your 3d routines >> were there any 48 routines that are faster there was so much 3d >> software on the 48: full list from wos >> >> http://www.worldofspectrum.org/infoseek.cgi?regexp=^Vector+Graphics$&phrase&loadpics=1 >> >> elite 3? >> http://www.worldofspectrum.org/infoseek.cgi?regexp=^Elite+3+Novosibirsk$&pub=^Shadow+Soft$&loadpics=1 >> >> someones taking the mikey?! >> >> was thinking along the lines of >> artic 3d combat zone >> melbourne starion >> crl tau ceti >> nexus micronaut one >> rainbird/firebird starglider1&2 carrier command elite >> ocean battle command >> realtime starstrike 1&2 >> mikrosphere sky ranger >> electric dream i of the mask >> microprose f15 project stealth fighterf19 gunship >> novagen mercenary &escape from targ >> activision fighter bomber >> and ofcourse digital integration >> >> velesoft reckon the external ram mb gives sam control over a single >> 16kb page i thought the hmpr controlled the external ram port but >> there doesnt seem toeb anything in the technicial manual about how to >> page it - other than it would page in the same way as teh internal >> ram? >> >> 28 May 2010 12:19, Thomas Harte <[email protected]> wrote: >>> Actually, 3 or 4 for the cube, now I think about it. But you get the >>> point. Always nicer when you realise that what you're doing exactly >>> fits an extremely well-documented and well-known data structure and >>> algorithm. >>> >>> On Fri, May 28, 2010 at 8:54 AM, Thomas Harte <[email protected]> >>> wrote: >>>> I had one further thought on this overnight: if you expand the planes >>>> bounding a convex object out to infinity then you get a series of >>>> convex cells surrounding the object. Which cell you're in exactly >>>> determines which faces you can see and the natural way to figure out >>>> which convex cell a player is in is a BSP tree. So you could reduce >>>> the face visibility check from its current linear time to logarithmic >>>> time - 5 or 6 checks for the Cobra Mk 3 (the most complicated model >>>> I've tried) rather than 30 odd and always 3 rather than 6 for the cube >>>> (the simplest). >>>> >>>> It definitely helps to talk about this stuff... >>>> >>>> On Thursday, May 27, 2010, Thomas Harte <[email protected]> wrote: >>>>> My own routine. It's in the drawline.z80s file, and it should be safe >>>>> to swap it out for any other function as long as it accepts the same >>>>> input and leaves the same registers intact (I think just IX and IY, >>>>> but go with whatever the comment in that file says rather than what >>>>> I'm saying now). >>>>> >>>>> My understanding was that the way that they've generalised the pixel >>>>> plotting step to support different drawing modes and to do viewport >>>>> testing within the line routine means that the ROM routines would be >>>>> slower than my RAM routines. My routines benefit from only ever doing >>>>> one of two things: >>>>> >>>>> - drawing a solid, single pixel wide line that is definitely entirely >>>>> on the screen (ie, no need to test per pixel) >>>>> - erase an old line, being allowed also to blank out any other pixels >>>>> the routine feels like (which in practice means that it calculates the >>>>> correct (x, y) for each pixel then just zeroes that byte in video >>>>> memory, actually blanking two pixels) >>>>> >>>>> The latter could probably be faster if you halved the notional x >>>>> resolution in which you're drawing and blanked out four pixels rather >>>>> than two (to deal with occasions when the rounded version pixels the >>>>> byte one to the side of the one that the non-rounded routine would >>>>> have picked). I haven't experimented there. >>>>> >>>>> On Thu, May 27, 2010 at 3:19 PM, Roger Jowett <[email protected]> >>>>> wrote: >>>>>> how are lines drawn using rom routine or your own? >>>>>> >>>>>> On 27 May 2010 15:14, Thomas Harte <[email protected]> wrote: >>>>>>> Removing hidden line removal would save the time calculating face >>>>>>> visibility but then add to transformation and drawing costs. >>>>>>> >>>>>>> The code at present always does a calculation for every defined face, >>>>>>> always considers a calculation for every defined line and performs >>>>>>> calculations for vertices only if they are used as part of the model >>>>>>> as it is visible for that draw operation. Vertices that are connected >>>>>>> only to lines that aren't visible aren't transformed. >>>>>>> >>>>>>> If I were to rewrite it, I would adjust that so that, as a first >>>>>>> measure, a calculation is performed for every defined face but lines >>>>>>> that aren't connected to visible faces are never even considered. >>>>>>> That's not a massive win in performance terms because all it does for >>>>>>> lines at the minute is run through reading a couple of flags and >>>>>>> proceeding or discarding based on the combination of those. However, >>>>>>> if I were then able to add a broad phase to the face stuff* then it'd >>>>>>> really start to pay off down the hierarchy. >>>>>>> >>>>>>> * as in, a prepatory step that interrogates some sort of hierarchical >>>>>>> structure and hence discards large swathes of faces without doing a >>>>>>> calculation for each. Usually it saves time even if it is able to >>>>>>> reject, say, only 90% of invisible faces and then you have to do the >>>>>>> face-by-face tests on each of the remaining potentially visible set
