Might I ask, is there any good reason why this program doesn't have anything in the way of a tile/map viewer? FCEUXD has one, Gamelad and bgb have one, Visual Boy Advance has one...granted, Boycott Advance and VBA-SDL-H don't, but I can use them in tandem with VBA's tile/map viewers. I don't have anything for SNES apart from the time-honored primitive method of using ZSNES savestates in conjunction with my debugger...

Are there any SNES emu's with this simple, useful feature?

SNEMul. But I don't think you can view it AND play the game. Also, it's for DOS and hasn't been updated since like '99.

ZSNES has debugging features [that don't require DOS now]; it doesn't include a tile viewer yet, though.

The thing that scares me is that I did a remarkable amount of work on G Gundam and Zeta Gundam with no prior experience, using nothing but logs generated by LordTech's DOS-based Snes9x Tracer and a basic grasp of ASM. Now I can't imagine doing a hack without implementing VWF and bending the whole shebang to my will. ^_^;

Patlabor is going to be an odd duck to hack if I ever try it, seeing how the font is already squashed horizontally and I still don't have enough room for all the text. Furthermore, while I know the original cast forwards and backwards, what about the original characters with unfamiliar kanji names? I'm still pretty much a n00b at reading kanji names (though GiTS: SAC has taught me to think twice about reading 一人 as ひとり, if you catch my drift XD).

Ah, QBASIC. I remember being so pissed that Microsoft had discontinued version 4 for purchase (I couldn't compile programs in the free version that came with Windows, only interpret them) that I decided "hang the rules" and just downloaded it. My first such act. In that regard, I suppose you could call them the Lewis Prothero and company to my V, 'cept I wouldn't be caught dead in a Guy Fawkes mask. XD And I won't be exacting any vendettas on them as long as their .NET Express compilers remain freeware, and they keep putting out neat stuff like Rise of Legends. ^_^

I actually hand-assembled code for an abortive attempt to hack SF5 on GBA. Got pretty far with it, too, until I broke down when I discovered there was another bug I had to squash. T_T; Now I have Goldroad, and those dark days are far behind me...now, if I could only get my fledgeling VWF to display properly in the dialog boxes. XD

GB hacking became a lot easier when I finally understood that CALL instructions pushed the address of the next instruction onto the stack. I can just glance at the stack display in bgb and tell where the last CALL came from without following a routine to the end and hoping I hit the right RET. ^_^;

Using hires to simulate 8x16 in a 16x16 font almost never looks good. It tends to come out looking like the old version of my Rudra patch. I recommend you break it.

Break it, as in, "smash the hi-res printing entirely and have it print normal-res characters instead"?

Sounds like fun. ^_^

Problem is, I'm getting nightmare visions of using SRW:OG's ugly ultra-narrow VWF to get a decent amount of text on screen...not to nitpick at the otherwise excellent work, but am I the only one who noticed that the letters "i" and "l" aren't spaced properly? Bah, narrow doesn't have to look ugly. I'm sure I can work something out.

Speaking of fonts and printing and yada yada yada, the foundations of my Bistro Recipe translation are in place. I haven't implemented the VWF yet, but I do have some hooks and modifications in place that do two very nice things:

1. You can now choose to name a created Foodon, or use its default name. Even put a proper prompt in place for it, though there's this odd bug I can't figure out where the name entry screen displays improperly for an instant. Using its default name will save a dictionary compression code to memory instead of the actual full name; this is vital to allow me to use names longer than 6 characters without completely breaking the original save system.

2. Monster names will be displayed using their exact length, regardless of where the name appears; no more ugly empty spaces. (This uses a method I will have to rewrite once VWF is in place, but the basic functionality is there. In fact, as it stands, it's somewhat redundant. XD)

One thing worth noting at this point is that save files are still compatible between both versions, although compression codes will display as gibberish in the original ROM. Once I get passwords done - and I will have them done (possibly next!) - they will, for obvious reasons, not be directly compatible between versions, but if I can, I'll rejigger the password system in such a way that passwords can be converted for use (though I'll probably have to add some means to change the monster's name mid-process; otherwise it'll display as cavespeak).