As Snes9x gets its key settings from a config file, but that file is rather bewilderingly explained, I set about seeing what it took to make Snes9x act a bit more ZSnes-like. Like most other programs you can also give it command-line options when you start it, and can use multiple options at once (some combinations make no sense or are unnecessary). Some handy examples I found:
snes9x -sc makes it double-sized, so it actually fits the damn window rather than being just a tiny little picture in the middle of a great-big window.
snes9x -y makes it fill the window and use the scanlines type display like ZSnes tends to do by default. Some of us prefer that look :)
ZSnes buttons:
| SNES | keyboard |
| A | x |
| B | z |
| X | s |
| Y | a |
| LEFT shoulder | d |
| RIGHT shoulder | c |
| START | RETURN |
| SELECT | Right-Shift |
DEFAULT Snes9x buttons... according the readme file:
| SNES | keyboard |
| A | v |
| B | c |
| X | d |
| Y | x |
| LEFT shoulder | a |
| RIGHT shoulder | s |
| START | SPACEBAR |
| SELECT | RETURN |
| SNES | Keyboard |
| A | d |
| B | c |
| X | s |
| Y | x |
| LEFT shoulder | a/v |
| RIGHT shoulder | z |
| START | RETURN |
| SELECT | SPACEBAR |
Another funny thing the Unix port of Snes9x apparently also supports bastardised versions of the vi/Roguelike direction keys (also used in less and numerous other Unix progs), but instead of using the standard h/j/k/l arrangement they put it into another horrible arrow-key arrangement, h/j/u/k so you have to contort your fingers up again, all in the name of obviousness. The rather more obvious problem with this is that anybody used to using those keys for directional control will not be used to that arrangement, it will just confuse us. Anybody else is not going to use them at all. Why do it?! Other than that, it also supports other predefined keys for the buttons too. And conspicuously, it uses Escape to quit the emulator, no questions asked, whereas ZSnes uses Escape to bring up a pretty useful in-game menu.
But I digress, yeah. It'd be preferable (for ZSnes users like me), to have the keys we're familiar with, so a config file would be nice! Well here you go. This is for the Linux/X version- if you want different keys still, the key names can be found from the X11 header file /usr/include/X11/keysymdef.h if you have it, but you have to remove the KB_ prefix from the names in there. OR you could probably use that GTK wrapper/launcher for it, but I didn't fancy that myself. Or if you use Snes9x on Windows you presumably don't need to bother with all this anyway, as it apparently lets you set the controls from the GUI instead.
[Unix/X11 Controls]
K00:Right = Joypad1 Right
K00:Left = Joypad1 Left
K00:Down = Joypad1 Down
K00:Up = Joypad1 Up
K00:Return = Joypad1 Start
K00:Shift_R = Joypad1 Select
K00:x = Joypad1 A
K00:z = Joypad1 B
K00:s = Joypad1 X
K00:a = Joypad1 Y
K00:d = Joypad1 L
K00:c = Joypad1 R
Copy and paste that into the relevant part of your config file, or else make a file just containing that and save it as snes9x.conf in the appropriate directory (should be ~/.snes96_snapshots ), and it will use it on startup. If you just want to test it out without changing defaults, put it in a different file, and pass the name of that config file, eg:
snes9x -conf testconfigfile.cfg romfiletoload.smc
Then you can install it properly afterwards if you like it. Alternatively of course you could again use that GTK wrapper for snes9x, but you might not like the idea *shrug*. The config-file approach has its advantages once it's done.
| CTRL-F1: Save SPC data | CTRL-PtrScrn: Take screenshot | Scroll-Lock/ Pause: Pause emulator |
| Shift-F1: Save snapshot #1 | ... | Shift-F9: Save snapshot #9 |
| F1: Load snapshot #1 | ... | F9: Load snapshot #9 |
Important bit to remember is that Shift is to save, and Unshifted is to load, and CTRL is to do quirky things.
However, the docs also refer to other keys for "load and save game's position", with no explanation how these differ from the snapshot controls above. Also there's the claim at one point that F10 is a 10th save position but this appears to be only for loading an """oops""" file, which I've seen but there's no explanation WTF this is. Shift+F10 doesn't save to that file, so don't try to use it unless you know what it's for. Some of the CTRL based keys can use ALT instead, but this seems maybe inconsistent between versions.
(Addendum: I wound up looking it up at last, apparently "oops" files are generated automatically in certain circumstances, which is sorta what I'd noticed, purely as a bit of a safety measure in case you lose your *other* save files due to some cock-up. I'm still not clear *what* causes them to be produced. For instance yesterday my UPS packed up and powered-off my machine, leaving me with my game of Shin Megami Tensei unsaved since my squad passed through a terminal room several days before. I hadn't worried about taking any snapshots. Was there an .oops file? Yes, from the previous game session, 3 years ago!! Obviously I wouldn't expect it to magically produce one right when the power went off, but it hadn't made one during that whole session. So yeah, it's hardly infallible. Again, don't try relying on these things and don't try loading them if you don't want to lose your game position, duh. They're just a little safety-net)
The pause button is very very handy- some games have a pause, and some games are essentially turn-based, but that's no help for the others, and in any case, in-game pause controls do not stop the emulator using your computer's CPU cycles, so the system load remains very high. The Snes9x pause however, drops CPU usage to within a gnat's whisker of nothing, so you can use your computer normally for a bit without closing the game entirely. ZSnes OTOH keeps chewing loads of CPU even whilst the menu's there (I dunno if it has some other pause I've not seen though).
(oh wait, it's not "new" at all, it started in 2000 or something, it was just new to me because it's not such a popular one, and is still in somewhat alpha-status)
When run without a ROM image, it'll give you a neat little menu system, sorta like ZSnes does. Also like ZSnes, this menu mode continues to suck up tons of CPU for no obvious reason. Unlike ZSnes, your mouse cursor isn't visible (well ok mine wasn't) when you try to use the menus, so you have to use cursor keys to navigate it. It had a very nice controller-setup interface, for you to define keys with, possibly similar to what the Windows version of Snes9x does. There's a few options you can tweak from here too. If you run SNeSe with a ROM image, you can get the menu by pressing Esc, again like ZSnes, and you can leave the menu by pressing Esc a further time. IIRC?
Emulation is eh, well it was a bit slow for me. Not unusably slow, but sluggish. Sound was different yet again to other emulators and things, though I didn't test it a whole lot. It seemed slightly as though the channels were out of sync, but I think this may've been just the way it sounded due to the different reproduction to what I'm used to. It seemed not to actually drop out much, like actual buffer underruns or anything, but some of the channels seemed to come out a bit jittery or warbly??? This could be different filtering or something. I've heard similar playback from some other emulator, but I think it was ZSnes post-upgrade (my system was upgraded, not ZSnes, and ZSnes wound up with choppy sound thereafter)- in which case that'd imply it's just not going fast enough.
I tried toning down the quality a bit to reduce the processing requirements, but it still sounded off. Also the sound was noticably laggy, like maybe 300mS or thereabouts, I couldn't say. Possibly the sound buffer size is determined by the Allegro library or perhaps that was the smallest buffer they could use without underruns.
I also noticed that when I quit, the settings file it made (sneese.cfg) seemed to be left in the source directory, rather than my home directory or the working directory. This would be a bit undesirable as I built it in a temporary directory... It could've been basing the location on something else, but I've not looked into that further.
So anyway. It's plausible newer versions are better in some of these respects, and it's pretty reasonable to suppose that it's less sluggish on faster computers! And I don't think I noticed any other problems.
Other nice point: Whilst they don't strip the SneSe executable when it's built, and it comes out at about 4.5MB for me, I found that if I stripped it myself (run "strip sneese" at the command line, if you don't know), the executable came out at just 790K!! That's much better than ZSnes or Snes9x in that regard. OTOH the Allegro library is a bit bigger than the SDL library. But if you have other Allegro games/programs, that doesn't matter. Anyway, worth noting for a few of us.
(Oh hmm, it's "SNEeSe", not "SNeSe", on looking again. That randomly-mixed-case crap always makes my eyes water anyway, don't blame me. Meanwhile it seems according to the SNEeSe homepage that it hasn't been updated since 2006, what I had is still the latest version)
See also: SPC music, Shin Megami Tensei If..., and playing import games (doesn't currently cover SNES, but may well do some time)