GTK/X11 Port (aka Linux/UNIX GUI)
OK, this means the ROM's actually loading. I have a couple more questions: Are you using the fullscreen-on-open option? And since you installed it, can you confirm things run when using the original unix Snes9x? (I believe the executable name is just "snes9x")didli wrote:Thanks for the quick reply !
it hangs just after choosing the rom. And with the command line too. Terminal says something about "Map_HiROMMAP" but nothing else happens.
No, but I will give it a try just to see if things happen...Are you using the fullscreen-on-open option ?
Yes, most of my games are running with the original Snes9x version. And I'm trying to find the command-line options for mono 8-bit with 320x240 video window.can you confirm things run when using the original unix Snes9x ?
And once again, thank you very much BearOso, I really appreciate the time you're spending to help me ...
I've looked, and in the unix port, there is no command-line option for selecting 8-bit sound. You have to edit ~/.snes96_snapshots/snes9x.conf to include SixteenBitSound=0 in the [Sound] section. I believe a file that looks like:didli wrote: Yes, most of my games are running with the original Snes9x version. And I'm trying to find the command-line options for mono 8-bit with 320x240 video window.
Code: Select all
[Sound]
SixteenBitSound = 0
I've tried to locate specifically where a lockup could occur in my version, but have been unable to. If you're willing to spend the time to compile the source using the --with-debug flag and get a stack trace, it would help greatly. If you want to help, follow the instructions at http://www.snes9x.com/phpbb2/viewtopic. ... c&start=37 except instead of waiting for a crash, press CTRL-Z in the terminal where gdb is running when you encounter the lockup and continue to follow the instructions.
-
- Snes9x White Belt
- Posts: 41
- Joined: Wed Feb 20, 2008 9:38 am
BearOso, you mentioned netplay as a "missing feature", wich I am guessing means a feature that will be added eventually. If so, is there any Free Libre Open Source standard for netplay available? Kaillera is closed source unfortunately so I am thinking it's not so good to use it. If there is none, are you planning to get a new standard? The VBA-M team is implementing link support to their emulator, and with that, maybe they will add netplay support to their emulator too. If they plan to do that, maybe you should help eachother out, to avoid code duplication? A lot of "if"'s I know, and I might be completely off, I don't know
I'm using the snes9x core implementation--the one used by the unix and windows ports--for the reason you mention, to avoid code duplication. Also, because it's the quickest and easiest method and it's compatible with the highest installed base. The Mac OS X port doesn't use the core Netplay support for one reason or another, but it's got a lot of Cocoa sprinkled in, making it difficult to convert.deniseweird wrote:BearOso, you mentioned netplay as a "missing feature", wich I am guessing means a feature that will be added eventually. If so, is there any Free Libre Open Source standard for netplay available? Kaillera is closed source unfortunately so I am thinking it's not so good to use it. If there is none, are you planning to get a new standard? The VBA-M team is implementing link support to their emulator, and with that, maybe they will add netplay support to their emulator too. If they plan to do that, maybe you should help eachother out, to avoid code duplication? A lot of "if"'s I know, and I might be completely off, I don't know
I've also looked at Kaillera. It's got a good reputation, but it's definitely out of the question as you've said.
Question:
Will it be possible to have a compiz video-plugin method for output? (With fallback to Xv, if compiz suddenly closes)
As it currently stands, Neither Xv nor OpenGL will work properly with window transformations using stable open source drivers. The plugin also purportedly has better performance.
Will it be possible to have a compiz video-plugin method for output? (With fallback to Xv, if compiz suddenly closes)
As it currently stands, Neither Xv nor OpenGL will work properly with window transformations using stable open source drivers. The plugin also purportedly has better performance.
I investigated the compiz mplayer output before, but it currently seems to be quite a hack. David Reveman has said in the past that he plans to do something more substantial (i.e. an actual Xv port for compiz), so I'd prefer to wait for either that or more info to decide. It might also be a good idea to see what DRI2 can do for OpenGL behavior over the next month or so.mrthefter wrote:Question:
Will it be possible to have a compiz video-plugin method for output? (With fallback to Xv, if compiz suddenly closes)
As it currently stands, Neither Xv nor OpenGL will work properly with window transformations using stable open source drivers. The plugin also purportedly has better performance.
Since I've been distracted and haven't posted a new update in a while, I thought I'd give a little more info on what I've been aiming for.
For the next release, I've begun a little work by integrating the sparse unix NetPlay client. I'm hoping I'll be able to work the server in so that hosting is a transparent process.
After that, I see two things remaining before this port is essentially "feature complete": cheat search and key combos. Of course, I'm also open for more suggestions, like the compiz output that mrthefter mentioned.
For the next release, I've begun a little work by integrating the sparse unix NetPlay client. I'm hoping I'll be able to work the server in so that hosting is a transparent process.
After that, I see two things remaining before this port is essentially "feature complete": cheat search and key combos. Of course, I'm also open for more suggestions, like the compiz output that mrthefter mentioned.
Actually, I just stumbled across something better:
XVideo textured video output. It's one of the new things DRI2 is adding to all the drivers (on hardware that supports it. if it supports compiz, it'll probably support it), but currently, intel has it on DRI2 architecture, and the opensource radeon driver on the current DRI arch (not radeonhd) has it up to r500 series (rv250 excluded, hardware bug. I'm trying to work around it).
All being said, it seems your xv code can't cope with it, because it crashes with an X error if I try and set xv output. Other software have this problem, too; has something to do with the different params the textured video port spits out. Incidentally, I didn't have this problem before, because textured video was set to not load due to blacklisting my rv250.
EDIT: Forgot to say what the benefits were. It's still hardware accelerated, not as fast as overlay, but it allows compositor transforms, aka, compiz works with it.
XVideo textured video output. It's one of the new things DRI2 is adding to all the drivers (on hardware that supports it. if it supports compiz, it'll probably support it), but currently, intel has it on DRI2 architecture, and the opensource radeon driver on the current DRI arch (not radeonhd) has it up to r500 series (rv250 excluded, hardware bug. I'm trying to work around it).
All being said, it seems your xv code can't cope with it, because it crashes with an X error if I try and set xv output. Other software have this problem, too; has something to do with the different params the textured video port spits out. Incidentally, I didn't have this problem before, because textured video was set to not load due to blacklisting my rv250.
EDIT: Forgot to say what the benefits were. It's still hardware accelerated, not as fast as overlay, but it allows compositor transforms, aka, compiz works with it.
Can you please post the output from the command "xvinfo" when video-texture is enabled? This will give me a better picture of which visuals are being reported.mrthefter wrote: All being said, it seems your xv code can't cope with it, because it crashes with an X error if I try and set xv output. Other software have this problem, too; has something to do with the different params the textured video port spits out. Incidentally, I didn't have this problem before, because textured video was set to not load due to blacklisting my rv250.
-
- Snes9x White Belt
- Posts: 41
- Joined: Wed Feb 20, 2008 9:38 am
-
- Snes9x White Belt
- Posts: 2
- Joined: Mon Mar 17, 2008 2:12 am
Ok, this is now available in version 30(a). The binding is in Preferences->GUI Shortcuts->Emulator and at the bottom. I was reluctant to put this in before, as I assumed some people would bind it to a convenient button and accidentally hit it.SaxIndustries wrote:I have a feature request!
I'm currently using SNES9x-GTK with MythTV. I use a gamepad to navigate all the menus, so I was wondering, would it be possible to add a GUI shortcut to quit the emulator? The idea being, map an unused button on the pad to exiting the game.
Thanks!
Fedora 9 users, here is a list of packages you need to install (for full gtk and opengl support)
gtk2-devel
libglade2-devel
libXv-devel
SDL-devel
portaudio-devel
gtkglext-devel
also you will need
gcc
gcc-c++
autoconf
automake
possibly libtool, I'm not 100% sure on this one, I just already had it installed for a previous build
lastly make sure you have DRI enabled! To check open your local neighborhood terminal and type:
glxinfo | grep 'direct rendering'
if it does NOT output 'direct rendering=Yes' then you need to get it enabled. Usually installing nvidia or ati drivers will fix this.
simply put these into yum and it will download a plethora of packages, and should hit every last dependency for snes9x-gtk.
then download and build the source as directed in the OP
Be prepared for a lot of warnings... this is something I've come to notice with F9 over F8. But do not distress, it will still work fine as long as you do not miss the dependencies as listed above.
PS if I forgot a package please say so
btw great work as always BearOse!
gtk2-devel
libglade2-devel
libXv-devel
SDL-devel
portaudio-devel
gtkglext-devel
also you will need
gcc
gcc-c++
autoconf
automake
possibly libtool, I'm not 100% sure on this one, I just already had it installed for a previous build
lastly make sure you have DRI enabled! To check open your local neighborhood terminal and type:
glxinfo | grep 'direct rendering'
if it does NOT output 'direct rendering=Yes' then you need to get it enabled. Usually installing nvidia or ati drivers will fix this.
simply put these into yum and it will download a plethora of packages, and should hit every last dependency for snes9x-gtk.
then download and build the source as directed in the OP
Be prepared for a lot of warnings... this is something I've come to notice with F9 over F8. But do not distress, it will still work fine as long as you do not miss the dependencies as listed above.
PS if I forgot a package please say so
btw great work as always BearOse!