Now, this aforementioned game should have a couple color changes when its done, but I haven't decided on the color combinations yet. I was getting pretty sick of trying colors blindly. I thought somebody had made a utility that showed all of the available colors, but I couldn't find it so I coded my own: http://roody.gerynarsabode.org/notdead/colorthing.hex
While putting it together, for some reason, I was using HugoFix's "$ot" command to look at the object tree. All of the blank (no-named) objects due to my sample game's many windows bothered me, so I updated DoHugoFix's (and its companion routine, DrawBranch's) code so that the following usually-blank items now have a description:
- Object 1 is now listed as the display object, which it should always be in a standard library-using game.
- I gave the window_class object in "window.h" the type "window_class" so it can be checked for. Window objects get some special window-printing code.
- All other unnamed objects are assumed to be replaced objects and are listed as such.
So yeah, admittedly, that's not the most important roodylib addition I've ever written, but I like it enough.
Other than that, I noticed that Hugor is not handling the MATCH_FOREGROUND constant correctly, so the input color is coming out wrong on some games. I e-mailed Nikos about it, although maybe I've said something about it before as the e-mail gave me a little bit of deja vu (the only implication here is that I'm so disorganized).
Oh, well, progress is progress!