Freescape was everything available at the time — z80, 6502, 68000 and 8086. And it has a scripting language, with all game events handled by running the bytecode compiled output of that, though by Construction Kit time the model format and scripting language for the 16bit machines is almost entirely different to that for the 8bits. As I recall, there's one bytecode for games pre-Castle Master then another subsequently, so the split probably happened somewhere just before the development of that.
Freescape doesn't do networking... On Fri, May 28, 2010 at 4:24 PM, Roger Jowett <rogerjow...@gmail.com> wrote: > freescape was 6502? thoght the first version was cpc (not+!) > was 6502 1mhz equivalent to z80 at 4mhz? - what ahsame no one bothered > to add patches forthe 4mhz z80 in the fdd3k - or was the serial > interface 9600 baud like the interface 1/128k machines? > > so the r800 16 bit multiply would come in handy along with the lack of > four tstates to each instruction unless its come from the next 256kb > ram boundary - mind you the v9990 seems to have so much hardware > frippery - daft 125 hardware sprites scrolling and blitter - instead > of fixing the maximum bpp colour depth to 256 colours from a 24bit tru > colour palette but allowing a horizontal video ram page switch every > 256 pixels - could diplay 24bit tru colour screens with ¼ of teh video > ram of a pc with further video ram savings if there were less than 256 > different colours on each 256 pixel line of higher than 256 pixels per > horzontal line of the screen - not that it matters > pc seems to drop screen resolution when you run dxdiag for display > testing of textured box regardless of the lcd screen montiors fixed > video display mode - lcd screen quite happily displays a screen > reoslution too low for this monitor error message - infact most > emulators happily use older lower screen resolutions for full screen > simcoupe in a window when dragged off the left hand border of rthe > screen acyually squeezes the 3d vector stuff your routines are drawing > - seems kind of weird that overlays are not use to fix the screen > resolution at the lcd screens best mode and just use multiple pixels - > most 3d chipsets should be capable of doing this even if they cant be > bothered to include int he driver a routine for encoding to video the > desktop or a 3d app - especially when most of the vga cards i have > actually include a tv encoder chip on the vga! > > can your gl freescape network to a real sam using the pc gameport midi > network on the sam?/rs232 comms interface? > > On 28 May 2010 15:58, Thomas Harte <tomh.retros...@gmail.com> wrote: >> 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 <rogerjow...@gmail.com> 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 <rogerjow...@gmail.com> 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 <tomh.retros...@gmail.com> 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 <tomh.retros...@gmail.com> >>>>> 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 <tomh.retros...@gmail.com> 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 <rogerjow...@gmail.com> >>>>>>> wrote: >>>>>>>> how are lines drawn using rom routine or your own? >>>>>>>> >>>>>>>> On 27 May 2010 15:14, Thomas Harte <tomh.retros...@gmail.com> 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 >
