CPS2 - slight lag / frame skip in some games

[madmax]

Hi

I found that the newly released CPS2 core has slight lag / frame skip in some games like Street Fighter Alpha 3, Marvel Vs Street Fighter.
Unless you played these games for a decade or owned the real PCB on a CRT monitor, it is almost unnoticeable.

I observed this on two different mister, two different microsd installation, two different LCD monitor and various controllers.

Did someone noticed the same ?
It is not happening with CPS1 or Neogeo (this one has a pitch issue in the sound)

[akeley]

MiSTer doesn't guarantee 0-lag on various controllers or HDMI displays out of the box. You need to take some steps to minimize it, and even then it can be down to your display/controller. See this: https://github.com/MiSTer-devel/Main_Mi ... -Explained

[FoxbatStargazer]

I'm trying to find the exact refresh on CPS2 and coming up empty... LCDs can start dropping or pausing on frames if the refresh is too far from 60, but Neo Geo is already down at 59 so issues would surely show there.

[hideous]

Log the issue here for better visability: https://github.com/jotego/jtcps1

[mr-box]

strange can you give a example i want to try to reproduce it so far i don't feel any lag or frame skipping on my crt tv . the core is still in beta i dont think JT comes here that much you need to go to his discord or post bugs on github

[atrac17]

I'm trying to find the exact refresh on CPS2 and coming up empty... LCDs can start dropping or pausing on frames if the refresh is too far from 60, but Neo Geo is already down at 59 so issues would surely show there.

1.png (127.81 KiB) Viewed 7678 times

[AtomicShroom]

Unless you’re outputting to CRT monitor that supports the exact same refresh (hz), you’re bound to see a frame skip once in a while. Most LCD monitors don’t refresh at the exact same rate, hence frameskips.

[Insert Disk Two]

Ideally we get an option to have cores running at exactly 60hz to maximise compatibility with the various lcd monitors

[FoxbatStargazer]

59.6 isn't that far off NTSC spec (which is 59.94, not exactly 60), and its way closer than Neo-Geo. So if Neo-Geo is perfect its unlikely that CPS2 has that problem. (Unless the monitor has more trouble off of near-integer amounts?) Using vsync_adjust=0 is also going to invite lag and stutter on the Mister side but OP probably knows that...

Still using a CRT to verify would 100% confirm that there is a problem and remove the whole LCD question. Also note that Jotego still considers the core "beta" with problems so he might even know something is up. (maybe some pauses added to deal with Mister's slowish memory?)

[madmax]

Thank you all for sharing informations and debating on this. Ive only observed the issue on CPS2 but not happening with CPS1.
It looks a refresh issue with my current monitor (support freesync only on displayport) which maybe the reason I see frame drop once in a while.
I have another old freesync monitor lying around, which support freesync on hdmi port. would it help to solve the issue ?
I assume freesync hdmi is not the same as hdmi 2.1 vrr.

Thank you

[FoxbatStargazer]

Freesync itself is semi-irrelevant, Mister cannot provide the right protocol/handshake to activate it. It all comes down to how the monitor interprets "normal" resolutions, whether it forces a certain refresh and drops or adds frames to meet it, or it displays the refresh it is receiving.

Example, I have a freesync monitor with a 48-120 range on HDMI. If I feed it 50hz via mister I get an absurdly choppy image, basically looks like it is converting to 60. If I force 100hz it gets quite a bit smoother, though I'm not sure it is showing 100 or 120. Meanwhile on windows PC with adaptive sync enabled in Retroarch 50hz is silky smooth.

On the other hand, I've tried several generations of Sony LCD TV, no HDMI 2.1 or VRR support, that all show 50hz correctly when fed video_mode=9 (but run choppy on video_mode=8.)

Basically blindly buying a display that will sync to the exact refresh of various Mister cores can be a headache. The best luck I've had is with older LCDs that have VGA and DVI ports instead of DP and HDMI, these often lack any kind of refresh adjustment, and you get weird sync errors if you go out of range rather than frames getting dropped or added. Unfortunately these tend to be kind of bad in the motion blur department.

[atrac17]

Ideally we get an option to have cores running at exactly 60hz to maximise compatibility with the various lcd monitors

This already exists. It's in the ini file.

Code: Select all

[jtcps2]
vsync_adjust=0

I don't know why people just don't use this for 60Hz on cores that don't display on their monitors for 60Hz. The whole point of FPGA is accurate timing to include the refresh rate. It's just a waste of time for a core developer to write a wrapper for a refresh toggle in the core when you can do it yourself (if needed).

[Chris23235]

Ideally we get an option to have cores running at exactly 60hz to maximise compatibility with the various lcd monitors

This already exists. It's in the ini file.

Code: Select all

[jtcps2]
vsync_adjust=0

I don't know why people just don't use this for 60Hz on cores that don't display on their monitors for 60Hz. The whole point of FPGA is accurate timing to include the refresh rate. It's just a waste of time for a core developer to write a wrapper for a refresh toggle in the core when you can do it yourself (if needed).

As I understood it, this is not the same as the core outputting 60 Hz. vsync_adjust=0 tells the MiSTer to output the signal it receives from the core in 60 Hz, regardless what the core uses. This leads to terrible choppy scrolling when running a PAL game on the MiSTer in 60 Hz. On the other hand look at the Cave core. This core has an option to output 60 Hz opposed to 57.4 Hz of the arcade machine. I tried both methods and found that the result of switching to 60 Hz in the core is much better then what you can achieve with vsync_adjust=0.

Again only as I understand it, switching the game to 60 Hz in the Cave core makes the game run slightly faster, while vsync_adjust=0 doesn't change the game speed, because it doesn't interfere with the core logic. The game runs in original speed but choppier.

[FoxbatStargazer]

It varies by approach. The cave core is actually overclocking the entire system to get up to 60 hz. So with that and vsync_adjust=2 you will get a bufferless low lag experience, even though the game is running a bit too fast. But cores like Ao486 and wonderswan and atari lynx not downclocking to go from 70 or 75 to 60 hz, they are instead using their own buffer that is kind of duplicating what vsync_adjust=0 would do. So in those cores even with vsync_adjust=2 the games are still running at the same internal rate, and you have a bit of choppiness/lag added due to the core itself doing buffering and framerate conversion instead of the scaler. Still the one benefit of this latter approach is getting 60 hz out of the analog signal, so you can use those 70+ hz systems on a consumer 15khz CRT.

[atrac17]

Ideally we get an option to have cores running at exactly 60hz to maximise compatibility with the various lcd monitors

This already exists. It's in the ini file.

Code: Select all

[jtcps2]
vsync_adjust=0

I don't know why people just don't use this for 60Hz on cores that don't display on their monitors for 60Hz. The whole point of FPGA is accurate timing to include the refresh rate. It's just a waste of time for a core developer to write a wrapper for a refresh toggle in the core when you can do it yourself (if needed).

As I understood it, this is not the same as the core outputting 60 Hz. vsync_adjust=0 tells the MiSTer to output the signal it receives from the core in 60 Hz, regardless what the core uses. This leads to terrible choppy scrolling when running a PAL game on the MiSTer in 60 Hz. On the other hand look at the Cave core. This core has an option to output 60 Hz opposed to 57.4 Hz of the arcade machine. I tried both methods and found that the result of switching to 60 Hz in the core is much better then what you can achieve with vsync_adjust=0.

Again only as I understand it, switching the game to 60 Hz in the Cave core makes the game run slightly faster, while vsync_adjust=0 doesn't change the game speed, because it doesn't interfere with the core logic. The game runs in original speed but choppier.

What PAL game are you running from CPS2? Also, I am aware of the Cave core wrapper. Running it at 60Hz isn't the proper way to play C68k hardware. I'm aware it's not perfect. Again, I was pointing out a work around. I thought the whole point of this was accuracy?

[dazzer69]

It will be interesting to see what Jotego chooses to do when he surely tackles R-Type.

[Insert Disk Two]

I mean like Dodonpachi has. Game runs at a slightly different speed so it matches the exact display of 60hz while being smooth, stutter free scrolling.

If you rather have jumpy scrolling than "accuracy" then it should up to the end user to decide what's the best for him or her. I am always in favour of more options, I'm not an elitist. If something isn't for me I just don't use it, not hope that it didn't exist.

Ideally we get an option to have cores running at exactly 60hz to maximise compatibility with the various lcd monitors

This already exists. It's in the ini file.

Code: Select all

[jtcps2]
vsync_adjust=0

I don't know why people just don't use this for 60Hz on cores that don't display on their monitors for 60Hz. The whole point of FPGA is accurate timing to include the refresh rate. It's just a waste of time for a core developer to write a wrapper for a refresh toggle in the core when you can do it yourself (if needed).

[SuperBabyHix]

Someone correct me if I am wrong, but I believe the reason there isn't just some universal option to run any core at 60hz internally is because, well, you can't, unless the core was designed that way from the ground up.

I'm pretty sure the reason all the various consoles/computers have slightly different refresh rates is because it is generally tied the clock rate of some chip, possibly the cpu, which is why NTSC and PAL versions sometimes have slightly different cpu clock rates. So changing the refresh rate means changing the clocks of other things which can introduce bugs, timing errors, etc... So it's not as simple as flipping a switch. Again, I could be wrong, this is my laymans understanding though.

[Insert Disk Two]

Not really. Game just runs very slightly faster... Or slower. In fact console versions of Dodonpachi does exactly that, running at exactly 60hz. If it's OK for Cave, it's OK for me

As for your other comment 60hz switches have to be done per core. Considering that end users are patching, for example Neogeo core to run at 60hz exactly (see thread in Neogeo section) it is doable.

[aberu]

Someone correct me if I am wrong, but I believe the reason there isn't just some universal option to run any core at 60hz internally is because, well, you can't, unless the core was designed that way from the ground up.

Yes. There could be something added to Main that is a default OSD option for this which could make the "glue" a bit easier to work with (I feel like there already is actually now that I think of it...), but the developer of the core would have to do it for each core, each time, anyways.

[dazzer69]

Not really. Game just runs very slightly faster... Or slower. In fact console versions of Dodonpachi does exactly that, running at exactly 60hz. If it's OK for Cave, it's OK for me

As for your other comment 60hz switches have to be done per core. Considering that end users are patching, for example Neogeo core to run at 60hz exactly (see thread in Neogeo section) it is doable.

Irem M62 core also has OSD switch to slow it down to 50hz from the it’s native 55hz.

[Insert Disk Two]

Ideally cores have a speed up / slow down core speed maybe one hz at a time. Say your display didn't support 55hz, but it's fine with 57hz. Going straight to 60hz or 50 is quite a jump, so the user could increase it to 57hz and get a display. Obviously this is not a simple task to do.

[dazzer69]

I’d imagine that something like that was possible in the realm of FPGA. But the fact that no one has done it already would suggest it’s not straightforward.

[Insert Disk Two]

It is possible of course as it has been done. I guess the reasons that it's not actively implemented are:

1. Devs are interested about accuracy, not display compatibility (even though these are not mutually exclusive)

2. It takes time to develop such features and I suspect that many devs feel that making screen compatibility features is a waste of time a they would be rather working on something else.

Bottom line: we should be thankful for what we are getting for free thanks to the work of some incredible developers. We can of course ask for things and explain why these would be nice to have, but in the end these are just suggestions and up to devs to pick up, or ignore.