Not a bug at all and in fact exactly as intended.
What you see there is simply the difference in quality between the SNES’ low-res 256x224 resolution vs. its high-res interlaced 512x224 resolution.
Hunh. Well, thank you for the clarification.
There are still some minor issues with libretro-mednafen I’ve mentioned on Git: Problems with the core volume options for PCECD Blood Omen speed issue
Also, in the current official compile of the Genesis Plus GX core (2013-05-19) Lunar the Silver Star freezes before the title screen, but ekeeke fixed that recently, so the next time cores are compiled that will be fixed for everyone 
Retroarch Wii
I’ve noticed some weird garbled pixels starting to show up in Seiken Densetsu 3 on the righthand side on the screen. They originally cropped up with a bad rom in the menu screen, but after replacing with a clean rom they disappeared. I played for ~3 hours (without restarting or resetting). When I started it up today, the garbled pixels reappeared whenever I enter the hires menu screen. I’m playing with standard configs.
Edit: Played a couple more hours, restarted Retroarch, and now the line of garbled pixels is now on the lower right hand side (it was on the upper right hand side). The pixels are appearing outside of the 4:3 screen but smack against it. It almost seems as if the location of the pixels is related to the save data because the only thing that seems to change is how long I’ve been playing the game.
Win64 Nestopia 640x480 60 refresh rate
Crop overscan doesn’t seem to work. I got it work once, and I have no idea how. Since then it doesn’t work. This is most noticeable in SMB3.
EDIT: Can RA not boot from .zip very well?
I have been unable to launch multiple ROMs on the Wii version, such as Sonic 2 & Knuckles, Sonic 3 & Knuckles, and DKC (Rev B). Previously I had the ancient 0.7.2 version installed, but managed to hunt down 0.9.9 on Google. Is there a specific way to uninstall and reinstall RetroArch (As in, could I have messed something up if I didn’t follow the right method)? Does RetroArch simply have issues with certain types of ROMs (Rev versions, Sonic # & Knuckles ROMs, etc.)? I will try out Super Metroid: Redesign and a couple of randomized Pokémon ROMs to see if it is all special ROMs and report back. Also, upon quitting RA, I have to pull the power cord because my system freezes. I have RA on my SD card and all of my ROMs on a USB, if that makes a difference.
Can someone confirm this for me? When I upgraded my snes9x core from snes9x_libretro_x86_64_20130519 to snes9x_libretro_x86_64_20130629, I noticed an increase in input lag. Am I just crazy? I kept the old core and it doesn’t seem to have the issue. I swear the newer core has more input lag somehow. I’m using the Windows 0.9.9 x86_64 Full version of RetroArch if that makes a difference
@diggly I’m going to guess placebo effect, since there haven’t been any commits between those builds that could cause any sort of input delays:
Having an issue with running a specific game Guardian’s Crusade (u) in mednafen psx core. The game itself works fine but the input is not working and therefore the game is unplayable. Works in regular mednafen emu. Tried other playstation games where the input worked fine. This is the only one that does not.
What’s wrong with the input? Are none of the buttons responding?
Which platform are you on? Windows?
Many input issues have been fixed over time. Is your core newly compiled?
nothing seems to be responding I have my d-pad setup for fast-forward slow-motion and fullscreen toggle
oddly those work just fine
I am on windows 7 64-bit i got the mednafen core straight from retroarch-pheonix gui updater
edit fixed it I guess there is a new mednafen core that solved the problem. However now I have another issue. I am using blargs ntsc svideo x64 filter and it is messing with the screen proportions really bad in mednafen psx. Same system win 64 bit. Filter looks amazing and I hope there is a fix for this. Thank you.
Using Android retroarch version 0.9.9.3 r17, and core PCSX ReARMed r19 The Sony Dualshock 3 controller is no longer working correctly. The Cross, Square, Circle and Triangle buttons are not mapped correctly. I found a note in the Ouya thread that actually showed different key values than what I see, I posted the values I get from enabling debugging over there (http://forum.themaister.net/viewtopic.php?pid=5806#p5806) and suggested (meant to ask) if possibly a change for Ouya broke it on standard Android, because this used to work flawlessly.
This custom mapping is working correctly:
A Button using Button Y B Button using Button X X Button using Button B Y Button using Button A
All other buttons work mapped as normal (e.g. Right Button using DPAD RIGHT)
Another problem is that when using the custom bindings the Right and Left Buttons have a 1 second lag before the input is recognized. The lag was not there when using Auto detect with this version, but the button mappings were wrong.
I see in another thread (http://forum.themaister.net/viewtopic.php?pid=5832#p5832) that there is an acknowledged problem with the dualshock 3 face buttons with a fix in the works for the next release.
Is there an objective way of measuring input lag?
Also, you could simply try blinded placebo controlled tests if there isn’t. Try to have someone switch the cores at random (coin flips or dice perhaps to choose), without you knowing. Switch between all the snes cores, not just those two versions. Have them record which instance was which core, and you record how much apparent input lag there is. Ensure it’s blinded. Don’t tell them what your testing, or which ones have apparent input lag. Yes, this is basically silly nonsense, but it would be fun.
The best way to test that sort of thing is by having a “robot” press buttons on two controllers simultaneously, one connected to a computer running one core and the other connected to a computer running the other core. That’s still not exactly perfect, but probably the best you’re going to get.
Anything that involves human judgment, even if it’s double-blinded, is suspect in this sort of should-be-objectively-measured case.
Retroarch Android :
When using two usb gamepads at the same time the input freezes and after some time the emulation quits.
I was looking at logcat, and it logs this multiple times just before the emulation quits:
I/InputDispatcher( 285): Dropping event because there is no touched window.
I’m using a mini PC (MK802 IIIS) plugged to an HDMI with two arcade gamepads that are detected as USB Gamepad on retroarch. I tried a psx clone gamepad too, that is detected as DragonRise, it gives me the same error.
I don’t know if it has something related to the bug, but the device doesn’t have a touch screen.
Contact me if you need more testing or info.
Thanks
@markezine I believe it’s this same race condition input issue: http://forum.themaister.net/viewtopic.php?pid=6117#p6117
@hunterk yes, that’s it. I was watching that thread but didn’t have the debug info yet. I tried a snes emulator app in the same scenario (I could find only one free emulator besides retroarch that could handle more than 1 gamepad) and it didn’t freeze (Is it worth mentioning what emulator was?). I’m sorry, english is not my first language, but what’s a race condition ?
If I can help in some way, I’m not an expert developer like you guys, but I can debug and install prototypes on my device if you want to.
EDIT: Sorry, didn’t saw the Squarepusher’s reply on the other thread… So it’s impossible to fix ? Should I try it with some other custom firmware or something like that ? could it be a USB hub fault or something like that?
I don’t know if this has been reported yet, but the Gamecube controls for PrBoom are completely broken.
I don’t know if this just me but just in case, for people with an nVidia card.
I’ve been experiencing a appcrash involving nvoglv64.dll in OpenGL for a while now (Win7/Win8) and found a workaround.
Here is what usually happened: *Launch RetroArch *Apply Shader Preset (eg: mdapt.cgp from common-shaders\dithering repo) *Crash!
The crash would also happen when switching shaders.
The workaround: *Before applying shaders, set “Shader Passes” to 0 *Apply Shader Changes *Load Shader *Apply Shader Changes *It Works!
Sometimes it looks like loading the rom first helps. Loading a “safe” shader before the tricky one too. I have no idea who/what is to blame (rgui.cgp parsing? nVidia driver? shader code?) but the workaround is simple enough!