@SinisterSpatula That's great indeed and I'm glad I could help. I can't wait to see the next iteration you produce. The advanced mapping method with case statement really works well if you have a lot of code. My arcade machine's runcommand-onstart.sh has about 4,300 lines of code for 4 arcade joysticks, a PS4 wireless controller and an 8BitDo Zero covering about 60 systems. I also use it for all of the libretro cores too now. It doesn't miss a beat, so I reckon you're going down the right path. Going back to my GPi vice code, with a bit more testing I'm finding that it's definitely not working for every game, so I reckon your newly produced code will be more successful than mine in "universalising" the controls for the c64. Please feel free to experiment with my code of course and make any changes you think are best.

if anyone is interested, I noticed that using time channels, many games work properly (eg Satella walker or Mario Excitebike). I am attaching my latest data, where I have enabled building animations, time channels and other things :) https://drive.google.com/open?id=15kiReJJv6_OOUEZUnGOlVyVbM5DwWv67

I just wanted to say...I love Lufia 2!

Hmm. Now I'm wondering where the setting is for bilinear filtering is located at. EDIT: Found it. Everything is now good. Thank you for the help.

@mediamogul said in How to use multiple emulators with same system: It could just be an issue with your timing in activating the Runcommand menu. Once images are added, the timing changes a bit. The menu can't be accessed while an image is up, but it can be within a few seconds after the image disappears. It's a known issue and mentioned in the docs. Ahh! That's exactly it! Thanks!!!!

The RetroPie-setup script updated today and now I can't update lr-snes9x from source with the PGO changes. Anyone else having this issue? EDIT: Found the problem. So it seems like there's a limit to how many games you can profile, otherwise it will crap out during compiling the optimized core. I probably profiled 15-20 games, so I think it's better off to just go with 5-10.

Just a last report. So, I have installed my new case and the temperature difference is like day and night, dropping around 30° Celcius (from 80° to 50°, but just a small test, it will heat up a little more, but you get the idea)! Its one huge heatsink (whole case is one big heatsink) and no extra boards installed. I am just happy, plus the right emulator and no over heating issues and no fan noise! Still not really well tested, but I can see clearly the benefit. Just someone is interested in it too, its very inexpensive also. My new case is: BIQU Aluminium Raspberry Pi Modell B for 11 Euros in Germany.

@fabio78 Yep, I was just doing it earlier with the lb-snes9x core. It starts out at the default 10 but wasn't the original hardware slightly faster? Anyway, it bumps up by units of 10 after that. 20 worked really nicely. Overclocking the Pi itself seems optional, but it would get you back to a perfect 60fps or close to it.

@fernandoj8 How is this related to RetroPie ?

@dlawrence529 A name is just a name, nothing more. Glad you got it sorted out.

Report the issue here: https://github.com/libretro/snes9x2010

Lr-snes9x is more accurate and uses more resources than lr-snes9x2010. The pi may not be able to keep up with a more accurate emulator. The popping is just the emulation pausing for a split second waiting for the cpu to keep up. To our ears is sounds like a crackle. So even if it’s delaying a frame or 2 which may not be notable to our eyes, our ears can hear the delay. Stay with snes9x2010 as it runs most games fine.

With the official release of Snes9x v1.55 a week ago, the first official release of Snes9x to support MSU, the lr-snes9x emulator core for RetroPie has also been updated. I'd strongly suggest everyone update (from source) their lr-snes9x on their RetroPie setup. The new version has fixes for a few MSU related issues, the biggest one I'm aware of is a fix on a bit of code that actually lets music resume properly (so after a battle when you show up on the worldmap, the music will continue where it left off, rather than starting over, as one example). It actually supported it before but wasn't reading the settings properly, so resume didn't work.

I made the problem known on the official github but the person can't reproduce the problem, and told me to try one already built from libretro. In trying it out, i get the error relocation error: /opt/retropie/libretrocores/lr-snes9x/snes9x_libretro.so: symbol _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEjjPKcj, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference Might this be a reference to not having the latest gcc?

@Darksavior actually snes9x2005 is not rendering jurassic park right. SNES9x2010 is actually doing it right. That game uses a kind of a fake high res mode that renders a 640x240 image, but the snes sends out a 320x240 image. So on a CRT TV, every other line blurs together making a kind of a fake transparency. It was a trick used in a couple of game including kirbys dream land 3. The problem is that emulators don't output down to 320x240, and show the full 640x240 image with every other line as a vertical line where there is supposed to be a fake transparency. There is a shader that does the blend, but makes the games look blurry during the 320x240 parts (kirby changes back and forth based on the level) and is slow on a Pi. Snes9x 2005 just ignores it all together and just shows a 320x240 image with no transparency. Bsnes on the other hand (not on the Pi) can detect it and add the blend when needed.

@meleu I've never tried it.

Capeman : thanks for clearing that up, I didn't know that this was how it has always worked. dankcushions : I found the undo load state option but only after resetting and noticing the problem. It was obviously too late... well, now I know.