thanks for all your time sorry if my email bit incomprehensible - if you really want to struggle to understand i can translate to czeck for you maybe make my emails more 'fun'! sorry im using windows media player classic im playing video at full screen resolution of 512x384 - i understand this is not sam reoslution i then open the same file in virtual dub as retro x and bmp wont accept the avi file that debut screen capture program records:
http://www.nchsoftware.com/capture/support.html mpc: http://sourceforge.net/projects/guliverkli/ i convert with virtual dub : http://sourceforge.net/projects/virtualdub/files/virtualdub-win/1.9.9.32817/VirtualDub-1.9.9.zip/download i resave the avi file to old format avi or segmented avi just to get retro x and bmp2scre to load the file - at the moment it is crashing and there is a beeping sound im going to try the segmented version now is there a filesize limit? atom lite is available from sim coupe as hdf file you can create a bdos bootable atom lite+ compact flash or harddrive file - think the harddrives loose 50% of the size due to some 16bit multiplexing problem but its atechinicality overcome by readtiming so 128 lddr statements that is: 128x21=2688 t states without refresh added in and you have 128 bytes or one line of pixels you then need to repeat this 192 times so 192x2688=516096tstsates - and that is without the tstates for the loop code ld sp, data to me moved -first byte address of stored screen pop af, bc,de,hl, exaf, axx, pop af,bc,de,hl ld sp, destination address start address of screen location plus 16 - as push descends on stack which is now screen ram so we are goign backwards last first push hl,de,bc,af exaf,exx push hl,de,bc,af that is 16 bytes for 204 tstates the code takes 26 bytes 24576/16=1536 needs repeating 1536 times 1536x206 tstates =316416 199680tstates less than lddr? or am i dreaming? mind you 25frames per second 316416x25=7910400 = so we are needing at least the 7.1mhz of the r800 in the msx turbo r thanks to its ram loose the first four tstates from each instruciton unless it crosses a 256byte ram boundary! mind you we could cheat a bit... sim coupe plus on numeric keypad allows five frame skip if we display the same fram or interlaced frames for a duration of five frames that would give us five frames to trasnfer two frames which might be possible until someone codes a dma into sim coupe or figures out how to use the 25mhz microchipdma on the trinity interface - though it wont be working at 25mhz of course! exaf=4tstaets x2 = 8 exx=4tstates x2 =8 push 11 tstates x 8= 88 pop = 10 tstates x 8= 80 ld sp,nn=11 x2 = 22 206 tstates 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. >>>>>> I've never been 100% on the best, or even a necessarily suitable >>>>>> hierarchical form. >>>>>> >>>>>> On Thu, May 27, 2010 at 12:51 PM, Roger Jowett <[email protected]> >>>>>> wrote: >>>>>>> so no hidden line removal speeds things up a bit... >>>>>>> http://www.worldofspectrum.org/infoseekid.cgi?id=0003126 >>>>>>> theres a screen shot only the roads were solid line the objects seemed >>>>>>> to be dots and not hidden line either >>>>>>> think in th erooms things were all solid >>>>>>> can be seen better in this screen shot >>>>>>> >>>>>>> http://www.worldofspectrum.org/infoseek.cgi?regexp=^Mercenary%3a+The+Second+City$&pub=^Novagen+Software+Ltd$&loadpics=1 >>>>>>> >>>>>>> thought battle carrier command were pretty solid/shaded 3dnot vecotrs? >>>>>>> >>>>>>> On 27 May 2010 12:08, Thomas Harte <[email protected]> wrote: >>>>>>>> Without being able to answer on the Timex or the extent to which the >>>>>>>> RAM upgrade would benefit 128k emulation, was Mercenary the one where >>>>>>>> they appeared to be drawing on only every other scanline? It's >>>>>>>> possible I've merged it with Battle Command (filled polys, draws only >>>>>>>> every other line) in my memory. >>>>>>>> >>>>>>>> I'm not completely sure on the external RAM modules, but my >>>>>>>> understanding is that they're not contended at all, which would be a >>>>>>>> substantial speed improvement for the 3d calculation parts of this >>>>>>>> sort of code and some improvement to the pixel throwing. >>>>>>>> >>>>>>>> Technically my code can do display without hidden line removal, it's >>>>>>>> just a consequence of the algorithm rather than a deliberately >>>>>>>> designed feature. It's the Elite method, each line is considered a >>>>>>>> potential edge and connected to two faces. If either face is visible >>>>>>>> then the line is drawn. The links are pointers, so you'd set both >>>>>>>> pointers to a face that isn't connected as part of the model (so the >>>>>>>> code won't recalculate whether it is visible when you draw) and has >>>>>>>> the visibility flag set. >>>>>>>> >>>>>>>> On Thu, May 27, 2010 at 9:30 AM, Roger Jowett < >>> >> >
