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. >> 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 <rogerjow...@gmail.com> 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 <tomh.retros...@gmail.com> 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 <rogerjow...@gmail.com> >>>> wrote: >>>>> did you see mercenary - the 3d stuff above ground was made up of dots >>>>> adn wasnt solid line removed - like starion just vectors without >>>>> hidden line removal(vu3d terminology! - mind you the shading took all >>>>> day on vu3d whereas 3d construciton kit managed to do it in 3-4 frames >>>>> possibly less with the dma from the mb-02+ - shame no one bothered >>>>> with the fdd3k had a 4mhz z80? but connected via serial interface - >>>>> assume it was faster than the interface 1 9600baud? dunno what the >>>>> sams comms interface was 19200?baud) >>>>> velesoft reckon the external 4mb has different paging to sam - can >>>>> page 16kb into last two ram pages CD of hmpr? there wasnt much info on >>>>> this in the technical manual but velesoft reckon it might help with >>>>> 128 conversion - i was thinking the sams extra ram could be filled >>>>> with every possible combination of pages that the 128 could have and >>>>> then the port out to change the ram page could be altered to the >>>>> single byte valu to include the two correct pages - this would mean >>>>> duplicating ram pages in the sams ram internal (external - might not >>>>> need to bother) >>>>> >>>>> >>>>> forgot about that - was that the case for the timex extra attribute >>>>> screen mode? or the 512x192 mode of the timex? >>>>> do you know if it had paper and colour settings for hi rez? >>>>> >>>>> On 26 May 2010 15:01, Thomas Harte <tomh.retros...@gmail.com> wrote: >>>>>> Mode 1 routines would very nearly work in Mode 2, the main difference >>>>>> being that Mode 2 has a linear pixel layout but Mode 1 replicates the >>>>>> order of the ZX Spectrum by switching some of the bits around. There's >>>>>> also a gap between the Mode 2 pixel data and the attribute data, >>>>>> whereas in Mode 1 the attribute data is immediately after the pixel >>>>>> data (and there's less of it too, per the attribute size differences)
