Scorr
MGBA Core not working?
Hi,
its said that the mgba core works, but it doesnt?
Any hint for what needs to be looked into, to make it work? (also other cores?)
mgba did not work for me either. I am able to load gba roms with vbam_libretro.dll. The screen flickers though. Snes9x works perfect.
I am mostly interested in getting mame arcade emulation working for my project. Unfortunately I am not able to correctly load a rom because bool ret = Libretro.RetroLoadGame(ref gameInfo); returns false. The rom path is correct so I must be missing something in the environment setup.
As a test to load another core I was able to load stella for atari2600 emulation. The game works, but I need to adapt the framebuffer to output to the screen correctly.
Have you tried to get more cores working?
@ptrvg got snes,gba,nes and gb/gbc working. Im currently debugging whats wrong with the mupen core in unity. Seems like Unity crashes when mupen uses libco to start a coroutine. Right now, im writing an workaround for it.
Can have a look at Mame Arcade Emulation at the weekend if it helps you
EDIT: Sorry for my bad english
@JustMeDaFaq I would love it if you could get Mame working. My Unity project is a port of my 3darcade emulator frontend to Unity that I started two weeks ago. So yeah Mame is the one I am after! See: 3darcade Unity , old one 3darcade
There are a few Mame cores. For performance reasons I would like to use mame2000. or mame2003. But any will do. I only succeeded to load a game with the default mame.libretro.dll core. But then it crashes on the first update call.
@JustMeDaFaq I would love it if you could get Mame working. My Unity project is a port of my 3darcade emulator frontend to Unity that I started two weeks ago. So yeah Mame is the one I am after! See: 3darcade Unity , old one 3darcade
@ptrvg Seems my idea for mupen64 core worked out well. At least, it boots the game. Need to test if its stable tho, time for Super Mario 64 ;)
Looks awesome your project, so Mame will be next! :)
@JustMeDaFaq Damn you work fast...have fun with Mario!
@ptrvg
Worked the last two days on it, didnt wrote c code for a long time, so it took me a bit to get back into it ;D
Had a quick look at the Mame2003 core. Main issue seems to be also related to the libco library. But the workaround applied to mupen should work for the Mame2003 one too, i guess. And a minor Environment stuff. Hope that i get to work on Mame on Thursday, shouldnt take too long.
@JustMeDaFaq Big thanks for doing this! C# and in fact any c language are completely new to me. So figuring out the libretro.h implementation in LibretroWrapper.cs was and is a bit of a challenge for me ;)
hey sorry bout that, I just checked and mgba doesn't work for me either. like ptrvg said, vbam_libretro does work if you need gba. I just pushed a potential fix for the flickering, let me know if it still happens.
I'd like to make this repo compatible with any libretro core but I haven't gotten to looking into it because I never got sound working properly on the cores that do load. that's been the main blocker and that's why this repo hasn't been updated much.
hey sorry bout that, I just checked and mgba doesn't work for me either. like ptrvg said, vbam_libretro does work if you need gba. I just pushed a potential fix for the flickering, let me know if it still happens.
I'd like to make this repo compatible with any libretro core but I haven't gotten to looking into it because I never got sound working properly on the cores that do load. that's been the main blocker and that's why this repo hasn't been updated much.
@Scorr Hi. I tested the new version a bit an for me it still has the flickering with vbam.
Yes it would be great if the repro could support more cores. From what I have read so far getting sound working properly is very difficult with libretro. Unfortunately I dont have the technical skills to be much of a help beside from testing.
@ptrvg @Scorr Which game did you try? 32 or 64bit version of the core? Tried pokemon firered, video isnt flickering for me.
@Scorr @JustMeDaFaq I tried super monkyball jr and Herg's Solitaire. That was with an older 32 bit core.
I now tried the latest cores directly downloaded from retroarch: vbam_libretro.dll crashes Unity for me with both games vba_next_libretro.dll works ok on both the old and new version of the repro with no flicker. All cores are 64bit.
So yeah my fault, I should have done more testing before reporting the flicker issue.
@ptrvg Got Mame2003 core working yesterday. Worke fawlessly on android, a bit buggy on windows tho. Il look at it tommorow! :)
@JustMeDaFaq Damn that is great news! Looking forwards seeing it in action. I will only be able to test the windows version. I have no android devices.
@ptrvg Had no luck getting it to work reliable. It randomly fails. Seems that nothing is missing but that its related to how unitys native function calling works. Have no idea if theres an solution for it.
Im thinking about to switch to unreal engine
@JustMeDaFaq Thanks a lot for trying. You have come much further than I did. Are you willing to share what you have got so far? I still like to see it.
New retro arcade neon uses libretro with the unreal engine. So yes it has been done before, so that should work for you. I don't know much about the unreal engine besides that it uses c++. That is a bit scary compared to Unity's c#. The only modern language I know well is Swift...
I don't know what the issue could be but I don't think switching engine would be the solution (though maybe it randomly fixes the real issue whatever it is).
Unity does not do anything special for native function calling, and C# native function calling is generally pretty robust.
@ptrvg probably got it working more reliable. Il clean it up and give it to you when im back home later. You should test reliability tho
@Scorr From the information i gathered, theres definetly something in unitys mono runtime/jit compilation... i could be wrong tho. Il be glad if you could prove me wrong, have a look at the vbam core :)
Thanks, take your time! Of course, I'll test it inside my app. And if it goes well I'll send it to a few more people to test.
@JustMeDaFaq Hi. Have you made any further progress with mame support? I am still very interested in testing what you have so far!
@ptrvg sorry for not getting back to you! Just completetly forgot about IT, after figuring out whats the reason some cores dont work. Trying to get around it, tho, need to learn more about the stuff needed, not experienced enough. Probably takes a few weeks.
Tho, il make sure youre getting the mame one asap. Should work without problems (beside the controls, i was too lazy to include all Buttons, but that shouldnt bee too hard :) )
@JustMeDaFaq Dont worry, I forget things all the time ;) Yeah I already added better controller support and retro_unload_game to the wrapper. I also will closely look at the changes you made to learn more how this stuff actually works!
How did you guys get the mupen64 core working? I seem to get a crash after it polls all the system variables, all the way up to pak4, and then it just crashes the editor. I've got Snes9x, quicknes, and mGBA working well, with stable sound for each, minus some crackling.
@JustMeDaFaq @ptrvg are either of you around to explain why the mupen64 core wasn't working and what you did to get it to work?
@Hokage3211 Basically, the hardware render callback isnt implemented. See the environment function for that, it asks on those cores for RETRO_ENVIRONMENT_SET_HW_RENDER, when that is asked for in the environemnt callback, "data" is a struct of type retro_hw_render_callback, where you need to apply the proper things (added an example of such a function below, but written in c++)
Also, the threat youre running it in must have a opengl context for obvious reasons.
We are trying to implement the hr_render using GLFW here https://github.com/Skurdt/LibretroUnityFE/issues/5 Contributions are welcome ;) and basically all changes could be used here either.
@JustMeDaFaq Awesome, that makes sense so far, where and what are those get_current_framebuffers and get_proc_address implemented? Like how do I use what this callback gives me, or how do I set up the stuff to give the callback? This is what I got for my implementation of the hw callback stuff
@Hokage3211
get_current_framebuffer -> Libretro uses it to get the pointer to the framebuffer you want to render to. That framebuffer has to be generated by yourself. See https://docs.gl/gl3/glGenFramebuffers (need a GL/GLES library for that) . A example for the "callback_get_current_framebuffer" callback is attached :)
get_proc_address->Helps libretro to make use of the actual opengl api. For egl thats like https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglGetProcAddress.xhtml , its almost completely similiar tho. That should be part of the OpenGL/GLES library of your choice :)
U dont realy use anything from that callback, but since it tells the Libretro Core which framebuffer it should render too, you can do all further things, whatever you want, with the rendered frame on the framebuffer you generated :)
Hm.. okay.. based on all this stuff including their examples it feels like I'm not gonna be able to contribute much if this isn't working to display to the in-unity screen stuff, I can't make heads or tails of the examples if they aren't already working to display on the in-unity screen. Unless I'm missing something on how to funnel the rendered stuff to the texture data?