I am making the FreePlay Zero GBA kit with the RPi Zero WH and I want to emulate GBA games (why is everybody like “I want to emulate SNES games on a GBA” or “I want to emulate N64 games on a GBA” or something like that.) I am using Lakka as my OS, because I have had good experience with Lakka and RetroArch in the past. My favorite GBA emulator has always been VBA-M (despite what all the hardcore mGBA people say.) Before this I had run Lakka on my old RPi 2 and it had the VBA-M core, but for whatever reason, there is no VBA-M core on the RPi Zero version of Lakka. I don’t know if I have a bad image or if you didn’t include VBA-M with the RPi Zero image, but please add it.
I would love to see a Libretro core for OpenMSX! Or, at least an update for the BlueMSX core as it feels really undercooked and hasn’t been touched in ages
Love to see a way of using the Transfer Pack for N64 Games Espically Pokemon Stadium Games.
Anyone looking of putting Link Cable in GBA Cores so can use the Link Cable for GBA Games?
I have a really cool idea which is currently only possible in retroarch.
The start point was to think about the game Yoshi Topsy-Turvy and wario ware twisted. If you play those games currently the display stays static although the tilt sensor simulates that you rotate the screen (trees are shifting, etc).
So I thought to create a shader to rotate the display depending on the sensor input. However there is one major issue, you cannot read data from libretro and feed a shader with that input. But this is the general idea.
Would it be possible to read data from libretro like input data or also cheats data as an source for shaders to manipulate shaders?
libretro provides already some kind of manipulation with rumble. https://docs.libretro.com/guides/cheat-codes/ I thought to extend that kind of feature and apply it to shaders.
For instance if the players character got damage, not only the controller will rumble but a distortion shader will be applied for 0.5 secs.
Another example would be the GBA games I mentioned. If the user emulates the tilt feature, libretro shall read the input of the controllers and the shader shall rotate the display according to the input degree.
A third idea which came into my mind is to have some kind of blur feature. For instance if you got a star in super mario bros, a blur shader will be applied.
That feature would be pretty unique for retroarch and libretro. And i only see the possibilities with libretro.
2 Likes
Yeah, would be very cool. There are lots of possibilities, it’s just a matter of hooking the shader backends to the other parts (input, memory pokes, etc.). It’s outside of my range, but it’s in the realm of possibility.
1 Like
I’d like to see save core options per directory. We have few cores that can emulate different systems. E.g. atari800 core can emulate A5200 console as well as whole family of 8-bit computers. Since 5200 is very different than A8 computers, most of folks using this core would have separate folder for each of the systems. Currently, emulated atari machine is saved in retroarch-core-options.cfg. If last played game for atari800 core was for 5200 then loading game for A8 requires user to go to core options, change emulated machine and restart the core/game. I don’t know if this is the issue for other 8-bit computer emulator cores (namely Amstrad, Commodore, Sinclair) but it would be really nice to be able to save those settings for each directory individually and not to worry about switching emulated machine each time different game is loaded.
2 Likes
Think your idea is a good one, hopefully someone at RA control have the know-how to do this.
Another Idea would be split the cores into seperate cores for each system they emulate. IE you end up with atari800-XL, atari800-5200 and such, would be easier methinks, but not sure how @hunterk and others will feel about it
I think this would be a pain for developers to maintain two cores (even if those are virtually same). I’ve copied and renamed atari800 core to atari5200 and generated playlist for 5200 and linked games to the new core. Trouble with this is, that selecting Atari 5200 as a mchine when new atari5200 core is launched overwrites following lines in the retroarch-core-options.cfg:
atari800_artifacting = “disabled” atari800_cassboot = “disabled” atari800_internalbasic = “disabled” atari800_keyboard = “poll” atari800_ntscpal = “NTSC” atari800_opt1 = “disabled” atari800_opt2 = “disabled” atari800_resolution = “336x240” atari800_sioaccel = “disabled” atari800_system = “800XL (64K)”
And those lines are also used by original atari800 core. As you can see last entry is selected, emulated Atari machine model (in this case atari800_system = “800XL (64K)”). I’ve seen post on this forum (from few years back), where some did same thing as I, but hacked renamed core with the hex editor, essentially replacing all atari800 references with new entries. Nice workaround, however it would have to be done each time core is updated.
renaming the core won’t help. You need to change the code, as the core name is hardcoded. I self-compile a few cores like that.
1 Like
There’s a batch script to split the core and rename it …search for split cores…use the batch on the pc to split pc or android cores
How hard would it be to port the frodo (C64) core to Wii? It exists on PSP, Wii doesn’t have a core for C64.
hello, would you like to suggest the following: Emulation profiles for N64. Here’s an example using Francisco Zurita’s version of mupen64plus.
-
[Glide64-Accurate]
-
comment=glide64 video with recommended settings for quality
-
r4300Emulator=2
-
videoPlugin=libmupen64plus-video-glide64mk2.so
-
glide64Frameskip=0
-
[Glide64-Fast]
-
comment=glide64 video with recommended settings for speed
-
r4300Emulator=2
-
videoPlugin=libmupen64plus-video-glide64mk2.so
-
glide64Frameskip=-5
-
[GlideN64-GLES-2.0]
-
comment=gliden64 video with recommended settings for most older devices and support for hires texture packs.
-
r4300Emulator=2
-
videoPlugin=libmupen64plus-video-gliden64%1$s.so
-
videoSubPlugin=-gles20
-
EnableCopyDepthToRDRAM=2
-
txHiresEnable=True
-
txSaveCache=True
-
[GlideN64-GLES-3.0]
-
comment=gliden64 video with recommended settings for Android 4.3+ devices with OpenGL ES 3.0 support and support for hires texture packs.
-
r4300Emulator=2
-
videoPlugin=libmupen64plus-video-gliden64%1$s.so
-
videoSubPlugin=-gles30
-
MultiSampling=0
-
EnableCopyDepthToRDRAM=2
-
txHiresEnable=True
-
txSaveCache=True
-
[GlideN64-GLES-3.1]
-
comment=gliden64 video with recommended settings for Android 5.0+ devices with OpenGL ES 3.1 support and support for hires texture packs.
-
r4300Emulator=2
-
videoPlugin=libmupen64plus-video-gliden64%1$s.so
-
videoSubPlugin=-gles31
-
r4300Emulator=2
-
txHiresEnable=True
-
EnableLegacyBlending=False
-
EnableHWLighting=True
-
UseNativeResolutionFactor=2
-
EnableFragmentDepthWrite=True
-
[GlideN64-Full-OpenGL]
-
comment=gliden64 video with recommended settings for Android 5.0+ devices with Full OpenGL support
-
videoPlugin=libmupen64plus-video-gliden64%1$s.so
-
videoSubPlugin=-egl
-
MaxAnisotropy=8
-
r4300Emulator=2
-
txHiresEnable=True
-
EnableLegacyBlending=False
-
EnableHWLighting=True
-
UseNativeResolutionFactor=3
-
EnableCopyColorToRDRAM=2
-
MultiSampling=4
-
EnableFragmentDepthWrite=True
-
[Gln64-Accurate]
-
comment=gln64 video with recommended settings for quality
-
r4300Emulator=2
-
videoPlugin=libmupen64plus-video-gln64.so
-
gln64Frameskip=0
-
gln64Fog=0
-
gln64Sai=0
-
gln64ScreenClear=True
-
gln64AlphaTest=1
-
gln64HackDepth=0
-
[Gln64-Fast]
-
comment=gln64 video with recommended settings for speed
-
r4300Emulator=2
-
videoPlugin=libmupen64plus-video-gln64.so
-
gln64Frameskip=-5
-
gln64Fog=0
-
gln64Sai=0
-
gln64ScreenClear=True
-
gln64AlphaTest=1
-
gln64HackDepth=0
-
[Rice-Accurate]
-
comment=rice video with recommended settings for quality
-
r4300Emulator=2
-
videoPlugin=libmupen64plus-video-rice.so
-
riceAutoFrameskip=False
-
riceFog=True
-
riceFastTexture=False
-
riceScreenUpdate=4
-
riceForceTextureFilter=False
-
riceTextureEnhancement=0
-
riceHiResTextures=True
-
[Rice-Fast]
-
comment=rice video with recommended settings for speed
-
r4300Emulator=2
-
videoPlugin=libmupen64plus-video-rice.so
-
riceAutoFrameskip=True
-
riceFog=True
-
riceFastTexture=False
-
riceScreenUpdate=4
-
riceForceTextureFilter=False
-
riceTextureEnhancement=0
-
riceHiResTextures=True
Hopefully it’s possible, so you decide between performance or speed. Thank you!
Most Naomi/Atomiswave games won’t run with the Flycast core that’s preinstalled on the Pi4 using Lakka, but run on my PC Retroarch fine.
Is there anyway to get the latest Flycast core updated on Pi4 Lakka?
A Windows95 Core Based on PCem or DosBox a dedicated Win95 emulator which runs Win95 games. A Win95 VM is mostly too much. you do not need the whole OS to play games like NFS.
An Android/IOS Core Looking onto the policies from google and apple several games were already removed from the stores. A Core with a dedicated android or ios version to play those games would be nice
3 Likes
Nintendulator is indeed a great emu, but it’s very Windows-centric and depends on WINE for cross-platform compatibility. This doesn’t bode well for libretro-ization, unfortunately.
1 Like
Uhm… If there’s alreadies a way to do this that we misseds, we’s sorry (also if Rei’s way of talkings is a problems, can tries to wait ‘til Nezumi can fronts), but… we would likes a way to activates Dual Shock vibration buts disable Analog controls. There’s a few games that supports vibration buts nots analog, of which the one I’s most interesteds in is R-Types. (We was actuallies going to creates a new topic discussings issues we’s had wif its an’ Delta, but couldn’t find a way to creates a new topic)
Never minds! We founds out how to gets that part to works wif Duckstation core. (Still no idea on PCSX ReARMed, but that one has weirds graphical issues on the opening FMVs for us, so…)
SMS Plus GX allows you to feed it a SMS BIOS - however it does not load the BIOS screen before loading the game 
The SMS bios displays at the start of booting a game if you use genesisplusGX, but you have to enable it in the core options first.