http://www.youtube.com/profile?user=rogerjowett#p/u/41/UEEh7qjACXw
are these figures anywhere near the actual ones i was trying to see whether it worked faster witht he screen off and the rom code or external ram... dont get the spectrum percentage or the mips at all thoguht 4mhz z80 was½mip dont think he has added the extra t state the sam adds to each instructiuon for no apparent reason?! 2009/10/20 Thomas Harte <[email protected]>: > I'm not sure about the squeezing them down to 8kb slices, but at least > in principle squeezing a vector-based Spectrum program onto the Sam > and switching it from Mode 1 to Mode 2 shouldn't be too difficult and > should give an instant frame rate boost. Though it'd probably be > easier with a 48k program than a 128k program. And obviously something > like Elite is the dream program to get working because it even > performs a software page flip. With all the latest emulators, etc, > I'll bet you could find something with a debugger that can trap on > VRAM writes, making locating the relevant code not too complicated. I > expect someone with more experience than me must be on the list and > can advise properly. > > That all said, I guess it's a question of objectives. I hope it's not > too controversial to say that, for me, Sam programming — especially > now — is much more about solving puzzles than actually producing > anything. So porting existing titles through code hacks isn't a > similar activity at all. > > On Tue, Oct 20, 2009 at 11:56 AM, Roger Jowett <[email protected]> wrote: >> wouldnt it be easier to just convert the 128 software flight sims to >> sam first then figure out how to modify the 128k code to reside solely >> in the remaining 8kb after each screen page of ram then convert >> routines to use mode 2 - which shouldnt be too difficult seeing as >> mode 1 is very similar the only difference would be 8 times as many >> attribute adjustments... >> >> 2009/10/19 Thomas Harte <[email protected]>: >>> I'm working on a proper, robust and fast polygon filler*, as well as >>> always looking to improve my line drawer, and have recently discovered >>> Bresenham's alternative run-slice algorithm, via a Michael Abrash >>> article published in Dr Dobbs in November '92. It switches you from >>> making a decision every pixel (eg, stepping along x, deciding whether >>> to make an adjustment in y after every pixel) to make a decision at >>> the end of every slice (so if you were drawing a line 256 pixels wide >>> and 2 pixels high, the first 128 pixels would be one slice that you >>> knew the length of before drawing, the next 128 would be another >>> slice; the length of every slice in a line varies by no more than 1 >>> pixel so that's the decision) at the cost of an 8bit by 8bit integer >>> divide with remainder outside the loop. >>> >>> This is explicitly still error tracking and proper integer arithmetic >>> ala per-pixel Bresenham, there are no fractional parts. This isn't DDA >>> in fixed point (which would be a much more than 8bit by 8bit integer >>> divide) or anything like that. >>> http://www.gamedev.net/reference/articles/article386.asp seems to be a >>> facsimile of the article, albeit with the figures and listings missing >>> somewhere. >>> >>> The way I see it, dividing costs less per bit than Bresenham does per >>> pixel (using, e.g. those restoring divide as demonstrated at >>> http://baze.au.com/misc/z80bits.html), so this could start costing >>> less even on very small lines. It'll almost definitely cost less for >>> polygon filling since you mainly want to know x intercept per >>> scanline, so I can switch between regular Bresenham and run slice >>> depending on the edge slope. With a 1/2 offset on the initial run of >>> the slicing algorithm (so I'm picking the centre pixel for every >>> slice), my C tests imply a great result with all the features you'd >>> like (adjacent polygons always exactly meet up, the switch from >>> per-pixel to run-slice isn't visible). >>> >>> That all said, I know I'm often hopelessly optimistic about these >>> things. Has anyone with more experience looked into and/or implemented >>> run-slice line drawing? >>> >>> * the one I used for my youtube videos leaves the occasional empty >>> pixel between adjacent polygons, is limited to triangles and uses >>> costly fixed-point division for every single edge. So: lots and lots >>> of unnecessary 16bit divides. >>> >> >
