I’m an occasional contributor to the MegaZeux source code, and I frequently compete in the bi-annual Day of Zeux competions. Accordingly, I’m always interested in new ways to push MegaZeux forward and help people create games easier, which brings me to Kev Vance‘s MegaZeux debugger. It’s ten years old and based on the ancient 2.51 codebase, which means that the released code is not much good (2.7 was a near complete rewrite, if I recall correctly), but it’s got me thinking about how a debugger could integrate into the modern incarnation of mzx. So much so that I’ve got a prototype in the works (and a corresponding bzr repository), and some thoughts to put down on paper.
I forsee a debugger in MegaZeux as being useful in the following ways:
- Tracing code execution in a single robot
- Placing breakpoints in robotic code
- Verifying expected values at different points in the program
The third is already possible with the F11 window that was added recently, which displays all known counters for easy perusal. Combined with instruction stepping, a debugger will hopefully remove the need for debug variable output lines in order to determine when a counter’s value changes.
The vision of the robotic debugger I have is a shortened robotic editor that takes up half the screen. This displays the watched robot’s program with the current line highlighted. F9 will single step forwards in the current robot, F10 continues the normal execution until/unless a breakpoint is reached (in any robot). Pressing CTR+F6 will bring up the debugger interface, and a window to select the robot to watch, at which point all execution will cease until the user presses either F9 or F10.
That’s the gist of it right now. I currently have the shortened editor displaying the watched robot code, but only the global robot can be watched right now, and the code display doesn’t actually show which line is about to be executed. If you bring up the debugger, all robot execution stops, and pressing F9 will trigger one line of code to be executed in the global robot, and F10 will make everything resume as normal.
Now, a brain dump of problems that I need to consider, in no particular order:
- Remove the ability for the player to move when single stepping?
- In fact, currently the rest of the board is updated as usual while the debugger is active, so bullets will continue to move normally even when the user is single stepping a robot, so something has to change there.
I’m positive there are going to be more concerns I’ll have to deal with, but I’m pleased with the progress I’ve made so far. Next step: make the debugger show the actual line being executed. Then it might start being useful!