i appreciate that a 512x384 video means that each frame woudl need to be converted into a mode 3 interlaced screen - maybe needing line interrupts and hmpr extra two bits for more than 4 colours onscreen although the mode 4 interlaced screens seemed to be more colour full thatn normal mode 4 screens
bmp2scr doesnt seem to save to a hdf atomlite comapct flash or hdrive file neither does retro X they just crash at the moment and take a long time to convert the 700mb video files - they dont use 64 bit processor architecture although i cant install the drivers for my pci tv tuners on 64 bit operating systesm xp vista or windows 7 have tried even the vga card from msi which ahs its own tv encoder on board the vga card - dont worry it is completely ignored byt he tv tuner software and teh vga tv encdoer software seems unable to handle the msi digital tv tuner despite needing an analog tuner in order to make any video at all - even with a 1.8ghz processor - not the 600mhz one mentioned ont he outsied of the box! the video jumps - pity they didnt put a couple of raid sata2 connectors on the video card and allowed the gpu&ram overclocking feature to affect the performance of the tv encoder! mind you you cant even use teh driver for the vga to encode desktop screencast video and thats on vgac ards that have tv encoders - so you have to feed the tv output back into the video input connector and hold your breath during the lovely bluscreen moments On 17 June 2010 13:27, Roger Jowett <rogerjow...@gmail.com> wrote: > 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 <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
