Renderer: BW mode

[Helco]

Actually, why not a black/white mode, as suggested to us it might look good (enough) to just draw the contours of the wall, planning notes to that should go here:

• Textures or no textures?
  • Maybe textures on Diorite but not on Aplite
• Contours to sector changes?
  • Maybe we can check on texture change (ID & significant matrix change)?
• Various memory optimizations propably needed to fit in 24KB (sized integers wherever possible)
• Additional performance analysis needed
• on-the-fly dithering may be helpful
• We should split up the renderer implementation in
  • Transformations (transform, clip and project)
  • Render with 6Bit color
  • Render with 1Bit black/white

[Helco]

WIP notes:

initialize the renderer with capability vector:

• framebuffer width/height/pixel format
• span texture mapping (walls)
• slab texture mapping (floors/ceilings)
• mipmaps (and up to what level of mipmap)
• contours (optimized vertical line and bresenham)
• predither pixel format.

Pixel format

We should consider the following pixel formats:

• 1 Bit grayscale (native aplite/diorite framebuffer)
• 2 Bit grayscale (for dithering)
• 4 Bit grayscale (^)
• 2 Bit color (native basalt/chalk(/emery) framebuffer) For simplicity we should not allow texture pixel formats other than the pixel format of native/predither framebuffer.

Dithering

Out of this comparison Atkinson Dithering should be most suitable, because of reduced speckling and the inherent support for fixed max/min values (contouring). In any case an on-the-fly error diffuse dithering is not possible with out renderer (semi-random draw order), which means there needs to be a pre-dithering framebuffer. Atkinson dithering uses the divisor 1/7 which means we need 2 bits more per pixel`, this would mean:

Pixel Format	Bits per Predither pixel	Predither buffer size (144x168)	Comment
1Bit grayscale	3~=4	12096B = 11,8KiB	Useless
2Bit grayscale	4	12096B = 11,8KiB	Light dithering
4Bit grayscale	6~=8	24192B =23,6KiB	Better dithering

Dithering on basalt/chalk/emery is useless because of its native color and aplite might not be able to do any kind of dithering. Thus diorite is (for the moment) the only platform which might profit from dithering. Which level of dithering can be used will be shown by the RAM usage of the textures.

Dithering on aplite

A possible way to optimize ram usage with dithering might be to exploit the framebuffer as temporary dithering buffer, this way ram usage for 2Bit dithering would be halved (to 6048B = 5,9KiB). Assuming a max code/data size of 12KiB a total of 6KiB would remain for a few (very small) textures (most suitable 24 32x32 textures). Maybe we should explore how to get more os-owned memory.

Contouring

Contouring would replace the wall filling by only rendering:

• left wall edge if wall is not clipped
  • (right wall edge will be drawn by the next wall)
  • this is a vertical line, we can optimize this into a memset call (on 1Bit framebuffer additionally up to two operations in the fom of p' = p & ((1 << remHeight+1) - 1) or p' = p & ~((1 << 8-remHeight) - 1)
• floor/ceiling/portal border
  • these will diagonal lines with x1 <= x2 -> bresenham algorithm
  • portal border lines interpolate the upper/lower portal boundaries, use them to update yTop/yBottom
• With differing write the max value (pure black/white), due to Atkinson differing these max values can not be changed -> the contouring will never be distorted