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). >> >> You know when you load a Spectrum game from tape, the title screen >> almost always loads as the first line, then the 8th, then the 16th, >> then eventually it jumps back up and adds in the 2nd, then the 9th, >> etc, it does that pattern once for each third of the screen and then >> finally the colours appear? That's because that's the order video >> memory is laid out in on a Spectrum. >> >> I've never seen an explanation as to why. But the individual scanlines >> are still linear, so it tends not to cause substantial difficulty and, >> conveniently, means it's usually easy to convert code from Mode 1 to 2 >> — often by removing a lookup table reference or a small chunk. >> >> On Wed, May 26, 2010 at 1:43 PM, Roger Jowett <rogerjow...@gmail.com> wrote: >>> does that mean that mode one reoutines might work in mode 2 then? >>> >>> On 25 May 2010 21:04, Thomas Harte <tomh.retros...@gmail.com> wrote: >>>> 3d data isn't graphics mode dependant like 2d data, but also doesn't >>>> have any particular common layout so it's really difficult to pull >>>> from existing titles. That's in contrast to 2d data, since you pretty >>>> much always store that in the format it would need to be in video >>>> memory in order to appear on screen. >>>> >>>> I'm using a standard Bresenham drawer (ie, each pixel it asks itself >>>> 'should I continue straight or is this a stair step?') so in principle >>>> Mode 3 would cost more. I've never been able to decide whether a run >>>> length Bresenham drawer (which is one 8 bit divide, but then the >>>> decision is 'is this run n pixels or n+1' so you save a lot on the >>>> journey across — and this explicitly isn't a fixed point DDA method) >>>> would be faster in principle. I guess you'd ideally switch from one to >>>> the other depending on line length. If so, then obviously that would >>>> help in Mode 3 where lines are, on average, twice as long in pixels. >>>> >>>> In the code I've just released, change the line drawer in >>>> drawline.z80s and then the constants on lines 661, 663 and 145 to >>>> implement an alternative graphics mode. >>>> >>>> On Tue, May 25, 2010 at 4:34 PM, Roger Jowett <rogerjow...@gmail.com> >>>> wrote: >>>>> impossible to use your routines to pluck 3d data for objects from >>>>> other 48 softwrae loaded as a snapshot into ram? you couldnt use such >>>>> a method to add a 3d part to the +d hacker/softcrack 9 multiface and >>>>> +d sopftware they seemed to have sprite grabbers for 2d stuff only >>>>> nohting for 3d - something like the starglider when docked the >>>>> computer offers a selection of all the 3d stuff in the game for >>>>> viewing? would be nice for others though the 48 would store >>>>> coordinates for only mode 1 viewing? or does coordinate system not >>>>> matter which mode the object is displayed in? >>>>> do your routines work as fast in mode3? do you need to double the >>>>> horizontal size in order to get around the rediculous fatpix cirlce >>>>> fix? >>>>> >>>>> On 25 May 2010 16:29, Thomas Harte <tomh.retros...@gmail.com> wrote: >>>>>> Nope, shouldn't be. I've not done anything particularly clever >>>>>> anywhere. I think there's some minor dynamic reprogramming, but not >>>>>> beyond changing constants attached to immediate operations. >>>>>> >>>>>> That said, I can release the source tonight as I always intended to. >>>>>> The only problem is that the attached documentation doesn't quite >>>>>> document the internal formats for a model, etc. There's a full >>>>>> breakdown of the memory model employed and the supplied methods to >>>>>> call to do different things, along with the demo as on the most recent >>>>>> Sam Revival as an example program (though I'll chop that down a bit), >>>>>> you're just left dangling if you want to add any additional 3d models
