Oh, but it did also occur to me that I could create a convex-sector and vertical portal Wolfenstein-type thing for just an extra couple of multiplies per vertex. That'd mean you could use vectors to draw the outlines of walls but everything would be clipped so that there was no ability to see through walls; they'd look solid but all the same colour. The camera would need to be kept level anyway, so you could throw in some more explicit vertex mirroring and probably up the framerate. Then maybe use coherence stuff to produce a filled display, so you're mostly just extending or shrinking already filled areas of the screen frame-to-frame rather than having to carry the costs of a full redraw. Which I think you said was what Chrome was up to?
If you wanted filled graphics then I guess you'd be looking at fixed height walls or arbitrary angle. So it wouldn't be exactly like Wolfenstein - you'd lose texturing but gain flexibility in shape. I think that's best attempted as a fork of the code though, so if I attempt it at all then it'll be after everything else is neatly tied up. I continue to dither over whether to switch to Jam from Pyz80. On Thu, Jul 10, 2008 at 7:36 PM, Thomas Harte <[EMAIL PROTECTED]> wrote: > I'm still chipping away at optimisations, little by little. I've been > distracted by my PC remake of the Freescape engine*, but haven't stopped > working on the Sam stuff. The code is now roughly 28% faster than the > version that I submitted for Sam Revival, and I'm not done yet. > > Filled polygons shouldn't be an insurmountable problem. In fact, they should > be noticeably faster than the version from before I switched to vector > outlines. The main problem is that not using the stack pointer for polygon > filling will obviously slow that down by a huge amount, but continuing to > use the end of frame interrupt for triple buffering and timing would lead to > the occasional stray four pixels of random colour. In fact, it'd be very > occasional because it'd only happen if the interrupt fired while the CPU was > drawing the last four pixels of a scanline. I guess the final decision on > what to do about that would depend on whether the engine was being used for > anything that was meant to be close to a realtime game. > > My suspicion is that something sufficiently sparse that didn't run > full-screen would actually be playable in real time with solid graphics. But > I've yet to try to prove it. > > Incidentally, having watched I, Of the Mask a few times, I think it has > exactly this problem — though obviously being a Spectrum game it leaves more > 16 pixels of junk on screen. I'm not completely sure though. > > In terms of the engine's functionality, I'd like to get Elite-style movement > (i.e. incremental rotations around local axes rather than Euler angles and > progressive global axes) in there before calling it 'complete'. > > For a game, I prototyped a tennis game but it didn't seem to be fun whatever > I did. So now I'm not really sure. > > * I know it's definitely not what this list is for, but Windows and OS X > betas are available from http://tinyurl.com/66wr29 > > On 10 Jul 2008, at 16:06, Colin Piggot wrote: > >> Thomas Harte wrote: >>> >>> I think I'm running out of optimisation ideas now, which is not to say >>> that there aren't any, just that I haven't had them yet and may never >>> have them. So it's time to start implementing an actual game. >> >> Anything in mind at this stage for a game, and how feesible would it be to >> impliment shading to the code as it stands? (going back to one of the >> original ideas of being like a Freescape style engine) >> >> >>> Would anyone be at all interested in my code, packaged as a public >>> domain library of functions? I'll probably eventually do that anyway, >>> but I'm curious. >> >> Yeap, certainly. I had a few ideas on what could be done with the maths >> sides alone. >> >> Colin >> ===== >> Quazar : Hardware, Software, Spares and Repairs for the SAM Coupe >> 1995-2008 - Celebrating 14 Years of developing for the SAM Coupe >> Website: http://www.samcoupe.com/ >> > >
