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