GTK/X11 Port (aka Linux/UNIX GUI)

[zombie_ryushu]

when switching into full screen mode from the command line, snes-gtk runs behind other applications, and I have to alt-tab to run it in the foreground.

[Screwtape]

I get Assertion failed errors trying to launch this application from the command line. How do I report a bug?

Well, mentioning how you installed it, whether you compiled it yourself, and the actual error-messages that appear would be a start.

when switching into full screen mode from the command line, zsnes runs behind other applications, and I have to alt-tab to run it in the foreground.

This is the thread for SNES9x; zsnes questions go over there.

[zombie_ryushu]

I made a mistake mentioning zsnes on accident, I apologize.

I also found out that the reason that the Assertion failed errors were the result of me hitting control break when snes9x-gtk launched in the background.

That being said, there is still the issue of snes9x-gtk running in the background. It causes xrandr to switch the card into 320x240. But it keeps KDE in the foreground.

This was built by the Mandriva distributors. It is an official repository package. I don't think it has been patched. Because it buts KDE in the foreground, it tends to resize all my windows.

[Kernigh]

I got ppu-gcc to work. I think I just wasn't being patient enough for it to compile filter_hq2x.cpp; it takes a long time to compile on a PS3.

That seems normal, because filter_hq2x.cpp also needs a long time to compile on my system, which is a PowerBook G4 (with an MPC7447A PowerPC processor) converted to run OpenBSD instead of Mac OS X. My compiler was the g++ 3.3.5 bundled with OpenBSD.

I tried to upgrade from delta-71 to delta-73 today, and I watched the slow compilation of filter_hq2x.cpp

Later I met a compiler error. I put that in as Issue 8: "powerof2" macro in BSD <sys/param.h> conflicts with gtk_sound.h. As I tell in the bug report, I fixed the compiler error, but delta-73 produced no sound, so I downgraded to delta-71.

Meanwhile, I worry about a different bug. I assembled a ROM image that consistently crashes delta-71. So I have a bug in the ROM, but I must also have a bug in the emulator.

[zombie_ryushu]

snes9x-gtk still launches behind whatever Window manager I start it from. (KDE, WahCade. etc.) Can this be fixed?

[BearOso]

Recently I've been messing with the sound core and the DMA timing problems, so I haven't gotten around to these issues yet. I'll try to get a new bug-fix release out later today.

[BearOso]

I've posted a new version. If anyone continues to experience problems with what I think I've fixed, let me know.

[zombie_ryushu]

Most ofthe time, I run my emulators in 320x240 on my TV, and 640x480 on my CRT monitor. The problem is snes9x-gtk tends to "lose" my configuration. My CRT usually runs at 1680x1050, and my TV runs at 740x480. (Attached to the same card.)

snes9x-gtk will "forget" the resolution its set at and try to use a resolution the TV has no support for, making the emulator *appear* to crash when it hasn't. It just has to be manually reset. Will you correct this problem?

[BearOso]

Most ofthe time, I run my emulators in 320x240 on my TV, and 640x480 on my CRT monitor. The problem is snes9x-gtk tends to "lose" my configuration. My CRT usually runs at 1680x1050, and my TV runs at 740x480. (Attached to the same card.)

snes9x-gtk will "forget" the resolution its set at and try to use a resolution the TV has no support for, making the emulator *appear* to crash when it hasn't. It just has to be manually reset. Will you correct this problem?

Sure, I will do this. This is just a matter of storing the actual resolution instead of the mode index and matching/validating the mode on-the-fly.

[zombie_ryushu]

If your card has TV Out, connect up via SVideo. Make sure your X Configuration uis set for separate X Servers, not Twinview. then, on your VGA monitor, set a resolution. move over to the TV screen on the SVideo port (to the right of.)

The resolution in the settings pull down bar will be blank.

[Blobbie]

snes9x-gtk works tremendously well. I love how easy it is to configure everything and the menu GUI looks and works great too. I just have one issue. I set things up so my kids can use the emulator and they're used to hitting ESC in every other emulator to quit the application. It would be really great if this could be an option to configure just like ESC can be made to either switch between fullscreen and window mode or just present the console menu in fullscreen mode. This will also have the added advantage of keeping them away form the configuration settings. I tried setting the quit application shortcut to ESC but that didn't work out

Thanks for making snes9x great in linux.

[BearOso]

I've uploaded another revision.

[Blobbie]

I've uploaded another revision.

Compiles and works great in Ubuntu Jaunty - 64.

Many thanks for the escape key to quit feature.

[zombie_ryushu]

The Full screening bug is back, but it only happens when launched from within WahCade. (Or at the command line.)

The game launches but is in the background until maximized.

The load Rom menu is fine.

Actually, the solution to this problem may be known already to the author of Gens-gs.

He had a similar persistant problem with Gens-gs.

# [Unix] Starting Gens/GS with the "--fs" option or "Full Screen=1" in the configuration file works properly. Previously, the GTK+ UI would be created after SDL was set to fullscreen, which caused SDL to revert to windowed mode, resulting in all sorts of screwiness.

That was the source of his problems. You might want to ckeck your GTK hooks to see if this has caused the same thing.

[BearOso]

The Full screening bug is back, but it only happens when launched from within WahCade. (Or at the command line.)

The game launches but is in the background until maximized.

The load Rom menu is fine.

Actually, the solution to this problem may be known already to the author of Gens-gs.

He had a similar persistant problem with Gens-gs.

# [Unix] Starting Gens/GS with the "--fs" option or "Full Screen=1" in the configuration file works properly. Previously, the GTK+ UI would be created after SDL was set to fullscreen, which caused SDL to revert to windowed mode, resulting in all sorts of screwiness.

That was the source of his problems. You might want to ckeck your GTK hooks to see if this has caused the same thing.

It's more the fact that everything happens at the same time in the server, and changing the resolution needs to be a step-by-step process.

I've committed a more aggressive approach to this to SVN. If you want to test it, checkout instructions are at http://code.google.com/p/snes9x-gtk/source/checkout. You can also try adding the --sync parameter to the command-line (forces GTK+ events to be synchronous), but it's less likely to work.

[zombie_ryushu]

The SVN compiles a command line only version.

[BearOso]

The SVN compiles a command line only version.

Change to the gtk subdirectory first. A different set of configure scripts is there.

[TiZ]

Using my PS2 adapter, which maps the d-pad to axes 4 and 5 when analog mode is on, pressing any button on the d-pad will cause it to quit with a segmentation fault.

This behavior is also exhibited in FCEUX, Gens/GS, and one of Mupen64's input plugins, but not in Neverball. These, and Snes9x-gtk, are all SDL apps.

What could be the problem here?

[BearOso]

Using my PS2 adapter, which maps the d-pad to axes 4 and 5 when analog mode is on, pressing any button on the d-pad will cause it to quit with a segmentation fault.

This behavior is also exhibited in FCEUX, Gens/GS, and one of Mupen64's input plugins, but not in Neverball. These, and Snes9x-gtk, are all SDL apps.

What could be the problem here?

The face buttons are analog, so this probably rearranges the axis order when analog mode is enabled. SDL, in all likelihood, doesn't reallocate the axes on open devices when the mode changes. Are you changing the digital/analog mode while the program is running? Doing that will cause problems.

[TiZ]

Using my PS2 adapter, which maps the d-pad to axes 4 and 5 when analog mode is on, pressing any button on the d-pad will cause it to quit with a segmentation fault.

This behavior is also exhibited in FCEUX, Gens/GS, and one of Mupen64's input plugins, but not in Neverball. These, and Snes9x-gtk, are all SDL apps.

What could be the problem here?

The face buttons are analog, so this probably rearranges the axis order when analog mode is enabled. SDL, in all likelihood, doesn't reallocate the axes on open devices when the mode changes. Are you changing the digital/analog mode while the program is running? Doing that will cause problems.

No, I do not switch while the program's running. I can switch while using jstest without any complications; the axes are still there, but not used.

I start said programs with analog mode already on, hit any direction on the d-pad, and the program segfaults.