There is an often-misapplied quote from Donald Knuth about premature optimization being the root of all evil. The quote originally meant that developers were often looking at optimization in the wrong places in their code at the wrong point in the development process.
I really thought that my ray-segment code was clunky and needed to be cleaned up and sped up, as I copied a bunch of stuff from Wikipedia after other copy-paste techniques failed. It’s clunky and inelegant but it works. I tried to improve on it after going through a few more web sites but never actually finished the optimization.
The rest of the code was horribly structured. The wxPython Frame’s OnPaint event handler was doing all the calculations for the distance from the runner to the walls, determining which walls were closest in each of five directions, and then drawing the lines.
In response I probably over structured the file. To escape the problem of doing the wrong thing in the wrong part of the code. So now I have separated the Runner (which is for the physical thing in space, not the neural net I hope to program), the Maze, the Trial, and the Frame into separate components. The Trial links to the Maze and to the Runner (and eventually the neural net), and the Frame links to the Trial.
I also implemented a simple tick counter in the Trial object and used PyPubSub to spread the word when the tick counted up. It also provides the runner’s position and and the points of intersection, so the Frame can draw what it needs. I can still use the mouse scrollwheel to rotated the runner (telling the Trial to rotate the runner and process a game tick) and the left mouse button to advance the runner (again, by telling the Trial to advance the runner and process a tick).
I also added labels for the current tick and a warning if the runner had hit a wall. This illustrated a problem with the super-clever matrix transformation I applied to the DC object so my text appeared upside down. It was easier to reset the transformmatrix and place text on the screen normally. I could also use wxPython’s text fields and labels to display this information, but that seems a more complicated re-learning process. I’ll just draw what I want to know.
There is no mechanism for stopping the runner from passing through walls, as there’s no concept of “inside/out” in the maze at this point, and if the runner escapes the walls the whole thing crashes.
I never cleaned up the ray-segment code, though. It currently is using Cramer’s rule and while I could get clever and sort it out with a cross product and a dot product I could probably speed up the calculation quite a bit, but I think I’m going to let it go. It works. I feel like I have bigger fish to fry.