I ignored the video. My testing was directly with the ROM.
I used the official 0.15 version.
@santiontanon Could you perform the same test with the latest development build available here? OpenMSX 0.15 was fine and smooth, however at least on my Mac and PC it regressed in current development builds. We’re trying to get a bit more testing coverage on it.
Some new results. So I'm on a single monitor now, should/might give more reliable results.
Haven't compared 50Hz yet, but FAC IV runs buttery smooth on 0.15!
Again: definitely different behavior in 0.16. Though throughout I might get the best smoothness from 0.16, driver vsync On (or Adapative), openMSX vsync On, but must be in fullscreen! Windowed will give me a (small) stutter every now & then.
In chronologous testing order:
1] 0.15, driver vsync Auto (= 'application controlled')
* cpu in the range of 1 to 5%, w/ occasionally spike up to 40%, which will gradually go back to low values again.
* smoothness is good (as I described before: can run smooth for a while, but at a point will have some stutter/judder, and go back to smooth again. Pausing & resuming seem to help when rendering goes juddery.)
2] 0.15, driver vsync Off
* very low (best) cpu values: 0 - 2%
* slightly more chance on a stutter, so it seems.
* FS: getting a thick 'hum'/tearing bar now of about 15 to 20% of the viewport in height, moving (slowly) from top to bottom.
3] 0.15 driver vysync On
* seems to behave same as case 1.
4] 0.16, driver vsync Auto, app (openMSX) vsync Off
* windowed: mixed results, seems more 'stuttery' (more chance) than 0.15 though;
* FS: tearing / small 'hum bars' appearing on alternating horizontal positions
* can be as smooth as 015, but seems overall more problematic (esp. FS)
5] 0.16, driver vsync On, app vsync On (triple buffering also On)
* FS seems perfect, fluid throughout;
* only drawback: perhaps slightly more input lag (should test a shooter for that);
* windowed is less good: a stutter every now & then.
6] 0.15, driver vysnc On, triple buff. On
* very good results, both windowed & FS (latter even better I think)!
So throughout, changing openMSX's vsync doesn't seem to matter a lot, except for what I described at case 5 (combining it with the vsync of the driver)!
(Some of my findings here might be quite specific to my system though (hw in combin. w/ OS & drivers)
)
Note that I have Threaded optimization Off, when that's on or auto, it will result in (very) high CPU usage! (Again could be a my system issue.)
Both settings of vsync in openMSX 0.15 produce very smooth scrolling and barely noticeable flickering (I had to stop movind and really pay attention to it to notice).
I used the official 0.15 version.
So, you were talking about the vsync setting in your driver control panel?
Indeed, please also check with the latest development build and the new openMSX vsync setting.
50 Hz results ((f* the) FAC IV)
So simply checked how smooth the scrolls were.
vs = vsync (driver), tb = triple buffering, vso = vsync openMSX
In order of testing:
0.15
1] vs: on, tb: on
win: good (occ. stutter)
fs: perfect?
2] vs: auto, tb: on
win: bad, high cpu! 46 - 50%
fs: good/perfect
3] vs: auto, tb: off
win: good
4] vs: on, tb: off
seems same-ish as /w tb on, though in fs spotted couple of hiccups
0.16
6] vs: auto, tb: off, ovs: off
win: meh (occasional stutter)
fs: tearing, stutters
7] vs: auto, tb: off, ovs: on
win: somewhat better
fs: somewhat better as well, but also tearing
8] vs: on, tb: off, ovs: on
win: pretty good, occasional (rel. big) hiccup though
fs: pretty good, occasional (rel. big) hiccup though
9] vs: on, tb: off, ovs: off
win: see above
fs: see above
10] vs: on, tb: on, ovs: off
win: no diff.
fs: pretty good, best of 0.16 yet?
11] vs: on, tb: on, ovs: on
win: same?
fs: same?
12] vs: off, tb: on/off, ovs: on/off
_: throttle = fast!
win: not so good
fs: not so good
So I was testing @1080p 50 Hz, then, when I was done, I recalled I created a custom 1280x960 resolution @ 50.159 Hz yesterday. When switching to this res, case 11 was, what looked like, perfect! (And running this res might have improved all the other cases as well.) (Upd: yes, seems that way.)
I do doubt whether the specific refresh I specified is actually honored, or that the monitor sets itself to a round 50 Hz, which is what I'm getting when checking the refresh on the web in Chromium (couldn't find a native app that's detailed enough), just like the standard 1080p res.
Oh, apologies for testing with the wrong version. I just downloaded the latest development version I could find (openmsx-0.15.0-848-g4dbe0355f-mac-x86_64-bin.dmg), and tested with "sync_to_vblank_mode" sync or immediate.
There is a big difference between 0.15 and the dev build.
- with 0.15: all smooth in any configuration (except if I bring up the openMSX console)
- with the dev build is a bit more interesting:
- in windowed mode with sync_to_vblank_mode=sync. Things are pretty smooth.
- in windowed mode with sync_to_vblank_mode=immediate, I get flickering and kind of choppy scroll (but not too bad)
- in full screen mode regardless of the value of sync_to_vblank_mode it's irregular flickering and choppy scroll
Again this is in a Macbook pro 13 inch (with the magic touch bar) from 2016.
santiontanon: in the version you have, the setting was renamed and changed to a boolean setting. Setting name is vsync
and values can be on
or off
. If you really used the old setting name, this will have had no effect at all. So it is already interesting that you did get some effect in windowed mode...
Note that the vsync setting is also in the OSD menu.
@grauw: perhaps I missed it, but are things OK on your two systems when vsync is on, in openMSX? Or is there still a regression then?
Yes for me things are fine when vsync is on. With that it is as smooth as 0.15 was, both windowed and full-screen. Also there is no difference in CPU usage.
There’s still that thing where of course the throttle now obeys the maxframeskip where it did not before, but I don’t mind that (though a logical explanation of how it changed would be nice).