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; | >>>>>> >>>>> >>>> >>> >> >
