Dysfunctional Programming » megazeux

Megazeux debugger on github

Josh Matthews — Tue, 02 Mar 2010 10:14:45 +0000

The official Megazeux repository recently moved to github, allowing me the opportunity to create my own fork and move my debugger work into a more public sphere. Accordingly, you can now visit my repo for all the most recent robotic debugging developments.

Cross-compiling with MinGW on Fedora

Josh Matthews — Tue, 02 Feb 2010 13:22:29 +0000

My goodness, I’m impressed. Having released the first iteration of my robotic debugger, I was informed that the fork()/exec() combo isn’t portable to Windows. Nobody volunteered any patches immediately, so I decided to read up on cross-compiling since I really dislike having to reboot into my other partition. Turns out that the entire MinGW stack has been packaged up for Fedora, meaning that all I had to do in the end was:
# yum install mingw32-gcc mingw32-gcc-c++ mingw32-libpng mingw32-SDL $ mingw32-make -j2

It wasn’t quite that easy – since Megazeux uses a non-standard configure script, I had to correct a few faulty assumptions. I never figured out the correct way to use

/usr/i686-pc-mingw32/sys-root/mingw/bin/sdl-config

instead of the default one, so that got hardcoded somewhere. Also, Megazeux relies on libogg and libvorbis, which haven’t been pushed to the fedora repository yet (packaging limbo ahoy!), but I was able to grab some rpms that the mingw32 packager helpfully left lying around. All in all, a very successful and satisfying experience.

Break me off a piece of that Megazeux debugger

Josh Matthews — Fri, 29 Jan 2010 22:45:31 +0000

Breaking news: breakpoints now exist in the debugger. There’s no indication that they exist until execution reaches them unless you look in the console window , but they’re there! Next up: differentiating between active line, current line, and line + breakpoint in the robot editor syntax highlighting. Apart from that, the debugger is now fairly functional – stepping, continuing, and breaking, and most importantly quitting are all zipping along as happy as can be.

Megazeux Debugging: Redux

Josh Matthews — Thu, 14 Jan 2010 10:14:03 +0000

It’s been about a year and a half since I last touched on the idea of a Megazeux debugger, and that is far too long! I’ve recently begun an internship with Mozilla working on the Electrolysis project, which is a continuation of the work I’ve been doing in a volunteer capacity for the past few months. This has inspired me to restart my Megazeux debugger project, with the key difference that the debugger is run in a separate process. I’ve spent a few days hacking this into a working state, and users of my debugger (namely me) are now able to choose a robot to watch inside of Megazeux, and a completely new application window appears displaying the robot editor and the watched object’s code. With this architecture, the parent process (mzx) simply informs the child (mzxdbg) which line is currently being executed, and the user can happily scroll around inside the robot and do things like place break points. Theoretical break points at this point, but they’re coming. Just you wait.

MegaZeux Debugging: part 3

Josh Matthews — Wed, 30 Jul 2008 20:48:52 +0000

After some more fiddling, basic robot watching is pretty rock solid. I fixed some memory leaks and crashes, and I’ve moved on to breakpoints. And herein lies the conumdrum, as I’m trying to figure out the use cases here and how everything should work together. As it stands, breakpoints are not very useful, because you can only place them when debugging, and then the only option is to place a breakpoint at the currently executing line. The robot editor that shows up when debugging currently has no mechanism for scrolling around the robot’s code, so you’re limited to the view of about 10 lines of code that surround the current line. For breakpoints to be useful to a developer, I feel like either you should be able to place them either in editing mode (when you’re actually modifying the robot), which will lead to all kinds of terrible headaches trying to keep that information in sync with the robot’s contents, or else the debugging interface needs to have more interactivity. I’m leaning towards the latter option, but still open for discussion.

The other major consideration right now is what kind of lifetime breakpoints should have. Should they persist between debugging/testing sessions? Across boards? What should happen to the interface when the player switches boards and the debugged robot no longer exists? These are questions for which I don’t have good answers at the moment.

MegaZeux Debugging: part 2

Josh Matthews — Tue, 29 Jul 2008 03:08:11 +0000

What with midterms and end of term, it’s been several weeks since I last touched my robotic debugger, but that changed tonight. There’s now a usable bleeding-edge debugger for your perusal in the bzr repository. You have your choice of robots to watch on activation (ctr+f6 in testing mode), f8 will bring up the watch dialog, f9 will step a single instruction (which updates in the editor accordingly, so you can follow the action), and f10 will continue normal execution with the debugger still activated, so pressing f9 will start stepping once more. Of course I’ve somehow induced megazeux to start segfaulting on exit, so there are obviously some problems that need fixing, but everything starts somewhere!

MegaZeux Debugging

Josh Matthews — Mon, 07 Jul 2008 23:12:55 +0000

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!