CMPLXM20.BAS - GW-BASIC, multi-path perfect maze generator, 160x200
0This was my crown jewel at the time. I took the algorithm explained by C. Regena in COMPUTE's First Book of TI GAMES, and converted it into a multi-path solution. This wasn't just to look cool on the screen, although it did with the multiple snakes simultaneously carving out the maze, without any issue. It was mainly to solve a problem with the algorithm, in that a single path, as long as it can find a way forward, will continue forward. This creates these long spaghetti strands of mazes that are trivially solved. I think it looks cool, since the paths are complex in their winding, but it is not complex to solve.
This is running under 160x200 16-color mode, which is accessible from CGA as well as Tandy graphics.
Since this is running under PC-BASIC emulation, which runs 3 to 4x the speed I had on my Tandy 1000 SX, it generated rather quickly -- though I bet it appears slow to you. I used to sit and watch this... every pixel... from start to end over a period of 15 to 30 minutes. I was absolutely enthralled by this. Randomness, dynamic, even evolution to some sense, all to generate a perfect maze where any 2 points only has 1 solution between them, and all points are reachable, without any loops. I thought it was amazing.
Looking at the code now, I am surprised to see two things:
One is the generation of a new path just does a FOR LOOP, and just quits it once it finds an opening in the array of current path tracers (which is fine), but never closes the loop! Apparently GW-BASIC is fine with this. I can only assume I was aware this was ok, since I believe many of my programs would do things like modify loop counters in mid-loop, and I trusted the interpreter to do the Right Thing.
Second is, and perhaps only because PC-BASIC is so fast, that I noticed the program does not get very much faster when few path tracers remain. I can smell that root cause from a mile away -- because it's doing extra unneeded work. The total indexes it loops over never decrements, so while it avoids processing path tracers that died, they were never deallocated. Now, you cannot just compare the end speed with the speed at the beginning; since the back-tracing is actually slower as it looks for paths untouched.
Of note, I actually learned that lesson during the making of Duality ZF (the Duality engine was released under the Score Rush series of bullet hell shmups), where I just assumed the CPU can handle iterating over 1,000s of elements unused, and it turns out it cannot without slowdown!
My playlists:
--------------------
- Voxel: https://youtu.be/watch?v=XCVWEuhCCDM&list=PLjnbT4UISq0bQF1g85tE9jTrKfEtdRYlY
- Road: https://youtu.be/watch?v=ck5ALX11YU4&list=PLjnbT4UISq0bnfd1RC3M4PgTgkmhlkikV
- Ray Casting 3D: https://youtu.be/watch?v=zjswXUTMP2o&list=PLjnbT4UISq0YcFtRFjFQqK0g6ONNCtrvY
- Side-Scroll Shmup: https://youtu.be/watch?v=fF4X8zN-Raw&list=PLjnbT4UISq0Y_7IAN_zUzxgZnfhXxo_0Q
- MonoGame Tutorial: https://youtube.com/watch?v=WW1dJnfXWb0&list=PLjnbT4UISq0adw__Y9B2eXA0LL35TyORU
My websites:
---------------------
- my GitHub: https://github.com/JDoucette
- my company: http://xona.com
- my Blog: http://thefirstpixel.com