A Raycaster in Bash

I <i>love</i> this. I&#x27;ve been wondering how the picture is drawn with less than one `echo` per pixel, and it&#x27;s very clever: the game is &quot;not really&quot; 3D, so you can run raytracing just once per column, and then you only need to draw a couple of lines (for sky, grass, and the actual object) -- this is done by outputting the &quot;draw this pixel and move down by one&quot; string to the terminal as many times as necessary using string repetition.<p>I&#x27;ve been considering working on a voxel render engine (not for Bash, but for another computationally limited environment). This is a treasure, I&#x27;m certain I&#x27;ll find something useful here.

In case you wondered if there is a raycaster written in MS Batch:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;nTh0rn&#x2F;batch-raycaster">https:&#x2F;&#x2F;github.com&#x2F;nTh0rn&#x2F;batch-raycaster</a>

It&#x27;s unfortunate that stty requires forking. Maybe the next project will be to use bash and rowhammer to call the necessary ioctls to do it without forking.

I had no idea this was possible with Bash. I’ve considered myself proficient with Bash at a pretty advanced level at times and this just blows me away. I don’t have the math chops to understand how it’s implemented, but it’s a pleasure to see.

And to think, that my own bash scripts spend 300 lines just parsing various command-line options, while instead I could be showing this game... :-P

I never ceases to baffle me how we&#x27;re still stuck with these mind bogglingly slow shells. Pure madness. I can maybe understand that some apps require all the vt100 weirdness or whatever, but probably 90% of apps just write to stdout and err. Surely we can blit some text to the screen a bit quicker and put the other 10% into some compat mode.

Only 300 lines of code, impressive! I love this.

&quot;bash is slow.&quot;<p>That&#x27;s in part why I do not use it for scripting. I do not use it for interactive use either.<p>Some popular Linux distributions also avoid bash as a scripting shell.

I&#x27;d love to see this combined with the author&#x27;s fork()-less implementation of ps to make a (almost) fork()-free implementation of psDoom.<p>Seriously though, this is really cool

Of course, we need to give an honorable mention to the `awk` raycaster from 9 years ago.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;TheMozg&#x2F;awk-raycaster&#x2F;tree&#x2F;master">https:&#x2F;&#x2F;github.com&#x2F;TheMozg&#x2F;awk-raycaster&#x2F;tree&#x2F;master</a>

Beautiful. Correct me if I&#x27;m wrong, but this looks like a bash version of <a href="https:&#x2F;&#x2F;lodev.org&#x2F;cgtutor&#x2F;raycasting.html" rel="nofollow">https:&#x2F;&#x2F;lodev.org&#x2F;cgtutor&#x2F;raycasting.html</a><p>Edit: ah, just noticed this is in the readme :(

Very cool! I&#x27;m curious when it says &quot;did you know that accessing a random element in an array takes linear time&quot;, why that&#x27;s the case, with bash?

Sadly I can&#x27;t get this working. It just throws up the view into a file called buffered for whatever reason and exits immediately :(

Wow, that’s an insane challenge. I can’t believe that’s even possible.

I wonder if texture mapping this would look good.

Imagine a TUI where you need to navigate a literal maze of options

&lt;3