Doesn’t seem to be much work on this core. It’s the one I’m most excited for. I had a saturn as a kid.
The current libretro version is based on an outdated version - the best idea would be to rebase it on the latest version (I believe the original author has a Github repo of it?).
Anyway, I’d be happy to push the libretro port upstream - do note though that any and all core improvements will have to come from the main Yabause author himself since I know next to nothing about Saturn programming.
I didn’t have a Saturn at all, but I would be very interested in trying out an updated core. The current one is hilariously broken with some games. NiGHTS seems to work rather well, though.
I can’t say that I found Nights to be working that well, but Albert Odyssey certainly did for the small amount of time I tested it. Voices and everything.
This is probably the repo: https://github.com/Guillaumito/yabause
Now that this is based on the latest git code and works on Windows, I find it works quite well for a decent amount of games. I’ve had playable performance from: Albert Odyssey, Dragon Force, Cotton Boomerang, Guardian Heroes, the Panzer Dragoon games, Radiant Silvergun, Saturn Bomberman, Shining Wisdom and Shinobi Legions.
There are a few features missing from the libretro port I’d like to note here though. They are all things that work in the stand alone Windows version. Normally I’d add them as issue reports on git, but there isn’t an issues page for the libretro fork of Yabause.
Save ram (internal or cartridge) support isn’t working. Save states don’t work either. Also, it doesn’t look like there’s any way to enable the 3D analog controller yet in the libretro version.
Hopefully these features won’t be too hard to get working. I’d mainly just like to be able to save
May as well add that there is an issue with scaling as well, where every game is stretched to a height of 240 pixels, when this is not always the case. It’s a fairly minor nitpick, but it does affect some things. Scanline shaders in particular are affected quite badly by this.
if the core is aware of the res change adding SET_GEOMETRY should be trivial but I’m not sure if it’s the case
Using standalone on a game like NiGHTs, which runs at 224p, setting the video to software results in letterboxing, so yes, it does seem to be aware of variance in vertical resolution.
I’ve added preliminary 3D pad support, but it seems a bit overly sensitive in the menu of Nights. Seems to work okay in game, but I’ve no experience of how it played on actual hardware. I’m trying to add support for the save ram as well, what is the best way to implement it, use the built in functions and just set the path correctly on init (using some string manipulation on retro_game_info->path) or use the retro_get_memory_data function?
Saving should now work if you build from git and there is now the option to attach the expanded ram cartridges for those games that require them (though I haven’t tested this to ensure it works yet).
I tried it out and the saving works great! I tried out 3D pad support on Panzer Dragoon Saga and that was a bit off though. If you start the game with it enabled you get no input. It will work if you start it with the normal Saturn pad and enable it in game though. But you lose input on the save screen and have to switch back to the normal pad for input to work again. I don’t think that happened last time I tried that game on stand alone Yabause with the 3D pad. I haven’t tried it with any other games yet.
Yeah, something is definitely off with the analog. I’m going to rewrite the peripheral core again after looking at how the qt port handles the input which will hopefully fix it.
Changes have been merged in that make the multitaps optional which appears to have fixed analog behaviour at least in Nights.
It works well for me now in Saga and Burning Rangers. I seem to get analog input in Panzer Dragoon I and II also; it must be acting like a Mission Stick for those two.