Skip to content

Latest commit

 

History

History
58 lines (45 loc) · 3.11 KB

0144-2023-09-06.md

File metadata and controls

58 lines (45 loc) · 3.11 KB
Raw

6 Sep 2023

Previous journal: Next journal:
0143-2023-09-05.md 0145-2023-09-08.md

raybox-zero

Quick update only:

  • Started working on textured walls.
  • Added version tags to tt04-raybox-zero and raybox-zero
  • Flip texu based on upper or lower side.

NOTE:

  • If it helps, tex_acc_init can actually start NEGATIVE at the start of the line and count up to 0

Next steps

  • Add in other test010 results (if not otherwise done in 0143?)
  • Move texv_acc logic into row_render?
  • Change MAP_HEIGHT_BITS to MAP_HBITS, etc.

Optimisation

  • partialX and partialY are not really needed and instead could be a shared module that loads mul_in_b as a register when needed...?
  • Get rid of rcp_sel and mux on state instead.
  • texv_acc and texa probably don't need to be full F precision.
  • Consider wall_tracer.playerX, etc... should we reduce the size of these ports, do the same with pov, and try explicit bit padding to match the shmul?

Other features

  • Texture scrolling (simple texu/v offsets)
  • Texture scaling (addend before multipliers)
  • Auto darken textures on shadow side: &0b10_10_10 >> 1 ? Or subtractor with clamp/sat? Even a luminosity LUT?
  • Wall height variation renders fine with repreating textures if we use texels (texu) as our height parameter. HOWEVER, we should be able to render taller walls in the distance but this doesn't work for height variations done using texu (because trace has already stopped). It COULD be made to work if we did an extra trace to find tall vs. short walls, because 1 tall will block anything behind it.

Home stretch -- Last day

  • Write IO list.
  • Fallbacks for map, textures, etc to bitwise versions, using an input flag or initiall state.
  • SPI registers to enable additional functionality if under host control.
  • Map:
    • 16x16 (256-bit) internal RAM set by host?
    • 64x64 bitwise ROM?
    • 1-bit walls, or 2?
    • Simple pattern using case expression or other bit patterns?
    • SPI ROM access? A 16x16 map might work, more might not. Got to consider FSM setup/hold time, SPI access time, SPI overhead, writing the address, reading data, and doing this up to 16*sqrt(2) times. Requesting 1 random bit (1 step) would take ~20 states, so 22 steps would take 440 states.
  • Textures:
    • 64x64 bitwise ROM using texu/v. Can work for different shades/tints too.
    • SPI-load from external memory: Load texu line into internal registers: 64x6=384 bits. We only have 160 clocks, maybe only 70 if we account for SPI cycles/timing. If we use QSPI, that could be 280.
    • SPI-load progressively probably won't work because timing can be too tight when scaling is on the small side, and impossible if pixels need to be skipped.
    • 32x32 textures or even 64x32 if necessary?
    • If necessary, buy more line time by defining HALF_SIZE as 240, meaning we can get 320 clocks in HBLANK instead.
  • Blanking signal (hi-Z control) to allow safe host control over external memories.
  • Interrupts or other signals of internal state.
  • Sprites:
  • Overlays?