GTK/X11 Port (aka Linux/UNIX GUI)
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.
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.
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...
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):
Code: Select all
sudo tee /etc/apt/preferences.d/use-snes9x-ppa << EOF
Package: snes9x-gtk
Pin: release o=LP-PPA-bearoso
Pin-Priority: 600
EOF
sudo apt-get install snes9x-gtk
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.Screwtape wrote: 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").
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.Screwtape wrote: Also, if you guys implement the libsnes interface from bsnes, I've got some scripts that make regression testing really easy...
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.
"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.BearOso wrote:Hmm. I would have thought because 1.52.81 > 1.52 it would be fine, but I guess not.
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?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.Screwtape wrote:Also, if you guys implement the libsnes interface from bsnes, I've got some scripts that make regression testing really easy...
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.Screwtape wrote:"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?
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)
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.Screwtape wrote: "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?
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.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.
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 partThe 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.
![Smile :-)](./images/smilies/icon_smile.gif)
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.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?
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).Screwtape wrote: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?
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.Screwtape wrote:(that's a serious question, maybe TAS efforts depend on the current algorithm or something, I dunno)
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.BearOso wrote: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.
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.
![Sad :(](./images/smilies/icon_sad.gif)
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.
I imagine the configuration UI would look something like this:
Code: Select all
Scaling method: [Stretch |v] (what my code calls scale_max)
|Keep square pixels | (what my code calls scale_raw)
|Aspect-ratio correction| (scale_ntsc or scale_pal)
`-----------------------'
[X] Only use exact scaling factors
-
- Snes9x White Belt
- Posts: 29
- Joined: Wed Jun 24, 2009 2:58 am
snes9x-gtk doesn't full screen right in Fluxbox
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.
Re: snes9x-gtk doesn't full screen right in Fluxbox
Is this the latest snapshot? I've tested it in several window managers (including Fluxbox) and it works for me in all of them.zombie_ryushu wrote: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.
-
- Snes9x White Belt
- Posts: 29
- Joined: Wed Jun 24, 2009 2:58 am
Fluxbox and appearing behind things
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.
Re: Fluxbox and appearing behind things
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.zombie_ryushu wrote: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.
-
- Snes9x White Belt
- Posts: 29
- Joined: Wed Jun 24, 2009 2:58 am
Sprite tearing
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.
Thanks for fixing my Window Manager problem, by the way.
Re: Sprite tearing
Please tell us more details.zombie_ryushu wrote: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.
-
- Snes9x White Belt
- Posts: 29
- Joined: Wed Jun 24, 2009 2:58 am
VSync Sprite tearing
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.
-
- Snes9x White Belt
- Posts: 29
- Joined: Wed Jun 24, 2009 2:58 am
VSync Sprite tearing
Super Mario All-Stars