chris asked me to delete the ix and iy from the lemmings code! it would have taken me years! mind you my sam keybaord membrane was wokring in 92! now i have atom lite and no keybaord membrane working from 3 machines! you seem to be optimising your 3d routines were there any 48 routines that are faster there was so much 3d software on the 48: full list from wos
http://www.worldofspectrum.org/infoseek.cgi?regexp=^Vector+Graphics$&phrase&loadpics=1 elite 3? http://www.worldofspectrum.org/infoseek.cgi?regexp=^Elite+3+Novosibirsk$&pub=^Shadow+Soft$&loadpics=1 someones taking the mikey?! was thinking along the lines of artic 3d combat zone melbourne starion crl tau ceti nexus micronaut one rainbird/firebird starglider1&2 carrier command elite ocean battle command realtime starstrike 1&2 mikrosphere sky ranger electric dream i of the mask microprose f15 project stealth fighterf19 gunship novagen mercenary &escape from targ activision fighter bomber and ofcourse digital integration velesoft reckon the external ram mb gives sam control over a single 16kb page i thought the hmpr controlled the external ram port but there doesnt seem toeb anything in the technicial manual about how to page it - other than it would page in the same way as teh internal ram? 28 May 2010 12:19, Thomas Harte <tomh.retros...@gmail.com> wrote: > Actually, 3 or 4 for the cube, now I think about it. But you get the > point. Always nicer when you realise that what you're doing exactly > fits an extremely well-documented and well-known data structure and > algorithm. > > On Fri, May 28, 2010 at 8:54 AM, Thomas Harte <tomh.retros...@gmail.com> > wrote: >> I had one further thought on this overnight: if you expand the planes >> bounding a convex object out to infinity then you get a series of >> convex cells surrounding the object. Which cell you're in exactly >> determines which faces you can see and the natural way to figure out >> which convex cell a player is in is a BSP tree. So you could reduce >> the face visibility check from its current linear time to logarithmic >> time - 5 or 6 checks for the Cobra Mk 3 (the most complicated model >> I've tried) rather than 30 odd and always 3 rather than 6 for the cube >> (the simplest). >> >> It definitely helps to talk about this stuff... >> >> On Thursday, May 27, 2010, Thomas Harte <tomh.retros...@gmail.com> wrote: >>> 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 < >> >
