I'd agree with that idea. Just remember to use --without-alsa on the portaudio configure script. I've been looking around, and it seems lots of OSS-only users are having this problem. Time to submit a bug report to portaudio.deniseweird wrote:Like I said ALSA is everywhere :S If anyone knows about a good OSS4-based distro, please tell me. Anyway, if I understood the Mandriva versioning system right, I am using version 19-10. Maybe I will try compiling the library manually.
GTK/X11 Port (aka Linux/UNIX GUI)
-
- Snes9x White Belt
- Posts: 41
- Joined: Wed Feb 20, 2008 9:38 am
Now it works! For any other OSS users, here's what to do.
* Remove portaudio if you have it installed.
* Download the portaudio source. I used the development version.
* Extract it somewhere.
Now do this:
If your system uses sudo instead of su, you skip the su command and do "sudo make install".
Now portaudio shouldn't care about ALSA, and everything should be fine in Snes9x. BearOso, maybe you could add this to the front page?
* Remove portaudio if you have it installed.
* Download the portaudio source. I used the development version.
* Extract it somewhere.
Now do this:
Code: Select all
cd SOMEDIRECTORY/portaudio
./configure --prefix=/usr --without-alsa
make
su
make install
Now portaudio shouldn't care about ALSA, and everything should be fine in Snes9x. BearOso, maybe you could add this to the front page?
-
- Snes9x White Belt
- Posts: 41
- Joined: Wed Feb 20, 2008 9:38 am
It actually only happens if you release the button during the resolution change. Just tap the direction button to fix it. I'm sure you easily figured that out.deniseweird wrote:Great release! I found a bug though. If you walk in a certain direction while switching to/from fullscreen, the controls get stuck with that movement even if you release the button.
This occurs because I have the program unmap the window when the resolution changes, so no events get through. The simple alternative to your problem would be clearing the joypad states so no buttons are pressed when the change occurs. But with that, someone who wants to hold a button through the resolution change will see an inconsistent state. Neither way is really correct.
The long way around is to poll the state of all keyboard bindings afterward to find whether or not they match. As Snes9x's port interface and GTK are both event-driven, this is a real pain. As this "bug" is fairly rare to trigger and easy to alleviate, I may or may not decide to mess with it.
-
- Snes9x White Belt
- Posts: 41
- Joined: Wed Feb 20, 2008 9:38 am
You should add -lXrandr to the GTKLIBS, because I've got
when building from sources. After appending -lXrandr snes9x-gtk has compiled fine.[/quote]g++ -fno-rtti -I. -Iunzip -o snes9x-gtk cpuops.o cpuexec.o sa1cpu.o spc700.o soundux.o apu.o apudebug.o fxinst.o fxemu.o fxdbg.o c4.o c4emu.o controls.o crosshairs.o cpu.o sa1.o debug.o sdd1.o tile.o srtc.o gfx.o memmap.o clip.o dsp1.o ppu.o dma.o snes9x.o data.o globals.o reader.o conffile.o bsx.o logger.o spc7110.o obc1.o seta.o seta010.o seta011.o seta018.o 2xsai.o sdd1emu.o cheats.o cheats2.o snaporig.o snapshot.o screenshot.o movie.o loadzip.o unzip/unzip.o unzip/explode.o unzip/unreduce.o unzip/unshrink.o jma/s9x-jma.o jma/7zlzma.o jma/crc32.o jma/iiostrm.o jma/inbyte.o jma/jma.o jma/lzma.o jma/lzmadec.o jma/winout.o gtk/gtk_s9x.o gtk/gtk_s9xwindow.o gtk/gtk_config.o gtk/gtk_file.o gtk/gtk_sound.o gtk/gtk_control.o gtk/gtk_display.o gtk/gtk_preferences.o gtk/gtk_glade.o gtk/gtk_cheat.o gtk/gtk_display_driver_gtk.o gtk/gtk_glade_window.o gtk/gtk_binding.o gtk/snes_ntsc.o gtk/gtk_display_driver_xv.o gtk/filter_hq2x.o gtk/filter_epx.o gtk/filter_2xsai.o gtk/gtk_display_driver_opengl.o -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -pthread -lgthread-2.0 -lrt -lgobject-2.0 -lglib-2.0 -lxml2 -lglade-2.0 -lgtk-x11-2.0 -lxml2 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lportaudio -lm -lpthread -lXv -Wl,--export-dynamic -lgtkglext-x11-1.0 -lgdkglext-x11-1.0 -lGLU -lGL -lXmu -lXt -lSM -lICE -lgtk-x11-2.0 -lpangox-1.0 -lX11 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lpthread -lm
gtk/gtk_s9xwindow.o: In function `Snes9xWindow::leave_fullscreen_mode()':
gtk_s9xwindow.cpp:(.text+0x837): undefined reference to `XRRSetScreenConfig'
gtk/gtk_s9xwindow.o: In function `Snes9xWindow::enter_fullscreen_mode()':
gtk_s9xwindow.cpp:(.text+0x9a0): undefined reference to `XRRSetScreenConfig'
gtk/gtk_s9xwindow.o: In function `Snes9xWindow::Snes9xWindow(Snes9xConfig*)':
gtk_s9xwindow.cpp:(.text+0x1f24): undefined reference to `XRRGetScreenInfo'
gtk_s9xwindow.cpp:(.text+0x1f36): undefined reference to `XRRConfigCurrentConfiguration'
gtk_s9xwindow.cpp:(.text+0x1f4b): undefined reference to `XRRConfigSizes'
gtk/gtk_s9xwindow.o: In function `Snes9xWindow::Snes9xWindow(Snes9xConfig*)':
gtk_s9xwindow.cpp:(.text+0x2194): undefined reference to `XRRGetScreenInfo'
gtk_s9xwindow.cpp:(.text+0x21a6): undefined reference to `XRRConfigCurrentConfiguration'
gtk_s9xwindow.cpp:(.text+0x21bb): undefined reference to `XRRConfigSizes'
collect2: ld returned 1 exit status
-
- Snes9x White Belt
- Posts: 2
- Joined: Mon Mar 17, 2008 2:12 am
I'm getting an error when building from sources.
My build system - Ubuntu Gutsy 7.10 on an AMD Athlon XP system.
Note: I'm also using an TNT2 card. Does that make a difference when I try and compile it?
My build system - Ubuntu Gutsy 7.10 on an AMD Athlon XP system.
Code: Select all
gtk/gtk_display_driver_opengl.o: In function `S9xOpenGLDisplayDriver::S9xOpenGLDisplayDriver(Snes9xWindow*, Snes9xConfig*)':
gtk_display_driver_opengl.cpp:(.text+0x7f8): undefined reference to `glXGetProcAddress'
gtk/gtk_display_driver_opengl.o: In function `S9xOpenGLDisplayDriver::S9xOpenGLDisplayDriver(Snes9xWindow*, Snes9xConfig*)':
gtk_display_driver_opengl.cpp:(.text+0x1078): undefined reference to `glXGetProcAddress'
collect2: ld returned 1 exit status
make: *** [snes9x-gtk] Error 1
No, the card doesn't matter. What is happening is that you're using GLX v1.4 headers, but linking against earlier GLX libraries. So your system is kind of messed up.SaxIndustries wrote:I'm getting an error when building from sources.
My build system - Ubuntu Gutsy 7.10 on an AMD Athlon XP system.
Note: I'm also using an TNT2 card. Does that make a difference when I try and compile it?Code: Select all
gtk/gtk_display_driver_opengl.o: In function `S9xOpenGLDisplayDriver::S9xOpenGLDisplayDriver(Snes9xWindow*, Snes9xConfig*)': gtk_display_driver_opengl.cpp:(.text+0x7f8): undefined reference to `glXGetProcAddress' gtk/gtk_display_driver_opengl.o: In function `S9xOpenGLDisplayDriver::S9xOpenGLDisplayDriver(Snes9xWindow*, Snes9xConfig*)': gtk_display_driver_opengl.cpp:(.text+0x1078): undefined reference to `glXGetProcAddress' collect2: ld returned 1 exit status make: *** [snes9x-gtk] Error 1
The best solution is to fix the discrepancy between the headers and libraries on your system. If you can't do that, open the source file gtk_display_driver_opengl.cpp in a text editor. Change line 236:
Code: Select all
#ifdef GLX_VERSION_1_4
Code: Select all
#if 0
[quote="BearOso"I'm pretty sure I've got the wrong byte order for the 15-24 bit RGB Xv modes, but have no way to test them. If anyone with Intel graphics sees problems, let me know.[/quote]
I just compiled v25 on a Macbook (Intel 945GM graphics) running Gutsy Gibbon, and the colors show up just fine in Xv mode. And unlike OpenGL mode, it doesn't hide the menus with Compiz running. Yay!
I have found a problem, though: when you turn on the NTSC scaling mode, the display gets vertically compressed, leaving solid blue bars at the top and bottom of the window. If you resize the window, sometimes these bars are repainted in blue, sometimes in black, and sometimes they're not repainted at all and you get the widget colour, or fragments of status-bar.
Also: I tried changing my button settings in the "SNES Joypads" tab, and although I can change a button by tabbing to it and pressing "Enter", the instructions at the bottom say "Click a button..." and this doesn't work - instead of staying depressed and listening for a key (as it does when I hit Enter), the on-screen button only stays depressed while I'm actually holding the mouse button down.
I just compiled v25 on a Macbook (Intel 945GM graphics) running Gutsy Gibbon, and the colors show up just fine in Xv mode. And unlike OpenGL mode, it doesn't hide the menus with Compiz running. Yay!
I have found a problem, though: when you turn on the NTSC scaling mode, the display gets vertically compressed, leaving solid blue bars at the top and bottom of the window. If you resize the window, sometimes these bars are repainted in blue, sometimes in black, and sometimes they're not repainted at all and you get the widget colour, or fragments of status-bar.
Also: I tried changing my button settings in the "SNES Joypads" tab, and although I can change a button by tabbing to it and pressing "Enter", the instructions at the bottom say "Click a button..." and this doesn't work - instead of staying depressed and listening for a key (as it does when I hit Enter), the on-screen button only stays depressed while I'm actually holding the mouse button down.
Could you clarify for me--do you mean that when you use the menus that they seem to open under the game image? If that's the case, then it is definitely a Compiz w/OpenGL driver issue. If it's something different, let me know and I'll try to fix it.Screwtape wrote:I just compiled v25 on a Macbook (Intel 945GM graphics) running Gutsy Gibbon, and the colors show up just fine in Xv mode. And unlike OpenGL mode, it doesn't hide the menus with Compiz running. Yay!BearOso wrote:I'm pretty sure I've got the wrong byte order for the 15-24 bit RGB Xv modes, but have no way to test them. If anyone with Intel graphics sees problems, let me know.
This bug seems to affect "Maintain Aspect Ratio." You can turn it off to get rid of any black bars. I've found and fixed the issue.I have found a problem, though: when you turn on the NTSC scaling mode, the display gets vertically compressed, leaving solid blue bars at the top and bottom of the window. If you resize the window, sometimes these bars are repainted in blue, sometimes in black, and sometimes they're not repainted at all and you get the widget colour, or fragments of status-bar.
I'm looking into this.Also: I tried changing my button settings in the "SNES Joypads" tab, and although I can change a button by tabbing to it and pressing "Enter", the instructions at the bottom say "Click a button..." and this doesn't work - instead of staying depressed and listening for a key (as it does when I hit Enter), the on-screen button only stays depressed while I'm actually holding the mouse button down.
*edit*
I've posted version 26. Let me know if the key binding fix works for you.
Wow, that's responsiveness!
Yeah, if I'm running SNES9x in OpenGL mode, and Compiz is also using OpenGL, then weird stuff happens like menus appearing underneath the game image. I don't know any other GTK+ apps that use OpenGL, though, so I can't tell if that's a bug in SNES9x or not. Besides, it makes sense that having two different uses of OpenGL simultaneously might make them trip over each other.BearOso wrote:Could you clarify for me--do you mean that when you use the menus that they seem to open under the game image? If that's the case, then it is definitely a Compiz w/OpenGL driver issue. If it's something different, let me know and I'll try to fix it.Screwtape wrote:I just compiled v25 on a Macbook (Intel 945GM graphics) running Gutsy Gibbon, and the colors show up just fine in Xv mode. And unlike OpenGL mode, it doesn't hide the menus with Compiz running. Yay!BearOso wrote:I'm pretty sure I've got the wrong byte order for the 15-24 bit RGB Xv modes, but have no way to test them. If anyone with Intel graphics sees problems, let me know.
I just checked, and yes, this works fine now.This bug seems to affect "Maintain Aspect Ratio." You can turn it off to get rid of any black bars. I've found and fixed the issue.I have found a problem, though: when you turn on the NTSC scaling mode, the display gets vertically compressed, leaving solid blue bars at the top and bottom of the window. If you resize the window, sometimes these bars are repainted in blue, sometimes in black, and sometimes they're not repainted at all and you get the widget colour, or fragments of status-bar.
I'm terribly sorry; this 'bug' was the result of me getting horribly confused about GTK: version 25 worked perfectly, it's just that in the 'click a button' case, I left the mouse-pointer over the button, and consequently the button was displayed in the 'hover' state instead of the 'active' state snes9x had asked for (to use the CSS terms, I think GTK calls them 'prelight' and 'active'). A side-note: nobody who ever needs to actually see anything on their display should ever buy a Macbook; the screens are horrid.I'm looking into this.Also: I tried changing my button settings in the "SNES Joypads" tab, and although I can change a button by tabbing to it and pressing "Enter", the instructions at the bottom say "Click a button..." and this doesn't work - instead of staying depressed and listening for a key (as it does when I hit Enter), the on-screen button only stays depressed while I'm actually holding the mouse button down.
*edit*
I've posted version 26. Let me know if the key binding fix works for you.
No need to fret--I've also had double takes at the appearance of those toggle buttons. Your "bug" also helped me notice a potential problem location where I was using memory addresses to test equality.Screwtape wrote: I'm terribly sorry; this 'bug' was the result of me getting horribly confused about GTK: version 25 worked perfectly, it's just that in the 'click a button' case, I left the mouse-pointer over the button, and consequently the button was displayed in the 'hover' state instead of the 'active' state snes9x had asked for (to use the CSS terms, I think GTK calls them 'prelight' and 'active'). A side-note: nobody who ever needs to actually see anything on their display should ever buy a Macbook; the screens are horrid.
-
- Snes9x White Belt
- Posts: 1
- Joined: Sun Mar 30, 2008 6:54 pm
Any chance you could build a AMD64 binary?
or a couple of .debs for i386 AND amd64?
The best place to host them would be at
http://www.getdeb.net/
Thanks for your great work
_________________
ATV Specs
The best place to host them would be at
http://www.getdeb.net/
Thanks for your great work
_________________
ATV Specs
Last edited by homerhomer on Sat Feb 21, 2009 1:28 pm, edited 1 time in total.
Re: Any chance you could build a AMD64 binary?
If the software is under an Ubuntu-friendly licence (and I believe snes9x is), probably the best place is an PPA ("Personal Package Archive") on Launchpad.net - you just upload your source .deb, and they take care of building your packages and setting up an apt repository and all that good stuff. It's really quite sweet.homerhomer wrote:or a couple of .debs for i386 AND amd64?
The best place to host them would be at
http://www.getdeb.net/
Re: Any chance you could build a AMD64 binary?
Thanks for the hint. Check outScrewtape wrote: If the software is under an Ubuntu-friendly licence (and I believe snes9x is), probably the best place is an PPA ("Personal Package Archive") on Launchpad.net - you just upload your source .deb, and they take care of building your packages and setting up an apt repository and all that good stuff. It's really quite sweet.
https://launchpad.net/~bearoso/+archive
These are marked for and built on Ubuntu gutsy, but they should also work on hardy and newer debian trees. I'll update the first post with a link to these.
*edit*
I also just posted a new release. This fixes several small bugs.