nothing does! not one emulator either
On 28 May 2010 16:41, Thomas Harte <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[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
