Errr, ah, well, this is probably completely daft , but I write it anyway - after all - this COULD be one of those things so obvious, only the idiot spots it. (Had I been clever enough, I would have tried the thing out myself.) ?B> It's on the by now utterly boring chunky-to-planar-conversion issue: -How about a SHires HAM8 (or HAM6) screen. -Let's think about it - okay, so all of a sudden there's four times as much data to convert and DMA will strike it's chest and take over the chipram buses (You are using 4x bandwidth anyway aren't you) BUT : ~~~~~ 1.If we fill the two control bitplanes with values, which for the first three pixels change the colour components, one by one, and then leave the fourth one unchanged, we only have six (..four in HAM6) bitplanes to convert. We fill the colour registers with a 64 (..or 16) value grayscale. YES THERE WILL BE A SERIOUS AMOUNT OF COLOUR FRINGING - BUT that could actually be somewhat advantageous - I imagine the picture as becoming softly blurred like, hiding sharp pixel edges. 2.There's now only two (lowres) pixels/byte to map into the bitplane and if we use two pixels per, err, pixel (VERY low resolution, like colour gfx on the C=64) there's only one - HEY PRESTO - all of a sudden there's no need for a dummy (chunky) image in ram - we might as well output to the bitplanes while calculating. 3.False 18bit (..or 12 [..nag, nag, nag..]) colourdepth ought to look a good bit nicer than 8bit colourmapped. 4.I SUPPOSE a smart layout of the bits in the chunky data could simplify the conversion. (We need a longword per pixel obviously. [unless we store the graphics truly serially.] Hence we've got six bits,which are extraneous.) 5.Unlike a copperscreen, this use a standard screenmode, a specialized animation format anyone? Another small reflection of my messy mind's. -Hello, any texturemappers out there? -How's for this fake antialiasing method???? 1.Drag the texture out to twice it's size (waste memory), never mind to fill in the blanks between the lines. 2.NOW fill the blanks, with halfway values (ie. if the original texture has a $0e0e0e pixel next to a $000000 one, the one in between would be 070707 [WOW, 'tis advanced stuff...err, not]) This will of course lead to textures, that take up four times as much memory while loaded and they have to be "expanded" before use, BUT (again) it could give us something remniscant to real antialiasing, without using any more CPU power while calculating the screen, couldn't it?? ...and to all not-quite-yet-texturemappers; remember, that all texturemapping is about, is the rescaling and drawing of straight lines. -Especially when it comes to DOOM-style stuff, where there's no pitch, nor roll. In those cases, you only have one-dimensional walls and two-dimensional floors/celings to care about. In short; apart from the always necessary (..although some people, seems to have skipped that part - Yuech, What's that perspective?!!?) Vector maths, you should be fine with addition (well...and division...and some LSRs) Oh...one more thing btw; why is it, that in every DOOM-clone you're 3" tall, just wondering...... If you want to flame me ( in a dignified way though, please =|:D ) you could always try my email address. o o__/ \__o in a slightly sincere manner... / / \ \ \ \,,,/ / jonny.johansson@mailbox.swipnet.se \/ \/ { . . } < U > ||| \ - / /. .\ ----oOOo-------oOOo--oOOo----U----oOOo---