Page 8 of 31
Posted: Mon Mar 10, 2008 4:50 pm
by BearOso
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.
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.

Posted: Mon Mar 10, 2008 7:10 pm
by deniseweird
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:
Code: Select all
cd SOMEDIRECTORY/portaudio
./configure --prefix=/usr --without-alsa
make
su
make install
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?

Posted: Tue Mar 11, 2008 10:33 pm
by BearOso
Another revision is up. It's mostly bug fixes.
Posted: Wed Mar 12, 2008 2:37 pm
by deniseweird
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.
Posted: Thu Mar 13, 2008 11:07 pm
by BearOso
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.
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.
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.
Posted: Fri Mar 14, 2008 1:51 pm
by deniseweird
You don't have to mess with it. I thought it was a new bug that appeared, but it's not something I am annoyed at.

Posted: Fri Mar 14, 2008 8:27 pm
by ojab
You should add -lXrandr to the GTKLIBS, because I've got
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
when building from sources. After appending -lXrandr snes9x-gtk has compiled fine.[/quote]
Posted: Sat Mar 15, 2008 1:06 am
by BearOso
ojab wrote:You should add -lXrandr to the GTKLIBS, because I've got
when building from sources. After appending -lXrandr snes9x-gtk has compiled fine.
Thanks, I've fixed this along with another bug in the new revision that's posted.
Posted: Mon Mar 17, 2008 2:15 am
by SaxIndustries
I'm getting an error when building from sources.
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
Note: I'm also using an TNT2 card. Does that make a difference when I try and compile it?
Posted: Mon Mar 17, 2008 3:10 am
by BearOso
SaxIndustries wrote:I'm getting an error when building from sources.
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
Note: I'm also using an TNT2 card. Does that make a difference when I try and compile it?
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.
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:
to instead read:
Then run "make gtkclean" in the source directory. Things should build correctly after that.
Posted: Sat Mar 22, 2008 1:10 am
by BearOso
A new version is available. This adds support for RGB output in Xv.
*edit*
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.
Posted: Sun Mar 23, 2008 12:44 am
by Screwtape
[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.
Posted: Sun Mar 23, 2008 6:52 am
by BearOso
Screwtape wrote: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 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!
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.
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.
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.
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'm looking into this.
*edit*
I've posted version 26. Let me know if the key binding fix works for you.
Posted: Sun Mar 23, 2008 10:06 am
by Screwtape
Wow, that's responsiveness!
BearOso wrote:Screwtape wrote: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 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!
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.
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.
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.
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 just checked, and yes, this works fine now.
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'm looking into this.
*edit*
I've posted version 26. Let me know if the key binding fix works for you.
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.

Posted: Sun Mar 23, 2008 10:31 am
by BearOso
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.

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.
Any chance you could build a AMD64 binary?
Posted: Sun Mar 30, 2008 6:56 pm
by homerhomer
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
Re: Any chance you could build a AMD64 binary?
Posted: Mon Mar 31, 2008 9:09 am
by Screwtape
homerhomer wrote:or a couple of .debs for i386 AND amd64?
The best place to host them would be at
http://www.getdeb.net/
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.
Re: Any chance you could build a AMD64 binary?
Posted: Mon Mar 31, 2008 3:46 pm
by BearOso
Screwtape 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.
Thanks for the hint. Check out
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.
Posted: Tue Apr 01, 2008 9:57 pm
by BearOso
byuu wrote:Ugh, okay, I have to ask ...
BearOso, what the hell is your avatar supposed to be, exactly? o.O
It's a picture of Beelzebub, cropped from a screenshot of Shin Megami Tensei III.
