I built Kronos standalone because the instructions for building the libretro core seem to be out of date (setting KRONOS_LIBRETRO_CORE doesn’t actually do anything).
Anyway, testing OpenGL stuff seems like a waste of time right now, when there are much more basic compatibility problems. OpenGL renderer would be great, but first the games need to actually be playable.
I don’t know what’s that supposed to mean but to build a libretro core you usually just need to locate its libretro makefile and run make on it. Kronos’s libretro makefile is located here. When having doubts you can also look at the .gitlab-ci.yml file at the root of repository, it includes the location of the makefile.
So one way to build it would be to run this :
# clone kronos branch into a folder named Kronos
git clone https://github.com/libretro/yabause.git -b kronos Kronos
# change directory
cd Kronos/yabause/src/libretro/
# run make with 4 parallel jobs
make -j4
I believe to make a core running “ok” on medium range handhelds it would be better start from the ground, except if pick one “light” core and start fixing things. Messing with all cores probably won’t be very productive as some are much heavier than others, you could end up with a dynarec for beetle saturn and run worse than yabasanshiro as i think 3D emulation eats many resources too.
I downloaded Kronos 2.7.0_official_release from github and tried to build that, but the instructions for building the libretro core were outdated or incorrect.
Building the source from libretro git did work. I really don’t have the right GPU for this. It runs, but slowly. There are some graphical glitches, although overall it seems a bit better than the old yabause.
Saturn emulation in general is in a pretty bad state, and I don’t know what’s really worth fixing.
One path would be to try to reintegrate the various changes from Yabause, YabaSanshiro, and Kronos. Each of these seems to fix some things, and break others.
The other path would be to try to improve beetle-saturn. The compatibility with games is actually pretty good here, it’s just slow and missing some features.
There are a bunch of things that I would need to understand better before I could really work on this. One is how does the frameskip in Yabause actually work. Mednafen/beetle doesn’t speed up much with frameskip, whereas dropping frames in Yabause actually saves a bunch of time, but glitches some games.
The HLE BIOS in Yabause seems to work, so I’m wondering why other emulators dropped this since it seems like it could speed up some things.
The dynarec also seems to work pretty well, so I’m wondering what obstacles there are to using this. Maintaining a dynarec does take some extra work since there is the risk that the assembly code breaks due to changes in APIs or operating systems, but emulators for pretty much everything newer than Saturn (DC, PS2, GC, etc) use dynamic recompilation, so this seems manageable.
The SCSP (sound processor) emulation takes a lot of CPU time, so I’m wondering what exactly is going on there. Can this be done in a separate thread?
Medanfen has some major input lag issues and I don’t see this with PS1 emulation, so this seems specific to the Saturn core. I don’t see a similar slowdown in Yabause.
I’m really not sure where to start with a lot of this.
Because there are countless bugs with it, and it doesn’t even allow to swap disc with m3u.
It had 3 frames of input lag on average the last time i checked, which is pretty low for saturn emulation as previously discussed. Why are you comparing apples and melons ?
That’s not the issue. The problem is that, at least with keyboard input, when you press a key it stalls the entire emulator. Even if it has only 3 frames of input lag, it takes much longer to process those frames. With frameskip enabled, it will drop some frames.
I don’t know what’s going on with that. It’s one of many issues to investigate.
I looked at yabause core source, that looks crazy complex lol. 8.000 lines of code for vdp1 only iirc. Talking about 100.000+ lines of code probably.
Did some game tests on i7-7700 Linux laptop, Hexen looks like it runs more smooth on Yabause than the other 2 cores (beetle saturn, yabasanshiro). Like higher internal framerate or something, with some minor slowdowns. Would need some high determination and elite expertise on coding and Saturn internals to improve things. Probably drop anything you do on your free time for the next 6 months (if one has the elite level i mentioned).
I would need to understand the VDP1 code better before I could make a lot of progress on this. Unfortunately, I probably won’t have a lot of free time to work on this over the next 6 months. This is why I suggested sponsoring another developer.
I saw the dynarec as a straightforward way to fix some of the performance problems, so that was the first thing I tried. It does work, and gives some speed boost, but it’s clear that this alone isn’t going to be enough to achieve the desired performance goals. The VDP1 and SCSP need a lot of work, and there are still quite a lot of other bugs.
Saturn emulation is currently somewhat acceptable with the right hardware, but there really isn’t a good solution for handheld or mobile, or even many laptops. Moreover, some games don’t work in certain emulators. This likely isn’t going to change soon, unless we can find someone who really understands this stuff and is able to work on it.
Medanfen has some major input lag issues and I don’t see this with PS1 emulation, so this seems specific to the Saturn core. I don’t see a similar slowdown in Yabause.
(I’m not an emu dev. Just my experience and what I read)
Saturn games often (though not always) had more input lag than their PS1 counterpart. This apparently happened on hardware as well.
Resident Evil for example lags quite noticeably more on Saturn than on PS1. While Street Fighter Alpha (1) seems on part with PS1.
Likewise, some arcade ports lag quite a bit more on Saturn than on arcade (the Saturn King of Fighters ports for example) while other ports feel pretty much the same. Ex: Sat port of Super Gem Fighters Mini Mix. Maybe one additional frame. Usually, I found Capcom arcade ports are quite good in this regard while SNK’s ports…not so much.
There’s also Saturn exclusive such as SteamGear Mash that feels extremely responsive -almost next frame but most likely 1 frame.
So basically seems it was very dependent on how the games were programmed and optimized and whether or not the devs optimized the processing chain. If they didn’t, then yeah, it could lag quite a bit more than PS1.
All this to say I don’t believe Beetle Saturn adds any significant lag -it can be pretty much on part with hardware, provided the user uses lag reduction options like hard sync on their end of course (there’s also an option in Beetle Saturn called “Mid-frame Input Synchronization” which might help decrease it further but will add an additional CPU cost).
The slowdown when keys are pressed seems to be specific to mednafen standalone, I don’t notice it with beetle-saturn (mednafen_saturn_libretro.so, built from github.com/libretro/beetle-saturn-libretro.git)
This seems to be an issue with how the emulator handles keyboard input, which is different than the issues with the Saturn hardware.
I’m not quite sure what the Mid-frame Input Synchronization setting does. There doesn’t seem to be an equivalent in Mednafen 1.32.1. Unlike mednafen standalone, beetle-saturn doesn’t seem to have any frameskip, it just slows down and the audio stutters.
Also, save states work in mednafen, and not in beetle-saturn. Beetle-saturn isn’t quite the same as mednafen that it’s based upon.
Probably not even releasing the actual source code but some of the tweaks only so he is the one that knows the sacred secrets lol. Later fooling everyone they make some mistake when compiling, it works perfectly on his side.
Seen this kind of crap happening, some chucklefuck takes over/hijacks a project, slaps his name in or renames the core completely like it’s their own, with a common motivation which usually is profit from another person’s work. And this usually kills the project for good. And the funny thing is they don’t have a clue wtf they doing.
There may have been cases of developers not sharing patches, but the bigger issue is that Yabause, Yabasanshiro, and Kronos all have changes that fix some things and break others. That code is available, but reintegrating all of it into one usable emulator and getting everything working would take a lot of effort.
I could try making a list of the games that don’t work and other bugs, but it’s a long list. I posted many issues above. I’d estimate it would take a good developer at least six months to a year to fix all of this, and I don’t have the time to dedicate to it right now.
Several people have offered to help fund this, so if there’s a developer who’s interested in working on this project, we can talk about sponsorship.
Kronos removed all the hacks used in yabause/yabasanshiro, and has the highest accuracy/compatibility among those 3. Over 2145 tested games, 1982 were playable (92.4%). I don’t think you know much about Kronos.
“Playable” is a bit subjective, as games are listed as playable even if there are glitches.
In another thread, someone complained that the graphical glitches in Sonic R were too much of a problem, although the game does run.
A lot of this turns out to be more complicated than it seems.
Being accurate to original hardware is not a glitch, it’s funny how people forgot about wobbling on those early 3D consoles just because pgxp was implemented on psx emulators.
This is Sonic R in Kronos : https://youtu.be/xI4gOdWa6UY
The “really bad wobbling” in mednafen is exactly the same, and you’ll find the same “really bad wobbling” on original hardware : https://www.youtube.com/watch?v=HlCBR46W_Qs
“Playable” usually means it can be played without issues affecting gameplay, and it is not nearly as subjective as making false statements about an emulator. I have to really wonder if you ever tested it.
Regarding what I was quoted on (and absolutely nothing else)
The issue with the floor in Sonic R on Kronos is not present in Beetle_Saturn, or moreimportantly real hardware. The video linked is not a great representation of what is happening, as the camera is flying around in this demo and you can’t even get a good look at the ground plane.
I’m not tainted by the existence of PGXP on PSX emulation, what I’m talking about in what was quoted has nothing to do with the standard polygon wobbling from these games. The entire floor texture is floating up and down like a raft on waves.
Which, again, isn’t present on beetle_saturn, or more importantly, real hardware. It’s an emulation inaccuracy. I can try to record a video of it, but if you boot the game, start a race on that first level, and run through the ruins past the bridge on the left and JUMP you will see exactly what I’m talking about there.
I tried the game before recording that video, and didn’t notice anything. I ended up recording the demo because i suck at this game.
Issues should be reported on the project’s github, not on a 3rd-party forum. Unreported issues are less likely to get fixed. Also keep in mind you need to use original resolution if you plan to make a valid comparison against mednafen or real hardware, upscaling is only gonna magnify any problem natively present in the game’s code.
To be fair it’s not a very ‘good’ game to start with haha, even if I love it.
It wasn’t my intention to report a bug, as I mentioned I was only here because I got quoted and my quote wasn’t understood. That’s a good idea though, I’ll track down the git and see how to open one.
I tried and i have no clue what you are refering to.
I have a feeling this is exactly as i suspected and you are making some invalid comparison by using upscaling.