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. >> >> 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 <rogerjow...@gmail.com> wrote: >>> is it difficult to disassmeble the 3d routines you made? >>> >>> >>> On 22 May 2010 17:58, Thomas Harte <tomh.retros...@gmail.com> 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ø <fr...@tennebo.com> wrote: >>>>> On Sun, 09 May 2010 23:04:53 +0200, Thomas Harte >>>>> <tomh.retros...@gmail.com> >>>>> 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: fr...@tennebo.com | fr...@irc ^ >>>>> | with Standard.Disclaimer; use Standard.Disclaimer; | >>>>> >>>> >>> >> >
