Half of cores not working

So, I have r12 and a JXD s7300. Half of the emulators I’ve tried (SNES, NES and Game Boy Advance) work extraordinarily well.

But most of the emulators don’t work at all. Medafen VB and Gambette only gives me audio, no sound, and the Turbografx and Playstation don’t even give me that.

Is there a workaround for this, or is the a bug that will hopefully be corrected for r13, or what? IS there an older version I can revert to?

‘But most of the emulators don’t work at all. Medafen VB and Gambette only gives me audio, no sound, and the Turbografx and Playstation don’t even give me that.’

‘only gives me audio, no sound,’

You probably mean video but no sound.

Anyway, what you’re describing to me sounds very weird to me - I think those other cores have been confirmed working by other JXD S7300 users so they should definitely work. You might not happen to be trying to load RetroArch from SD card, right? Because this could be causing problems.

Anyway, I’d ask what other JXD S7300 users are experiencing on this front - most of those cores should just work.

Yeah, Audio but no Video. That’s it.

I’m running it off the main memory, not the SD card.

I’ll check mine when I get a chance. What firmware you running SuperL?

I’m running NCCE 1.0 with no changes.

I’m having the same issue, it seems to be some sort of overlay issue with android. If I rotate the screen I see the image for a second and it disappears. Seems like something is overlaying the image. This happens on nestopia, mednafen PC engine and mednafen virtual boy that I’ve tested so far. I’m using sxelrom 2.0. I can submit a video if you would like to see, if I bring up a menu I can see the game behind it but once i clicked off the menu the image goes away.

Sounds like a firmware bug to me.

But do go ahead and post the video.

here is the video sample showing retro arch working in final burn and not working in mednafen virtual boy

Have the same issues on sxelrom 2.0 as well as NCCE 1.1, im going to try some older revs of retrocade to see if they work at all

From what you guys described to me - the only consistent pattern I can see here is that those cores that do not show the overlay (most Mednafen cores/Gambatte) are using 32bpp colors while the ones that do use 16bpp (FBA/SNES9x/VBA/whatever) do show the overlay.

We could research if there is an issue with cores that use 32 bit color and the overlay and try to fix that in time for the next release (0.9.9).

Quote from: SooBlazed on April 03, 2013, 12:13:58 AM Stock launcher doesnt work, crashs with process.android.media as soon as it loads

Also virtual boy, nestopia and turbo grafx 16 emulators in retroarch have video problems. ive escalated the issue to the guy who made retroarch he states its a firmware issue. The video is always in the background and not visible unless you rotate the screen. If i hold the power button and the shutdown screen pops up i can see the game behind it. Not sure what the issue is i have a video ill dig up the video and post it on here.

Response from one of the firmware devs

actually this is a lib issue cause of a shader filter used, im not sure if the stock libs worked on those 3 emus. Anyone on 1.7 can try? in any case were aware of it, hopefully there’s an alternate emu for those that works while a lib that works with those without breaking other games is found(you can thank mali for that, not releasing source)

Any news on this research? Cores using 32bpp colors work pefectly on Adreno GPU’s (Nexus 4 , Nexus7, …), but they don’t work on certain Tegra, PowerVR and Mali-400 devices… :frowning: Which is very unfortunate when you bought the device specifically to play retro games via RetroARch.

I have a Mali-400 device (Galaxy S2) and overlays work just fine here with 32bpp cores …

Overlays are also working here fine with all the cores on my Mali based Galaxy S2 and UG802.

well its not happening on all mali-400 devices but it does. I have an Ainol Novo 10 Hero. and I’m unable to play the 32bpp cores. I have two very crappy pictures I took with my phone. the first picture shows what it looks like when I load a game using nestopia. in the little retroarch icon for loading rgui you can see a bit of the game.

This second picture is what I see when i open rgui.

So this is a problem but probably something you guys can’t fix unless you get thoses cores working with 16bpp color or maybe you can fix it but I dont know. I’m going to be asking the guy that makes the custom roms for my devices to see if he his able to do anything about it since it seems more like a problem with crappy android drivers/builds from crappy companies.

Maybe the problem lies with the dpi density of the device? The JXD S7300B Mali-400 has a dpi of 160, while the Samsung S2 Mali-400 has a dpi of 240?

Installing a screenfilter app from the playstore “fixes” the problem…

actually figured out a better temp fix.

Use a shader. Something light like the scanlines shader fixes the problem.

I discovered this if it can be useful (JXD S7300):

On the buggy cores video is shown only if there’s a not fully transparent overlay on top of the libretroarch-activity. This explains why you can see the game for some instants when you overlay it with volume adjustment or other dialogs.

And, if the dialog, like vol adjust, has transparent background you only see the area where there was the volume spinner for some instants, but if the dialog also enables a semi-transparent background, you can see the whole emulator screen.

This happens only with stock shaders. So you set it to scanline and bug is “fixed”. But I’m running retroarch programmatically from another app and even if there’s scanline.shader specified as shader filter in retroarch.cfg stock shaders keep being loaded.

I made a video http://youtu.be/PPBMQBAnkhM

Only the usual cores seem to be affected, vba runs great

I forgot to update my last reply to this thread.

This issue should now be fixed (at least it is for sure for me). I mentioned this to Themaister on IRC about a day after I made my reply in this thread and he had me try out a few different things. He figured out the problem and fixed it.

So this should no longer be an issue when the next version of RetroArch is released on android. If you can’t/don’t want to wait you can always just build retroarch and the cores yourself.