Snes9x.com

Pushed version.

When I try to compile on my PPC Mac Mini, running Ubuntu Hardy 8.04 LTS, everything goes well, but at the end, I get this:
any help?

Pushed another version.

mikel-14 wrote:When I try to compile on my PPC Mac Mini, running Ubuntu Hardy 8.04 LTS, everything goes well, but at the end, I get this:

Code: Select all

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 netplay.o server.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/filter_hq2x.o gtk/filter_epx.o gtk/filter_2xsai.o gtk/gtk_display_driver_opengl.o gtk/gtk_netplay_dialog.o gtk/gtk_netplay.o gtk/gtk_display_driver_xv.o  -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -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 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0   -lportaudio -lm -lpthread   -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 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0   `sdl-config --libs` -lXv -lXext -lXext -lXrandr -lpthread -lm
gtk/gtk_display.o: In function `S9xInitDisplay':
gtk_display.cpp:(.text+0x1af4): undefined reference to `InitLUTs()'
gtk/gtk_display.o: In function `internal_filter(unsigned char*, int, unsigned char*, int, int&, int&)':
gtk_display.cpp:(.text+0x1c14): undefined reference to `HQ2X_16(unsigned char*, unsigned int, unsigned char*, unsigned int, int, int)'
gtk_display.cpp:(.text+0x1d24): undefined reference to `HQ3X_16(unsigned char*, unsigned int, unsigned char*, unsigned int, int, int)'
gtk_display.cpp:(.text+0x1d4c): undefined reference to `HQ4X_16(unsigned char*, unsigned int, unsigned char*, unsigned int, int, int)'
collect2: ld returned 1 exit status
make: *** [snes9x-gtk] Error 1

any help?

The hq2x object likely isn't being linked correctly or is corrupt. Delete the gtk/filter_hq2x.o file or run a make clean and try again.

BearOso wrote:The hq2x object likely isn't being linked correctly or is corrupt. Delete the gtk/filter_hq2x.o file or run a make clean and try again.

Sorry, my fault. I forgot to say that while compiling, my computer crashed. After rebooting, I forgot to run make clean, so that's why that happened. Anyway, i did realize that I forgot to run make clean about 5 min after I posted, and I had to go, so I didn't post that it got fixed...

Anyway,
THIS GUI IS GREAT!!!
Now I don't have to reboot into OSX to have a good emulator!

However, I'm not sure if it's because of Ubuntu, but many programs that I've compiled in both OSX and Ubuntu run MUCH faster in OSX. In ubuntu, snes9x runs fullscreen at ~30/60 while Snes9x in OSX stays always at 60. And it happens with many more apps where it runs much faster in osx... Does somebody know something about this?

mikel-14 wrote:Now I don't have to reboot into OSX to have a good emulator!

My thoughts exactly. Now, if only we could pursuade BearOso to write front-ends for Gambatte, Nestopia and VBA-M...

mikel-14 wrote:However, I'm not sure if it's because of Ubuntu, but many programs that I've compiled in both OSX and Ubuntu run MUCH faster in OSX. In ubuntu, snes9x runs fullscreen at ~30/60 while Snes9x in OSX stays always at 60. And it happens with many more apps where it runs much faster in osx... Does somebody know something about this?

In my experience, most of the performance difference between OS X and Ubuntu comes from video drivers - Apple's video drivers were written by Apple engineers with the full assistance and enthusiastic support of nVidia and/or ATi engineers, while Linux' video drivers were written by Linux engineers, at whom nVidia and/or ATi engineers bite their thumbs, waggle their anatomy and generally direct disrespectful behaviour.

I suggest using XVideo scaling rather than OpenGL, since it's more likely to work properly in Free Software drivers. (Software scaling works, but is even slower)

Screwtape wrote:My thoughts exactly. Now, if only we could pursuade BearOso to write front-ends for Gambatte, Nestopia and VBA-M...

I think this should get into the official Snes9x release before any of that... And, as far as I know, VBA-M has no public release, yet...
And as for Nestopia, I think a Mednafen GUI (not launchers-frontend) would be better.

Screwtape wrote:In my experience, most of the performance difference between OS X and Ubuntu comes from video drivers - Apple's video drivers were written by Apple engineers with the full assistance and enthusiastic support of nVidia and/or ATi engineers, while Linux' video drivers were written by Linux engineers, at whom nVidia and/or ATi engineers bite their thumbs, waggle their anatomy and generally direct disrespectful behaviour.

ATi never helped Open source drivers (except for the new radeonhd... or was it another one?) and probably will never. I got my Mac Mini 3 months before the new ones with Intel came out... so I'm stuck with radeon driver...
However, it's much better than being stuck with a PowerPC and a Nvidia card, where you will never get 3D.

Screwtape wrote:I suggest using XVideo scaling rather than OpenGL, since it's more likely to work properly in Free Software drivers. (Software scaling works, but is even slower)

I already noticed that. It runs much better. OpenGL screws up the sound and goes at 17fps, XVideo is much better for this. But, to make it work, I had to 'Force an inverted byte-ordering', otherwise I would have REALLY weird colors... Maybe it's because of PPC = big endian.

Hmm, what does XVideo have to do with YUV?

mikel-14 wrote:However, it's much better than being stuck with a PowerPC and a Nvidia card, where you will never get 3D.

/me sighs at his PowerMac G5 and GeForce 5200 FX.

We'll see if the Nouveau people can figure something out before I replace this machine with something else, though.

mikel-14 wrote:

Screwtape wrote:I suggest using XVideo scaling rather than OpenGL, since it's more likely to work properly in Free Software drivers. (Software scaling works, but is even slower)

I already noticed that. It runs much better. OpenGL screws up the sound and goes at 17fps, XVideo is much better for this. But, to make it work, I had to 'Force an inverted byte-ordering', otherwise I would have REALLY weird colors... Maybe it's because of PPC = big endian.

Yeah, BearOso put that toggle in for PPC users like us. Apparently the video driver says 'I want XVideo data in machine-native byte-order', assuming that the GPU and CPU use the same ordering, but apparently it's wrong.

mikel-14 wrote:Hmm, what does XVideo have to do with YUV?

XVideo lets you throw pictures at the video-card, and let the video-card do the hard work of stretching it to the appropriate size, etc. Normally these pictures come from video sources, and most video sources use the YUV colour space for maximum compression, so most video cards allow you to upload YUV images and let the video-card convert them to RGB as well as scale them - since the video-card is doing some heavy number crunching anyway, it might as well do all of it.

nitsuja wrote:

kRogue wrote:why the hell would it want to draw a cube??

At least in the Windows port there's a sort of easter egg where you press Shift+6 in OpenGL mode and it draws a spinning cube with the game rendered on every side while you play it. It's an instant fix for Super Mario Kart being too easy. The code for that may have been ported along with the other OpenGL code even if the Unix port never uses it.

you should add that easter egg if the code got ported to the unix version

byuu wrote:The big problem is that a lot of drivers lack RGB support in XVideo, which forces you to use YUV in those cases.

Gotten that error on the last two or three builds posted. Compiling on Yellow Dog Linux for PS3. Used --without-opengl --without-assembler when configuring.

zerojay wrote:

Code: Select all

g++  -fno-rtti  -I. -Iunzip  -c -O2 -fomit-frame-pointer -fno-exceptions -Wall -W -pedantic -Wno-unused-parameter -pipe   -I. -Iunzip  -DMITSHM -DCPU_SHUTDOWN -DSPC700_SHUTDOWN   -DUSE_THREADS -DSPC700_C  -DUNZIP_SUPPORT -DJMA_SUPPORT      -DSDD1_DECOMP -DCORRECT_VRAM_READS  -DNO_INLINE_SET_GET  -DNOASM -DNEW_COLOUR_BLENDING -DZLIB -DHAVE_LIBPNG -DHAVE_MKSTEMP -DHAVE_STRINGS_H -DHAVE_SYS_IOCTL_H -DHAVE_STDINT_H -DRIGHTSHIFT_int8_IS_SAR -DRIGHTSHIFT_int16_IS_SAR -DRIGHTSHIFT_int32_IS_SAR -DRIGHTSHIFT_int64_IS_SAR -DRIGHTSHIFT_IS_SAR '-DACCEPT_SIZE_T=socklen_t' cheats.cpp -o cheats.o
g++  -fno-rtti  -I. -Iunzip  -c -O2 -fomit-frame-pointer -fno-exceptions -Wall -W -pedantic -Wno-unused-parameter -pipe   -I. -Iunzip  -DMITSHM -DCPU_SHUTDOWN -DSPC700_SHUTDOWN   -DUSE_THREADS -DSPC700_C  -DUNZIP_SUPPORT -DJMA_SUPPORT      -DSDD1_DECOMP -DCORRECT_VRAM_READS  -DNO_INLINE_SET_GET  -DNOASM -DNEW_COLOUR_BLENDING -DZLIB -DHAVE_LIBPNG -DHAVE_MKSTEMP -DHAVE_STRINGS_H -DHAVE_SYS_IOCTL_H -DHAVE_STDINT_H -DRIGHTSHIFT_int8_IS_SAR -DRIGHTSHIFT_int16_IS_SAR -DRIGHTSHIFT_int32_IS_SAR -DRIGHTSHIFT_int64_IS_SAR -DRIGHTSHIFT_IS_SAR '-DACCEPT_SIZE_T=socklen_t' cheats2.cpp -o cheats2.o
make: *** No rule to make target `unix/unix.o', needed by `snes9x'.  Stop.

Gotten that error on the last two or three builds posted. Compiling on Yellow Dog Linux for PS3. Used --without-opengl --without-assembler when configuring.

You might have forgotten --with-gtk. If you're actually trying to build the original unix port, it's now excluded from the prepatched source to save space, so for that you'll need the original source tarball.

hello and excuse my bad English, but I am using the translation tool to be able to google publish my problem here.

look BearOso

Starting program: /sdb2/snes9x-1.51-src/snes9x-gtk
[Thread debugging using libthread_db enabled]
[New Thread 0xb6129740 (LWP 8832)]
Starting sound
--> (OSS : /dev/dsp)...OK
Map_LoROMMap
[New Thread 0xb3ec6b90 (LWP 8837)]

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb6129740 (LWP 8832)]
0xb7f16410 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7f16410 in __kernel_vsyscall ()
#1 0xb71c5085 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb71c6a01 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0xb763bac8 in ?? () from /usr/lib/libGL.so.1
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)

This is the problem that gives me the program after any load a game.

certainly it gives me the problem with any version, is compiled or in this format .deb


just give me this mistake when he put with opengl

1985a wrote:hello and excuse my bad English, but I am using the translation tool to be able to google publish my problem here.

look BearOso

Starting program: /sdb2/snes9x-1.51-src/snes9x-gtk
[Thread debugging using libthread_db enabled]
[New Thread 0xb6129740 (LWP 8832)]
Starting sound
--> (OSS : /dev/dsp)...OK
Map_LoROMMap
[New Thread 0xb3ec6b90 (LWP 8837)]

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb6129740 (LWP 8832)]
0xb7f16410 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7f16410 in __kernel_vsyscall ()
#1 0xb71c5085 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb71c6a01 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0xb763bac8 in ?? () from /usr/lib/libGL.so.1
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)

This is the problem that gives me the program after any load a game.

certainly it gives me the problem with any version, is compiled or in this format .deb


just give me this mistake when he put with opengl

It looks like it's crashing inside your video driver and clobbering the stack, which prevents gdb from showing what in Snes9x is triggering it. If you turn off all the extra options under OpenGL, does it still crash? Can you tell me what brand of video card and what drivers you're using?

I could solve the problem, apparently was the videocard that was making contacts in the motherboard.

because I do opengl as evidence and said that they saw no end or I threw a mistake.

I certainly would like to know how good could have timings to play online with a friend.

hey, sorry if this problem has been posted already (I skimmed through the thread and didn't notice anything)

I'm running rev 52 -- everything for the most part works well except for saving and loading states; when I do either the program crashes

when I save state it closes the program with no output and creates a snapshot, when I load a state the program closes with this output

one other thing I noticed is that when you have force SNES-hires output enabled the hq filters cause the app to crash

I also forgot to mention that this is absolutely amazing work you've done Thanks

prurigro wrote:hey, sorry if this problem has been posted already (I skimmed through the thread and didn't notice anything)

I'm running rev 52 -- everything for the most part works well except for saving and loading states; when I do either the program crashes

when I save state it closes the program with no output and creates a snapshot, when I load a state the program closes with this output

Code: Select all

absent: SA1(50); next: 'SHO:734213:'
absent: SP7(65596); next: 'SHO:734213:'
absent: RTC(24); next: 'SHO:734213:'
absent: BSX(147); next: 'SHO:734213:'
absent: MOV(4); next: 'SHO:734213:'
absent: DSP(1450); next: 'SHO:734213:'
absent: CX4(8192); next: 'SHO:734213:'
absent: IPU(0); next: 'SHO:734213:'
absent: GFX(0); next: 'SHO:734213:'

The loading output is normal, but the crashing isn't. I can't reproduce it myself...

one other thing I noticed is that when you have force SNES-hires output enabled the hq filters cause the app to crash

Is this with hq2x, too? There is fallback code that should drop the hq filters down to hq2x when hires is enabled. Once again, I can't reproduce this with any of the output drivers or hq filters enabled.
If you can generate a backtrace as described in http://www.snes9x.com/phpbb2/viewtopic. ... c&start=37 it would be immensely helpful for fixing these bugs.

ahh true, I'd forgotten about gdb!

the backtrace for the save load state issue seems to suggest the problem; I haven't tested with loading, but when I saved the state the backtrace gave me

#0 0x0829e916 in HQ4X_16 ()

I then tried saving and loading states without hq4 on and found no problems (using filters : none)

as for the hires problem, strangely I wasn't able to recreate it- I'd deleted my config since trying to fix the save state problem so there may have been some setting that contributed to the problem; I'll submit a proper gdb report if I find it again

edit : I have confirmed that the save/load state crash occurs with all hq filters and none of the others

prurigro wrote:ahh true, I'd forgotten about gdb!

the backtrace for the save load state issue seems to suggest the problem; I haven't tested with loading, but when I saved the state the backtrace gave me

#0 0x0829e916 in HQ4X_16 ()

I then tried saving and loading states without hq4 on and found no problems (using filters : none)

as for the hires problem, strangely I wasn't able to recreate it- I'd deleted my config since trying to fix the save state problem so there may have been some setting that contributed to the problem; I'll submit a proper gdb report if I find it again

edit : I have confirmed that the save/load state crash occurs with all hq filters and none of the others

So you're still experiencing the save/load state crash, then? If so, then the full output from the gdb stack trace (not just the top frame) will still be helpful for me to analyze and fix what is going wrong.