Skip to content

Latest commit

 

History

History
54 lines (44 loc) · 3.2 KB

0080-2023-05-16.md

File metadata and controls

54 lines (44 loc) · 3.2 KB

16 May 2023

Previous journal: Next journal:
0079-2023-05-12.md 0081-2023-05-20.md

Update

  • Last few days had no updates because I've been unwell.
  • Raybox wall textures now work well in the FPGA, since I registered the outputs. It was pretty unstable otherwise!
  • I've been thinking a lot about sprites in Raybox. Will probably be very hard (or impossible?) to do well due ot memory constraints.
  • I've started working on getting 1 sprite to work, though.

Raybox

Thoughts

  • Palettes are a good way to keep memory sizes low.
    • RGB222 looks OK but is a bit flat. RGB333 means 9 bits per colour, but I think most walls (and sprites?) would look fine with a 4bpp, i.e. a palette of 16x9-bit colours.
  • Try implementing a generic column renderer module, with transparency param, and optionally make responsible for working out scaling?
  • Wall textures have a weird wobble while walking to/from facing walls, possibly due to approximated reciprocal. We could try to fix this (maybe reduce precision of the texture scaler or lock it to wall height??) or we could try implementing subtle "bobbing" (like Doom does) and it will make it less noticeable.

Sprites

  • Sprites are hard!
  • Bottleneck is memory reads, esp. when we have stacked sprites.
    • Hardware sprites usually have separate memory banks for each sprite, so they can all be read simultaneously.
    • In our case, the sprites in hardware would be too large... probably need at least 64x64x4bit each (2KiB), so even just 4 of them would be 8KiB.
  • Could we use HBLANK to work out which sprite pixels go where on the next line?
    • Maybe something like how old Atari stuff used to do it, i.e. after each line has rendered (or while it is doing so) have a buffer that allows us to specify the placement of new sprites, but just 1 line at a time.
    • That way we only need to buffer up to 64 pixels per sprite (though we also need to store scaling, but perhaps that can be managed with a fixed-point incrementer).
    • Note that with a full screen width of 640w, our HBLANK time is 160 clocks, so if we had to load up sprite lines that were 64px wide each, we'd only have time to read 2.5 sprites from RAM. However:
      • Many sprites only use about half their available width; are partial sprite widths possible?
      • If we go with 512w, we get 288 clocks.
      • 4 RAM banks means we could increase sprite loads by 4x?
      • Combine all that, and we could have up to 36 sprites per line, but would need at least 18 sprite "registers" which is already a huge amount of RAM.
      • We could go for lower sprite resolution, meaning we effectively get 960 (800+160) clocks, which is enough for 15 sprites as-is. Given low resolution of sprites, this is probably fine. We could even cheat and use temporally-alternating lines for really distant sprites.

Next steps

  • Experiment with RGB222, 333, and 444 -- make a simple tool to visualise and see how good/bad they look, esp. at magnifications.
  • For fun, try a rotation dial (quadrature) for rotations on FPGA.