Skip to content

Latest commit

 

History

History
100 lines (82 loc) · 5.05 KB

0076-2023-05-07.md

File metadata and controls

100 lines (82 loc) · 5.05 KB
Raw

7 May 2023

Previous journal: Next journal:
0075-2023-05-06.md 0077-2023-05-09.md

Raybox

Achievements

  • Axis glitch fixed?? I think I plausibly worked out why the axis glitch was happening, and applied a fix based on that which seems to work. See "Axis glitch fixed?" below.
  • Improved the README a fair bit. Got an OK animated GIF into it, showing an actual VGA display.
  • Added sim hotkey to dump current design vectors (I as base key, and SHIFT+I which also pauses the sim) and likewise added function keys F1..F10 to load hardcoded sets of vectors for testing.
  • Adjusted write_new_position logic a little to hopefully make it work better for actual driving via another host controller.

Axis glitch fixed?

My theory is that because the step distance ends up being big enough that when it gets added to an existing trace distance, it overflows. In other words, it doesn't have to saturate but it can still be big enough as to cause an overflow on addition, and that means it will become negative and hence of course be "less than" its counterpart, so it doesn't stop tracing when it should. Consider this from here:

if (trackXdist < trackYdist) begin
    mapX <= rxi ? mapX+1'b1 : mapX-1'b1;
    trackXdist <= trackXdist + stepXdist;
    side <= 0;
end else begin
    mapY <= ryi ? mapY+1'b1 : mapY-1'b1;
    trackYdist <= trackYdist + stepYdist;
    side <= 1;
end

Let's assume Q12.12, i.e. 11 usable integer bits, because the sign bit should always be 0. If stepXdist has been calculated to be a (not yet saturated) value of 2^11-2 (2046) and trackXdist is already up to (say) 5, then in Q12.12, we'd be adding these two binary numbers:

  0111'1111'1110.0000'0000'0000 (decimal:  2046)
+ 0000'0000'0101.0000'0000'0000 (decimal:     5)
===============================
  1000'0000'0011.0000'0000'0000 (decimal: -2045)

...i.e. it wraps around to being negative, and hence trackXdist looks like it is still less than trackYdist even when it's already overflowed.

To mitigate this, I could've come up with a series of checks inc. a sign overflow detection, but I think it turned out to be simpler to just change trackX/Ydist to unsigned which makes the comparison work as expected.

Host controller ideas for Raybox

  • For Raybox input hardware, how about a S/NES controller, knock-off, or DB9-based controller (Atari/C64 joystick or Genesis gamepad)?
  • Ooh, another interesting option is a Wii Nunchuck controller!

Other notes

  • Observation on Wolf3D motion:
    • Faster walk speed than Raybox.
    • Run speed is much higher again.
    • Run also speeds up rotation.
    • Run does not affect mouse speed.
    • Strafe speed feels faster than forward/backward motion.
    • Mouse motion is very fine-grained.
  • Fabien Sanglard's Chocolate-Wolfenstein-3D vs. wolf4sdl.
  • Precision tests (prior to axis glitch fix):
    • I noticed that Q12.9 still kinda renders OK; slightly less refined on diagonals, and a little more X/Y axis glitching, but OK generally.
    • Interestingly, Q12.8 still works, but renders as though it has dropped to a lower screen resolution: I suppose this makes sense because the vertical scaler also loses resolution.
    • Q.7 doesn't currently compile because some code assumes at least 8 fractional bits. Besides, nobody would want Q.7 unless it was necessary to optimise for a small ASIC area.
    • Q10.8 is about the minimum that "works" but it's quite rough and has some glitches.
    • My recommended minimum is Q11.9.
    • Sweet spot seems to be Q12.12. Just note that higher N seems to introduce more axis glitching...?
  • Stuff that the ASIC could allow control over that would allow for coming up with new interesting effects when controlled by other external game logic:
    • X/Y beam transform control, to do screen rotational jiggle.
    • Distorted vplane, to allow for a skewed/wobble effect (e.g. teleport fuzz).
    • Vertical screen split (i.e. "two player" L and R screen sides).
    • Altered FOV or screen height.
    • "Jogging" i.e. up-down displacement?
    • 90deg rotated view ("Descent"-style), optionally with up/down bounce.
    • Doom-style acceleration/deceleration.
    • Host could add a small number of extra vectors onto the tracer to test things like collisions and line-of-sight stuff.
  • I need to brush up more on metastability to work out whether there are special requirements to make write_new_position (and its related registers) work properly.