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?
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.
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.
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.
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.
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
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.
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.
It does, and I adore GensPlusGX’s BIOS usage in general. I’m not aware of any other genesis core that allow you to use the TMSS for Genesis (an essential part of the experience IMO - and the #1 reason I wish Gens had 32X support, since PicoDrive makes 0 use of it.)
The problem with Gens though is there’s no way to crop the awful bar on the left of all the games. SMS Plus GX crops it though. From what I can tell these 2 cores are the only ones that utilize the SMS BIOS. Given that SMS games run on SMS Plus GX without the BIOS I thought for sure it would present the boot screen once you fed it the BIOS.
Hello guys! Are you aware that the core Duckstation is no longer supported by the developer? On GitHub he explains that you can use CMake to build the core on windows and Linux with the recent features.
Well I don’t know how to use CMake, I’m sad because I opened a request for Stenzek to implement “downsample to native res”. He answered, and the downsample is available in the last update. I tested it on the Duckstation standalone, and it’s great! Also because this emulator is very fast, but it would be better to use it with the RetroArch shaders, like nedi or scalefx-raa with the downsaple enabled.
If anyone knows how to build the core on CMake, could you please share?