>Just out of curiosity, what emulator(s) do you conisder to be good for debugging?
Post got really long (sorry), so here's quick summary:
- ZSNES for step by step debugging (and whenever I can because I prefer ZSNES)
- Snes9x "logger version" - for when step by step isn't feasible
- SPX - starting to look really good
Really, it depends on what you are doing.
If you are totally clueless as to what is causing the problem... (and it does happen to all of us at one time or another) ... then it's really hard to use the conventional emulators for debugging. I've eventually found most of these errors (with my coding style) to be caused by incorrect variable/system initialization, or stupid little errors in interrupts with kind of the equivalent of "sharing violations". So now when I'm totally lost at least I know what I probably should dig through. It takes time, but everyone eventually learns where their personal "what the #$@%?" errors come from.
But in general, when I refer to "debugging" I usually mean little stuff. It's annoying to transfer every code set over to the SNES while fixing up all the quick little errors after a big code addition or change. That's when the emulation is the most useful, and pretty much any decently compatible emlulator is good for this.
Now when the problem isn't quickly obvious, I usually know what function it is... I just don't understand why. ZSNES is good for this. I just look up the routine address in the symbol output file (you need to request this when you compile with WLA DX), run zsnes in debug mode, and tell it to run until it hits that address ... then I can see on a instruction by instruction level what the registers are doing, and see where my mistakes were.
In some cases, the error occurs only during a specific input sequence or certain scenario during the game ... unfortunately zsnes won't let you do input while debugging, and even if it did, you'd have to be careful to catch the correct frame where the error occurs. For annoying "in game" stuff like this, if possible I try to keep breaking at the routine address until the "error" comes around. This is really annoying though since if you guess when the error will occur and it takes 1/2 sec of game time longer ... that's about 30 breaks. Really annoying and I usually miss it.
If I fail to find it, or the game input requirements won't allow me to get into debug mode quick enough, I usually use an emulator that can log the emulation step by step to a file. Then search the file for my routine's address. These are definitely a nuisance.
(Sometimes the input is simple ... like pressing A "jump" causes a jitter then a crash. In this case, I go into debug mode, "fake" the input by changing a variable in memory ... then break on the routine where I suspect the problem.)
If I don't know where the error is at all, I usally add something to the program that will display some info on the screen or something (a quick nice way to narrow down where errors occur).
In reality, my answers above were of little help to you. Each person has different coding styles as well as errors they run into ... as well as how they prefer to seek them out.
Anyway, to better answer your question, I usually prefer zsnes because I liked their step by step debugger. Even though old habits die hard, I've been really looking at this new emulator (I'm not sure if I'm supposed to be releasing this info, as I kind of got a prerelease) http://users.tpg.com.au/trauma/spx/
It has fairly nice step by step debugging (I like zsnes's better still at the moment). It has logging to file support which is okay (I always had problems with some of the Snes9x's logger support, but Snes9x's is better if you can get it to work correctly). But what makes it really nice is that you can view almost anything about the SNES's internals. Once he adds the breakpoint and watchpoint features ... Woohoo! It will be really nice to work with.
I know he has newer versions than what is on the website, but we'll have to wait and see. He's still actively involved in SNES projects, so I doubt he set it down... so he may have a lot more done than I know about.