Yes, I am doing it recursively, but I have to make it fill the entire screen with one-pixel-wide paths.
Also, I can't figure out how to make it do the entire screen and not just one quadrant of it.

It just occurred to me that my code won't strictly work as written unless you use a stack; I recommend using Doors CS's Ans stacks and maintain six separate stacks, for X1, X2, Y1, Y2, A, and B. For one-pixel-wide paths, just replace where I wrote "multiples of 5" with "multiples of 2".

What about the fact that the game is written in Axe?

You can make a stack in Axe by using a SafeRAM area such as L1 and storing values to it.

Easy enough. Thanks for the reminder about the SafeRAM.

An excellent point. Here you'll want a single stack, then, holding 6-byte chunks as stack entries, consisting of those six values I mentioned. Just make sure you don't get more than (safeRAM size)/6 levels deep!

Alright.
Thanks for all the instructions, but I came up with a good algorithm that sort of follows the depth-first search. It makes hard but possible mazes about 80% of the time. I should have v2.0 of WM ready in the next couple days, as soon as I speed the algorithm up.

Can you present the algorithm that you're using? Is it based on any of the given algorithms? And with a DFS you definitely need some kind of stack; are you using one? Finally, what happens the remaining 20% of the time?

It is vaguely based on the DFS, but not fully, so don't be too surprised.
If the syntax is weird, that's because it's Axe.
(To all you Axe programmers: If I could make this faster, please tell me.)
For each pixel, it goes through, and, if the pixel is white and is a dead end or enclosed cell, changes one of the pixels around it to white, thus joining it to a neighboring pixel.
Note: Don't laugh at this; it is rather pathetic, but it does work about 90% of the time now.
The code:

Code:

That's an iterative algorithms, not a DFS or recursive algorithm at all. I'm glad to hear that it works though, but you need to get that remaining 10%.

I guess I'm just good at iterations.
Or bad at recursive programs.
Oh well. If I can make the speed bearable, then I can add a few changes to make the mazes solvable 99% of the time. Then I can get Window Maze done and turn my full attention to Axe Avalanche and Final Invasion.
Thanks for all the work on your part, Kerm, and I hope everyone continues to post errors, ideas and suggestions!

I have made BASIC maze algorithms of all kinds and I'd say I'm the most knowledgable on this forum about random maze generation (I even made a generator that can make mazes with walls at any angle). Shoot me a message on cemetech but preferably:

[personal info elided]

Can you explain what happens in the mazes that don't work? Does it make mazes that have no solution, or mazes that have too many solutions?

Well, because of the way I set it up, the start or finish pixels sometimes stay enclosed. But most of the time this is not true!

Be careful if you're storing large amounts of data to the safeRAM areas, though. You can easily overflow them and corrupt those parts of the OS temporarily stored in RAM. I've had some experience with that.

I'm done at last. I'm posting the file now.

I made this 300 byte program after my Physics final. I had a new idea for an algorithm. This is neither the fastest nor smallest algorithm but I think it's neat so i'll actually publish something for once (ha Kerm). I dare you guys to try to figure out how the algorithm works.
On my phone so I'll just type it:

ClrDraw
0 -> Xmin
94 -> Xmax
0 -> Ymin
62 -> Ymax
seq(A,A,2,60,2 -> L1
seq(A,A,2,92 -> L2
rand(30 -> L3
rand(46 -> L4
SortD(L3,L1
SortD(L4,L2
30 -> dim(L2
Horizontal 0
Horizontal 62
Vertical 0
Vertical 94
For(A,1,30
Vertical L2(A
Horizontal 62-L1(A
End
{0,62 -> L3
{0,94 -> L4
For(A,1,30
For(B,1,dim(L3)-1
randInt(L3(B),L3(B+1)-2
Ans+not(fPart(.5Ans
Pxl-Off(Ans,L2(A
End
augment(L4,{L2(A -> L4
SortA(L4
For(B,1,dim(L4)-1
randInt(L4(B),L4(B+1)-2
Ans+not(fPart(.5Ans
Pxl-Off(L1(A),Ans
End
augment(L3,{L1(A -> L3
SortA(L3
End


Sorry if iPhone autocorrect screwed anything up.

This could be further optimized down to about 280 bytes. I'll do it later.

Pseudoprogrammer, let me look at that again when finals are over. Thanks for finally posting something you've written, though. Here's the DFS implementation that I sketched out for you, c.sprinkle. Since you failed to implement it, I coded it up myself in BASIC using the DCSB Libs.

DCS DFS Maze Generator v1.0

Isn't that recursive division, not depth-first search?

I'm working on a DFS right now. I'll let you know when I'm done with it, and what it will look like.

Edit: First version. Probably not very optimal:

Code:

I realize that, for the number of cell visits, reaching (X-2)² within the main loop is enough to terminate the generation, but I kinda like watching it trek back to the middle each time.

Another thing: I theorize that if you write in a new variable whose purpose is to count the number of passes through the main loop, and then have that multiply by a constant before seeding rand in each pass, then you can find some interesting patterns. I'll fire this up in VTI to do some testing and take screenshots.

Edit: Voila.

Oh well, guys, you are definitely a little better at this then I am.
Thanks for doing all this. However, I am still happy I was able to make something that worked- even if it was only iterative.