>> Downgrading for the SAM is complicated, because it has 7-bit colour. 2 >> bits for each of RGB, and the Spectrum handed down its 'half-brightness' >> bit. > >I knew there was a reason I shouldnt go down this road! >[rr][gg][bb][x] is the layout?
Actually it works as [0][R][G][B][h][r][g][b]. As you can imagine, colour alterations from RBG perspective is a nightmare! >Carrier Command - the 3d wireframe is simple. Given a fast scanline routine it could be made solid ( AKA Atari ST version ) quite simply. The Z80B seems to achieve 80% speed of the same polygon fill algorithm as the 68000. Im not pretending to have written the fastest algorithm but it gives me a good feeling that solid 3D games are possible given we restrict the number of polygons on screen - perhaps with a limited depth >z-buffer algorithm? Don't even think about Z-buffering with SAM! I think it's a complete blind alley. What I did for non-sector (ie outside) 3D, was to do the opposite, and store WRITTEN SPANS in 2D, so that you can clear the screen or redraw the background with no calculations at all. It refuses to work so far, but promises to save about 30-35% total render time! Unfortunately, this is lost with sector-portal based 3D but you know the whole screen gets overwritten, so there's no need to clear the screen at all. >Hmmm. The spectrum version of Elite was not the best by a long shot IMHO and I was a spectrum bigot before I became a general bigot. Im not convinced that Mode 4 is particularly fast. Whilst I can create a bitmap from my 3d algorithms quickly when it comes to displaying it on screen the frame rate drops dramatically compared to the same non hardware blittered Amiga version. Perhaps Im not taking advantage of some >shortcut? It isnt so noticeable on the sprite engine I have already. If I limit the projection size to 64x64 it speeds up disproportionatly to the performance figures projected by the 94x94 and 128x128 figures. If this is the case it would be easier to create a Space Hulk type game because it would run at the same speed as a 3d game in 128x128 even if we projected 4 live action views. Is this because of the way SAM >handles screen memory? I (mis)use the SP register a lot with rendering. Because there's a lot of similar information, a few Kb with PUSH HL; PUSH HL etc etc in it saves a lot of time. This may not be practical on the Spectrum 48K, so SAM enjoys a faster render time. As for the 4*little viewwindows is faster than one large one, how??! There seems to be as much time with actual rendering, and four times as much clipping and actual gameplay coding! >> >7) Finally, is there a decent GUI project for the SAM? >> >> Ages ago Steve Taylor wrote a MODE 3 one, but it never caught on cos it >> cost too much and was fiddly to convert existing software. And it's word >> processor was apparantly too slow for real typists. > >This might be the same display update limitation I am hitting? I don't think so actually. I haven't seen the code, but it didn't do anything in the background, so what you had was a dorment (bar keyscan and mouse update) OS running a word-processor. Sounds crazy to me, but I've never tried anything so big. BTW you haven't pissed me off with crazy ideas. I don't care - isn't this what the list is for? -howard The NTICS Group: providers of Database Services to learndirect and Sheffield TEC. Contract management: Sheffield Libraries, Archives & Information Service. National Training Information Central Support Unit 4 AVEC 1 Sidney Street Sheffield S1 4RG Tel: 0114 275 1046 Fax: 0114 273 0024 Email: [EMAIL PROTECTED] Web: http://www.ntics.org.uk The contents of this e-mail are confidential to the addressee named above and may be legally privileged. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Any views expressed in this message are those of the individual sender and may not necessarily reflect the views of NTICS or Sheffield City Council.
