Added a snapshot release of 1.53 (81) for testing and to resolve several issues for 1.52.

The PPA is also updated for Karmic and above (older versions are not compatible with the GtkBuilder changes). If you want to stay on the stable release, you'll need to make sure the PPA isn't in your repository list.

This 1.53 (81) test build contains important changes (S-CPU IRQ and SA-1 fixes) which may affect ALL games, so we want reports which games improve and which don't.

I was using the snes9x PPA in Ubuntu 9.10 ("Karmic"), but removed it when I upgraded to 10.04 ("Lucid") because the latest version of snes9x-gtk was in the official repositories.

With this new version released, I installed the snes9x PPA again but it had no effect because the official snes9x-gtk package has a version number ("1:1.52-1") that's higher than the PPA's version number ("1.52.81-1~maverick1"). In order to install the new version, I had to run the following commands from a terminal (copy/pastable if you run "sudo true" first to make it prompt for your password):

Note that you have to use apt-get rather than aptitude to do the installation, and afterward aptitude will keep trying to downgrade you. The official Update Manager is fine, though.

Also, if you guys implement the libsnes interface from bsnes, I've got some scripts that make regression testing really easy...

Hmm. I would have thought because 1.52.81 > 1.52 it would be fine, but I guess not. I didn't number it 1.53.x because it might come across as a stable 1.53 or greater. If there's another test revision I might do that then.

I've thought about doing this and don't think it'll be too difficult, but there's definitely a few Snes9x-isms that could cause trouble.

Weird/new things I've found (using the OpenGL and PulseAudio drivers):

"Show frame rate" now shows a thing like "60 fps" in addition to the traditional "60 / 60". What's weird is that often the two fps counts are different. Why have both, and why are they calculated differently?

The aspect-ratio controls are terribly confusing to me. There's separate "Exact pixels" and "Correct aspect" sections in the "Change size" submenu of the "View" menu, but then there's also a "maintain aspect ratio" option in Preferences that lets you pick "Exact pixels" and "Correct aspect" options. However, possibly the most annoying thing is that enabling "use overscanned height" squeezes extra rows of pixel data into the same rectangle, causing the image to have a new aspect ratio that isn't 8:7 or 4:3.

The trick is the "1:" - that's an "epoch number" in Debian versioning. No epoch number is implicitly "epoch 0", and a higher epoch number beats every other version field.

I'd suggest discussing versioning with the relevant packaging maintainers, but it seems the snes9x package is orphaned.

Checking the Debian Policy Manual, it looks like if you call your package something like "1:1.53~wip1-1" then it will be considered to be a higher version than "1:1.52", but a lower version than the final "1:1.53-1" that (presumably) Debian will eventually package.

EDIT: A Debian Maintainer friend points out that if snes9x goes from 1.5x to 1.60 then all will be fine, but if it goes from 1.5x to 1.6 (six, not sixty), there'll need to be another epoch bump.


While it's true that libsnes was designed around bsnes's implementation, it *looks* like it should be generic enough to wrap any SNES emulator... out of curiosity, what are the pain-points for snes9x?

60/60 is the old framerate display that shows how many of the SNES frames are rendered/skipped. It will never go above 50 or 60, even if you disable all synching. The new x fps part displays the real rendered frames per second.

My guess was going to be that "X/60" means "rendered X frames to an internal buffer this second" and "X fps" means "rendered X frames from the internal buffer to the screen this second".

With sufficient messing around (pausing SNES emulation by switching to another window, etc) I've managed to make either one lower than the other; presumably the effective framerate is the minimum of both numbers. Why not just change the fps counter to that minimum value, and put "make FPS counter more accurate" in the changelog? Would anyone complain if the FPS counter were calculated differently?

(that's a serious question, maybe TAS efforts depend on the current algorithm or something, I dunno)

I didn't have anything to do with it, so I'll let OV2 continue to field that one.


I was thinking about getting rid of the separate sections in the menu and having a preferred aspect option or something in preferences. The menu options would continue to just resize and the maintain box would force as usual.

As for the overscanned height, I have no idea what the "correct" behavior is regarding that. It's probably ideal just to not have the overscan area available at all. I figure it's such a niche option that people using it can figure out a proper window size or whatever. I'm not overly concerned about it.


Ok thanks, that explains it. I get the 59 > 6 part .


Nothing impossible. For instance, the save-states are hard-coded to read/write from files and in most cases use zlib, so there's not a consistent way to get a block of data. The whole input layer would need another layer of indirection around it.

The two counters display different things: the old one states "of the last 60 frames, X were rendered" and has no reference time frame. The new fps counter displays the number of emulated frames in the last second (not necessarily all displayed).

The effective framerate is usually equal to the new counter, unless frameskip is enabled.


I didn't want to remove the old counter since it's the only way to check the frameskipping in automatic mode.

It seems that every emulator GUI has its own ideas about how scaling should work. snes9x's scaling system is pretty sensible for the most part, but completely different from bsnes's scaling which is pretty sensible in a different way.

A few months ago I tried to come up with a system worked the way I felt was most sensible, and eventually I came up with this code

EDIT: What the hell, I had a whole other half a post here, where did it go.

What I wanted to say was, I understand you're not particularly interested in rewriting the snes9x scaling system, but if you wanted to give it a try, I think my algorithm is simple, easy for the user to configure, and gives results that should closely match what a real SNES connected to a TV should do.

• "hi-res" mode doesn't affect the rendered width of the SNES frame, so we can ignore it.
• "interlace" mode doesn't affect the rendered height of the SNES frame, so we can ignore it.
• "overscan" mode affects the rendered height of the SNES frame, but only changes it by a trivial 15 scanlines. Also, if a game toggles overscan mode, proper re-scaling of the frame would cause annoying jumping. Therefore, always reserve enough room to display a frame with overscan, and just letterbox the frame while overscan mode isn't being used (I believe this behaviour has been verified on hardware).
• To make it easier to center a non-overscan frame, and just because it's a rounder number, assume 240 scanlines rather than 239.
• Aspect-ratio correction does change the rendered width of the SNES frame, so multiply the 256 pixel frame width by the aspect-ratio correction factor. Suitable factors are available in the bsnes source (calculated by measuring the output of a SNES connected to a CRT, IIRC), and copy/pasted into my code above.
• Therefore, the scaling problem is to take a rectangle that is (256xratio) pixels wide, and 240 pixels high, and scale that to fit the available output area.

The code I linked above has a few extra features (like an "only integer scaling factors" mode, and the fact that "only integer scaling" is disabled if the output window is smaller in either dimension than the SNES frame), but it's still pretty simple.

I imagine the configuration UI would look something like this:

That's a lot simpler than the current batch of scaling options.

snes9x-gtk doesn't full screen right in any Window manager other than KDE. In Fluxbox, it spawns behind the window manager and you have to Alt-tab to bring it to the front. But it does work after that. In KDE it works right.

Is this the latest snapshot? I've tested it in several window managers (including Fluxbox) and it works for me in all of them.

I should be a bit more specific. It appears behind WahCade when launched from within WahCade in Fluxbox. Yes, it is in the latest snapshot. It is spawning behind WahCade. but in KDE, it spawns normally.

Ok, I tested fluxbox with wahcade, and I reproduced your problem. I was trying to fix it, but then I noticed that wahcade's own "About WahCade" option in its menu doesn't even switch focus properly. As a result, I'm going to suggest that the problem doesn't lie with Snes9x. In fact, it seems to work correctly with metacity, xfwm4, kwm, openbox, and compiz, so I'd guess that it's a fluxbox bug.

I notice minor sprite tearing and VSync problems on the Mario games, its not severe, but it does look bad. I've tried enabling vsync but it does not help.

Thanks for fixing my Window Manager problem, by the way.

Please tell us more details.

Its more like a sprite tearing or flicker when the entire screen schools, scroll to the right and sometimes part of the pipe will split in half and then catch up.

Which mario games?
Which build of snes9x are you using?

Super Mario All-Stars