libretro / snes9x2010 Goto Github PK

Hi,

I'm trying to compile. This is the error I'm getting:

./src/emu-ps3.cpp:1122: error: 'bool emulator_init_system()' was declared 'extern' and later 'static

The snes9x2010 core is not building for armeabi-v7a and is missing from the buildbot.

http://buildbot.libretro.com/nightly/android/latest/armeabi-v7a/

Hi,

I've always installed new snes9x versions over the last installed.

Yesterday I installed the snes9x-next compiled by Peter_uk and always got black screen when trying to load any game. And I can't even go back to the menu using R3+L3.

So, my only solution was to delete this version through dashboard.

Then I reinstalled the last version I was using, but now I've got some 80010006 errors from the dashboard and can't even enter the first screen of snes9x.

I deleted it again and installed an older version I've got from ps3hax foruns. Only now it worked properly.

These are anomalous behaviors and I don't know what did happen.

Right now it's possible to input up+down or left+right. This is possible on the real system but only with a modified or broken controller, and some games respond badly to them, so they should probably be filtered out, at least by default. It's also useful, notable example: http://www.youtube.com/watch?v=JZ6pDAqN7gQ

It should be mentioned this also affects the bsnes core, but that was addressed in v090 and can probably be backported. It also affects QuickNES and bnes but not Nestopia, some NES games also hate these inputs. I don't know how it is for other systems or cores.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

SNES9x-next appears to be cropping overscan when crop overscan is set to OFF and not cropping overscan when crop overscan is set to ON.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

When compiling on ARM, it assumes MSB first byteorder, when on ARM most systems are LSB first. This patch uses more macros to detect these platforms and set the preprocessor defines correctly.

https://gist.github.com/2908167

Games that uses HDMA are not correctly displayed, it is more likely that HDMA is not working at all (turned off). I tested the same on snes9x core and CatSFC core and HDMA is displayed correctly. I test some older version and same behaviour. Not sure if it is a know issue.

Hi,

Now that I've successfully compiled the emulator, I tested it a bit.

Power Ranger Zeo (or Neo, can't remember), show black screen when a race is to begin. I can see a blink of the track only after pause the game.

I don't know if it's an old issue.

There is a graphical glitch on the save/load screen and name entry screen when playing FFIII. Instead of solid blue, the windows have two shades of blue.

Due to how the main emulator loop is written, there will currently (in the ideal case, with no game induced lag) always be two frames of lag until the emulator can produce a frame corresponding to a certain input. This is due to the fact that each call to the main loop starts at V=0, by rendering what was calculated in the previous frame. After the frame has been produced, the emulator reads input and runs additional logic in the vertical blanking interval (at least this is how I've interpreted it).

If the emulator main loop instead was to start right before reading the input and run until right after a frame has been generated, we'd be able to read the input and generate the corresponding frame in the same call to the main loop, i.e. we'd shave off a whole frame of lag.

Here's a simple sketch I made:

I have already tested this theory by making a few crude changes to the main loop. It took less than 20 lines of code in cpuexec.c. Here is a link to the modified source code file:

http://pastebin.com/5TfgnzLG

Below are some test results with the new code (taken from this post: http://libretro.com/forums/showthread.php?t=5428&p=41376&viewfull=1#post41376):

The chart below compares the unmodified snes9x-next and bsnes-mercury-balanced cores (the first six bars) to the snes9x-next core with my fix. The test was made with an LED rigged controller and 240 FPS camera.

I also tested the new core using the frame advance method (i.e. pausing emulation, applying input and advancing frame-by-frame). Test result for the newly compiled core is to the right.

Please see this post for a detailed description of the test methodology: http://libretro.com/forums/showthread.php?t=5428&p=36549&viewfull=1#post36549

I have not found any issues with my changes yet. However, I don't have any previous experience with this code or emulators in general, so I can't vouch for it. That's where I hope some of the more experienced developers may chime in. If the changes make sense, I don't see why they shouldn't make it into the master branch. Wasting a whole frame for nothing seems, well, wasteful. I realize the code I wrote isn't the nicest looking, so please feel free to rewrite it into something more fit to be committed to the master.

The core seems to completely ignore PAR codes, even though Game Genie codes that affect the same addresses (even converted PAR=>GG codes) work perfectly. When tested in other emulators with the same ROM, (including regular snes9x) the PAR codes work perfectly. This means codes affecting RAM addresses cannot be made to work, limiting the scope of cheats/hacks dramatically.

Note that I am adding the codes properly, since codes converted to Game Genie using converters can be made to work in RetroArch, this is not user error (the cheat interface is in fact one of the easiest and more convenient to use I stumbled upon).

Seems to be a general issue with libretro and PAR codes, even when the used cores are supposed to accept PAR, but was advised to post here for starters.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Super Bomberman 3 keeps freezing for me after about 20 seconds (in Menu). This does not happen with other games as far as I can tell.

I'm using snes9x-next's latest git revision (self-compiled with gcc 4.9.2) on an ODROID-C1 running ArchLinuxARM with ALSA (no pulseaudio) and framebuffer (no X11).

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

http://www.youtube.com/watch?v=LtKZD-Ka4OU&feature=youtu.bevvv

After selecting two shaders in the settings menu, Selecting "Save Settings as Shader Preset" causes the PS3 to lock completely. Tested on the newest commit.

Tried building latest snes9x-next, and I'm starting to see very broken images in Alltp.
Eventually it crashes, and there's lots of dmesg errors popping up ...
Upstream snes9x works fine.

http://i.imgur.com/LoPkmhG.png

Is this reproducible? I'm using GCC 4.8. Tried building with -fno-strict-aliasing and -fno-strict-overflow as well.

Currently, it references an non-existent Makefile.libsnes, and obviously is named compile_libsnes.sh

It had been awhile since I used my jb ps3. Compiled this repo as of yesterday for ps3. It seems that for the games I listed the colors in certain parts go completely out of wack (fuzzy, trippy broken colors).

A good example is Aladdin. Everything in the game is perfect except on the title screen. As the screen fades in the game title is all messed up however everything else is fine on the title screen. In DKC only the tree's in the background are broken and only become broken during screen fades (like entering DK's house and exiting). In Bomberman 2 everything is perfect except when actually in a level.

It seems some part of the core you have rewritten is using a different pixel format perhaps?

Nestopia and Genesis Plus GX already have it as a core option, it would be nice to have it available in a SNES core too.

The "Return to Menu" option in the Quick Menu does not seem to function. Selecting it just returns you to the game.

as image shows
http://imgur.com/cqtKuIu

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Dave's not here, man.

Weird, trippy graphical smearing appears in these high-res (I'm assuming this is supposed to be underwater) levels. This shot comes straight from the game's attract mode; it's one of the gameplay demos.

My understanding is that these worked previously, but I only just fired this game up for the first time on RetroArch, so I can't confirm when this regression occurred.

Running on RetroArch Wii 1.0.0.2/SNES9x Next v1.52.4.

the game got stuck 1 time (after winning a fight before playing the victory melody) and some times I got catapultated into "black space" in one instance while changing location in 2 other locations while using the whip to cross a gap.I got a save state to reproduce this behaviour.
I'm not sure this is a snes9x-next bug it could be a secret of mana bug.I can't reproduce it right now on the original hardware.
https://docs.google.com/file/d/0BxYPbh3cUNCBdm11RGxpLXdqRVE/edit?usp=sharing

I'm getting quite a few compilation warnings and errors when compiling snes9x on OS X 10.6.8. The majority of problems seem to stem from the /apu directory. Here's a link to the compilation output: http://pastebin.com/ZJCY29JE

One thing that fixed the majority of issues was to apu/apu.cpp:185 to:

#include "bapu/snes/snes.hpp"

I'm not sure about the others. Adding the /apu/bapu directory to the project didn't seem to fix the missing file issues, but someone more knowledgeable than I should be able to figure out what's going on.

I'm carefully and thoroughly testing games with this core on Retropie latest version (RPi2). It went well so far except with the following obscur games:

• Chou Aniki Bakuretsu Rantouden (Japan): game doesn't launch. Go straight into black screen and stays there. Not working on Snes9x1.53 Windows either but apparently does work on Bsnes or Zsnes.
• Kishin Douji Zenki - Tenchi Meidou (Japan): game doesn't launch. Go straight into black screen and stays there. Not working on Snes9x1.53 Windows either.
• Deae Tonosama Appare Ichiban (Japan): this one does launch. However it goes on a very weird animated screen with an even weirder character and.. that's all. Pushing buttons does nothing. It does work with Snes9x1.53 on Win and doesn't display that weird screen on that emulator.
• JoJo no Kimyou na Bouken (Japan): this one does launch. However screen goes full with garbage character during intro. This very same game works on Snes9x1.53 Win.
• Sailor Moon: to be confirmed - graphic glitches. There's a screen with a spotlight moving around the screen and spotlight is "glitchy"/doesn't display properly.
• Marko's Magic Football: crash during intro / unplayable
• Madden 96: doesn't launch
• Mechwarrior 3050: doesn't launch
• Robocop vs Terminator: does launch but intense screen flickering during stage 1. Not sure it's an effect but it makes the game unplayable.
• Stellaview games don't work as mentioned here #35.
• Sufami Turbo chip games launch but can't pass the instruction screen. I believe this is due on how ST games are supposed to work. Some ST games: Gekisō Sentai Carranger: Zenkai! Racer Senshi, Crayon Shin Chan, Sailor Moon Stars Panic 2, Gegege No Kitarou, ...

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Hi Twinaphex.
I am unable to make the multiman version of Snes9x.
Here is the output of compile_ps3.sh make_multiman: http://pastebin.com/DNgjSbi3

Since the first Snes9x-next version, all box shaders are broken. I don't know what happens, the screen gets tiny and scaling doesn't work.

The only workaround is to use a normal shader on second slot and use the Resize feature to get properly scaled.

Wrong colors on Android, nightly from 2015-08-20:

Port the new SNES9x core with byuu's SMP core to see how much the speed hit affects the PS3.

Using the parameters "Aspect Ratio: 256:239 (1:1 PAR)" and "Integer Scale: ON" still display non-square pixels.
This is very noticable and looks very bad.

Here is a screenshot taken by RetroArch followed by a screenshot of how the game displays on my screen.

I'm using the latest git of this core as well as the latest git of RetroArch on ArchLinux x86_64.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Some games (eg 2020 Super Baseball) were crashing on the RPI2. This is solved by changing the optimisation level from -O3 to -O2 in Makefile.libretro

Compiling with make -f Makefile.libretro platform=armvneon

Unsure the cause and haven't debugged further - - tested on gcc 4.7.2 and gcc 4.8.3.

RetroPie/RetroPie-Setup#946

Independent of retroarch, gpu, os settings etc, apples-to-apples comparison to other cores for different systems, this core produces massive input lag.

Worth nothing: all SNES cores produce much higher input lag than other cores, including systems much newer such as psx and n64.

Racking my brain, what is unique about the SNES architecture, is it the custom Sony sound chip (SPC700)? Or possibly the poorly documented GPU?

Other anecdotal evidence - http://libretro.com/forums/showthread.php?t=3603

I have taken a slow motion video with iphone to demonstrate the issue. I am going to save you the trouble and tell you I have spent hours eliminating all possible causes of the lag, from the obvious to the not-so-obvious.

http://tinypic.com/player.php?v=eah4rc%3E&s=8#.Vg4S4_lVhBc

In any case, SNES gaming requires responsive input to be satisfying and accurate. Interested in any thoughts on this matter.

If you enter Narshe mines just at the game's beggining and win some battles, you can easily notice music gets broken: out of tempo, wrong samples being played. Eventually the music becomes totally cacophonic.
It's not a host slowdown problem, but an actual SPU emulation problem.
Snes9x core (non-next one) doesn't show this issue.
Tested on X86 and ARM. Happens in both architectures.

i test some starfox 2 beta version, but the emulator dont load the game... but snes9x of windows load ok

I'm getting segfaults immediately after boot with all the SA-1 games (eg. "Super Mario RPG - Legend of the Seven Stars (U) [!]").

Tested with "libretro-snes9x-next_1.52.4+r172ubuntu14.04.1_i386.deb"
Also tested not occurring with "libretro-snes9x_1.53+r3178ubuntu14.04.1_i386"

I have the input exit emulator setting set in the retroarch.cfg config file. However when I hit esc in the emulator nothing happens?

Thoughts? Ideas?

The script requires Bash and should have a hashbang of

#!/bin/bash

I've tried lastest nightly 2015-08-16 savestates were broken, also I tested v1.2.2 and they worked fine.

In Chrono Trigger, when the player rewinds in a battle, this visual glitch appears on the top half of the screen: http://a.pomf.se/evfxiq.mp4

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

I seem to remember this happening some time ago:

• Pass the highway level
• Beat chill penguin
• Lost and game over in spark Mandril's and I was dumped back to the highway level instead of the startup screen
• When those blue bugs hit me with 2 missiles after that happened (but not only one) I get dumped to the password stage and forced to restart the stage

Then I reproduced it, gameover anywhere caused this to happen

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Hi, using the version bundled with Retroarch 1.2.1 and the latest nightly for Wii, there is a significant amount of slowdown in certain games as opposed to 1.0.0.2, most notably the intro to Yoshi's Island runs at around 50fps where it used to be at 59-60.

With the latest code, if you try to save a state and immediately after try to load it, any game gives out buggy sound and freezes the core (RA doesn't crash).
I have a very old version of the core with 'Load state' working, i'm going to investigate about it, if i find the broken commit i'll report it here.

Is two player support broken or am I setting it up wrong? Turtles in Time and Bomberman 2 (so multitap) appear to not work at all for more than one player. It seems all controllers, even if they S9xReportButton to a different PAD ID always modify player 1. This is a Wii version, I think it has to do with the following piece of code in control.c:

#if GEKKO
    case S9xButtonJoypad:
        {
            uint16 r = cmd.commandunion.button.joypad;

            if (data1)
                joypad[data2] |= r;
            else
                joypad[data2] &= ~r;
        }
        return;
#endif

It seems input doesn't work at all without that snippet. If I enable that snippet then input works fine but I can't get multiplayer support to work.

I am unable to build the PS3 Libsnes version of snes9x.

$ make -f makefile.libsnes platform=ps3
ppu-lv2-gcc -I. -I.. -I../apu/ -DBLARGG_BIG_ENDIAN=1 -D__ppc__ -O3 -DHAVE_STRING
S_H -DHAVE_STDINT_H -DHAVE_INTTYPES_H -D__LIBSNES__ -DRIGHTSHIFT_IS_SAR -DINLINE
=inline -fomit-frame-pointer -std=gnu99 -Wall -W -Wno-unused-parameter -DNDEBUG=
1 -c -o src/apu.o src/apu.c
ppu-lv2-gcc -I. -I.. -I../apu/ -DBLARGG_BIG_ENDIAN=1 -D__ppc__ -O3 -DHAVE_STRING
S_H -DHAVE_STDINT_H -DHAVE_INTTYPES_H -D__LIBSNES__ -DRIGHTSHIFT_IS_SAR -DINLINE
=inline -fomit-frame-pointer -std=gnu99 -Wall -W -Wno-unused-parameter -DNDEBUG=
1 -c -o src/bsx.o src/bsx.c
ppu-lv2-gcc -I. -I.. -I../apu/ -DBLARGG_BIG_ENDIAN=1 -D__ppc__ -O3 -DHAVE_STRING
S_H -DHAVE_STDINT_H -DHAVE_INTTYPES_H -D__LIBSNES__ -DRIGHTSHIFT_IS_SAR -DINLINE
=inline -fomit-frame-pointer -std=gnu99 -Wall -W -Wno-unused-parameter -DNDEBUG=
1 -c -o src/c4emu.o src/c4emu.c
src/c4emu.c: In function 'S9xSetC4':
src/c4emu.c:1143: warning: signed and unsigned type in conditional expression
src/c4emu.c:1144: warning: signed and unsigned type in conditional expression
ppu-lv2-gcc -I. -I.. -I../apu/ -DBLARGG_BIG_ENDIAN=1 -D__ppc__ -O3 -DHAVE_STRING
S_H -DHAVE_STDINT_H -DHAVE_INTTYPES_H -D__LIBSNES__ -DRIGHTSHIFT_IS_SAR -DINLINE
=inline -fomit-frame-pointer -std=gnu99 -Wall -W -Wno-unused-parameter -DNDEBUG=
1 -c -o src/cheats.o src/cheats.c
ppu-lv2-gcc -I. -I.. -I../apu/ -DBLARGG_BIG_ENDIAN=1 -D__ppc__ -O3 -DHAVE_STRING
S_H -DHAVE_STDINT_H -DHAVE_INTTYPES_H -D__LIBSNES__ -DRIGHTSHIFT_IS_SAR -DINLINE
=inline -fomit-frame-pointer -std=gnu99 -Wall -W -Wno-unused-parameter -DNDEBUG=
1 -c -o src/controls.o src/controls.c
ppu-lv2-gcc -I. -I.. -I../apu/ -DBLARGG_BIG_ENDIAN=1 -D__ppc__ -O3 -DHAVE_STRING
S_H -DHAVE_STDINT_H -DHAVE_INTTYPES_H -D__LIBSNES__ -DRIGHTSHIFT_IS_SAR -DINLINE
=inline -fomit-frame-pointer -std=gnu99 -Wall -W -Wno-unused-parameter -DNDEBUG=
1 -c -o src/cpu.o src/cpu.c
ppu-lv2-gcc -I. -I.. -I../apu/ -DBLARGG_BIG_ENDIAN=1 -D__ppc__ -O3 -DHAVE_STRING
S_H -DHAVE_STDINT_H -DHAVE_INTTYPES_H -D__LIBSNES__ -DRIGHTSHIFT_IS_SAR -DINLINE
=inline -fomit-frame-pointer -std=gnu99 -Wall -W -Wno-unused-parameter -DNDEBUG=
1 -c -o src/cpuexec.o src/cpuexec.c
ppu-lv2-gcc -I. -I.. -I../apu/ -DBLARGG_BIG_ENDIAN=1 -D__ppc__ -O3 -DHAVE_STRING
S_H -DHAVE_STDINT_H -DHAVE_INTTYPES_H -D__LIBSNES__ -DRIGHTSHIFT_IS_SAR -DINLINE
=inline -fomit-frame-pointer -std=gnu99 -Wall -W -Wno-unused-parameter -DNDEBUG=
1 -c -o src/dsp.o src/dsp.c
ppu-lv2-gcc -I. -I.. -I../apu/ -DBLARGG_BIG_ENDIAN=1 -D__ppc__ -O3 -DHAVE_STRING
S_H -DHAVE_STDINT_H -DHAVE_INTTYPES_H -D__LIBSNES__ -DRIGHTSHIFT_IS_SAR -DINLINE
=inline -fomit-frame-pointer -std=gnu99 -Wall -W -Wno-unused-parameter -DNDEBUG=
1 -c -o src/fxemu.o src/fxemu.c
src/fxemu.c:4257: error: 'fx_asr' undeclared here (not in a function)
make: *** [src/fxemu.o] Error 1

ca392d1 is a performance regression. Yoshi's Island rotating island screen dropped from 59 FPS to 53 FPS.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

As the box presets are broken, I've tried making a normal preset (using a normal shader on second slot).

When I choose that preset, the shaders aren't applied correctly. The emulator applies no shader on screen (the screen appears to use stock.cg shader). On top of that, the aspect ratio is returned to 4:3, even if I resized before and custom resize was chosen.

There are massive sound problems when playing Super Bomberman 2: In most menu screens and in the actual game, you can only hear sound for ~1 second. Then it mutes competely for the rest of the match/screen.
I do not encounter these problems when playing Donkey Kong Country.

I'm using snes9x-next's latest git revision (self-compiled with gcc 4.9.2) on an ODROID-C1 running ArchLinuxARM with ALSA (no pulseaudio) and framebuffer (no X11).

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

I would like to compile this so i can try the multitap patch out, but i cant find any instructions on how to do so
*running 64bit xubuntu

The Satellaview is that weird satellite-streamed service that was available in Japan for the Super Famicom. While Snes9x (even old versions) are able to detect Satellaview games as somewhat distinct from standalone SNES games and run them, Snes9X-Next seems to be launching them as SNES ROMs and the emulator locks up/crashes/etc. depending on the platform immediately upon load.

Emulation of the Satellaview is kind of a hassle generally; some games require the Satellaview BIOS to be in a certain directory and make calls to special BIOS functions and such, but other games (particularly those ported from the SNES to the Satellaview) don't rely on the Satellaview's features to run at all, e.g. Kaizou Chounin Shubibinman Zero (Japan) (BS) and Special Tee Shot (Japan) (BS) and will happily run in emulators without any BIOS required.

Anyway, Snes9x-Next seems to be trying to launch these games as SNES ROMs and they can be made to work somewhat by tweaking the bytes where a standard SNES ROM's internal header is located. Specifically, adjusting the ROM size byte which Snes9x-Next expects at 7FD7 (LoROM) or FFD7 (HiROM) to match the game in question (the values represent powers of two, e.g. 09 means 2^09 = 512KB, 0A means 2^0A = 1024KB, etc.) will make the games run to the extent that they can on a stock SNES.

Lay user's guess: when Snes9x-Next encounters the unexpected ROM size byte (FF in both of the aforementioned games) it tries to allocate some insane amount of RAM (forty-nine septendecillion zottabytes?) and everything explodes. Short of supporting the games, a sanity check here would probably be good. Ideally, it'd be great to see Next support the Satellaview somewhere around mainline 1.51's capability. If this is not planned, though, then at the least *.bsx should be removed from the list of supported file extensions since they don't work at all currently (i.e. Snes9x-Next isn't a Satellaview emulator).

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

In the Wii version of Snes9x Next (latest nightly build) I'm having an issue where occasionally a dpad button will get virtually "stuck" and keeps pushing in that direction until another button is given. I haven't noticed it in other cores but I mainly use Snes9x so I may not have noticed it, but I can't make it happen in the retroarch menu either. A good way to see it is just to open a menu in a game and scroll around randomly, it will eventually get stuck. Alternatively you can walk around in any platformer and it will happen.

EDIT: Others have told me it only happens with the classic controller, which seems to indeed be the case. As the classic controller is one of the best ways to play SNES games the issue remains.