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 <[email protected]> wrote: > does that mean that mode one reoutines might work in mode 2 then? > > On 25 May 2010 21:04, Thomas Harte <[email protected]> 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 <[email protected]> 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 <[email protected]> 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. >>>> >>>> I had some C code I was using to build the models (you call add vertex >>>> and add face methods, it dumps assembly code for you), I'll see if I >>>> can find that. >>>> >>>> I think it's definitely right to stop just sitting here, even if it >>>> means releasing less than I'd have liked. >>>> >>>> And for the record, yes I'd do a much better job if I were starting >>>> again from scratch. >>>> >>>> On Tue, May 25, 2010 at 4:02 PM, Roger Jowett <[email protected]> >>>> wrote: >>>>> is it difficult to disassmeble the 3d routines you made? >>>>> >>>>> >>>>> On 22 May 2010 17:58, Thomas Harte <[email protected]> wrote: >>>>>> Having obtained a physical copy of the manual in the interim, it's a >>>>>> shame that none of the appendices are included. The datasheets are >>>>>> probably redundant, but Appendix C is Sam specific, with some useful >>>>>> bits like the key map. For the very first time I miss the automatic >>>>>> feed scanner that I had access to two works ago. >>>>>> >>>>>> I have to admit that re: the current online version, I may have been >>>>>> too quickly discouraged by the reference to 'HGT' on page 2, which >>>>>> made me think there might be a few vital 0s turned into 8s or vice >>>>>> versa. >>>>>> >>>>>> From a random check of three pages, I think you're right that most >>>>>> things that are amiss are obviously so in context such that the >>>>>> digital copy is a suitable substitute. Specifically, I checked: >>>>>> >>>>>> Page 52: an extra full stop has appeared after 'calculator memory 0-5 >>>>>> on' about halfway down the page, commonly has become 'comanonly' in >>>>>> the text below that. >>>>>> >>>>>> Page 73: system variable 'STRM16NM' is incorrectly named as >>>>>> 'STRMX6NN', 'PAGCOUNT' as 'PACCOUNT', 'BCREG' as 'ECREG', 'AUTOFLG' as >>>>>> 'AUTOFLO', 'MYCRD' as 'MYORD', lots of minor errors like 'hold' turned >>>>>> to 'bold', an 0 turned into an O, a word decapitalised, etc. >>>>>> >>>>>> Page 34: no errors. >>>>>> >>>>>> One I get access to a program that'll open the DOC file in the zip >>>>>> (I'm sure Microsoft Word would oblige) then I'll submit corrections. >>>>>> >>>>>> On Sun, May 9, 2010 at 10:39 PM, Frode Tennebø <[email protected]> wrote: >>>>>>> On Sun, 09 May 2010 23:04:53 +0200, Thomas Harte >>>>>>> <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Oh, I sort of wish you'd listed the technical manual separately. I >>>>>>>> know there's a PDF about on the internet but it has a few OCR-style >>>>>>>> typos so I'm a bit wary of it. And I can't find it now, making me >>>>>>>> think it may not be legitimate to circulate. >>>>>>> >>>>>>> You mean this one? >>>>>>> >>>>>>> ftp://ftp.nvg.ntnu.no/pub/sam-coupe/docs/manuals/software/SAM%20Coup%E9%20Technical%20Manual.zip >>>>>>> >>>>>>> There are probably typos, but I was not aware of anything major... >>>>>>> >>>>>>> -Frode >>>>>>> >>>>>>> -- >>>>>>> ^ Frode Tennebø | email: [email protected] | fr...@irc ^ >>>>>>> | with Standard.Disclaimer; use Standard.Disclaimer; | >>>>>>> >>>>>> >>>>> >>>> >>> >> >
