Please help testing upcoming openMSX release!

Page 34/42
27 | 28 | 29 | 30 | 31 | 32 | 33 | | 35 | 36 | 37 | 38 | 39

By Grauw

Ascended (9054)

Grauw's picture

18-06-2020, 13:50

ren wrote:

To sum the 0.16 changes up, if I get it right:

  • due to the move to SDL2 this vsync thing became available,
  • default setting is 'off';
  • Grauw noticed there's a loss in smoothness however (when 'off');
  • (I noticed pre-0.16 it makes a difference when I set vsync to a hard 'off' in the driver settings);

Yes, and more concretely, I’ve confirmed that 0.15 with SDL1 does vsync on both my Mac and Windows PC, so the default has changed and the statement in the release notes that “added setting to control vsync. Default is still disabled” is incorrect. If anything 0.15 might never have explicitly configured vsync so what it defaults to was left to the system or something.

ren wrote:
  • turning vsync on should improve smoothness (when machine & monitor refresh match), but will also lead to increased latency.

Latency is not really the issue I think.

ren wrote:
  • is there any vsync applied for PAL machines? (And would that work, you think, e.g. when running @ 100hz refresh?)

PAL will always have some judder when it doesn’t line up with the display refresh rate. Even NTSC will drops a frame here and there because the display frequencies don’t line up perfectly (e.g. when MSX is 59.92 Hz and the PC is 60 Hz). But that’s very infrequent and not intrusive.

ren wrote:
  • I think it would be nice to have some (debug) info available so one can verify which vsync mode is active (none, adaptive or full).

You mean set vsync? Smile

By sd_snatcher

Prophet (3270)

sd_snatcher's picture

18-06-2020, 14:04

Speaking of the migration to SDL2 effect on Macs, are you also having the "zoomed image on the external monitor" problem reported here, Grauw?

By pgimeno

Master (170)

pgimeno's picture

18-06-2020, 16:24

When the screen is controlled by the OS and not by the emulator, i.e. in probably 100% of the software emulators, you're going to get either tearing or stuttering, unless the emulator is able to synchronize to the video frequency of the system, which few do. And those which do depend on the OS running on a screen mode with a frequency similar to that of the emulated system.

That's a limitation inherent to the fact that the emulator doesn't have control over the refresh rate. FPGA-based emulators typically remove that limitation (besides reducing the latency significantly).

As for the change in the default, I believe it's not due to the migration to SDL2, but was introduced in this commit: https://github.com/openMSX/openMSX/commit/706793b5e27a012b71... which apparently is hard to revert now.

By ren

Paragon (1455)

ren's picture

18-06-2020, 18:17

Grauw wrote:

Latency is not really the issue I think.

So by latency I think I basically mean the thing called input lag.
(This is what the the Nvidia control panel has to say on enabling vsync: [...] However can have longer latency and lower performance due to render rate limits. [...])

Here's an article discussing how to combat it (for both regular as VRR monitors) (blurbusters.com) (do note the update/link at the top)

Grauw wrote:

You mean set vsync? :)

That doesn't show if the sync applied is adaptive or regular (full) :)

Btw: I recently (happily) discovered MAME has a 'Low latency' toggle now (Advanced Options). Would something like that also apply to (and if yes could it possibly be integrated into) openMSX?

Btw2: I tend to use Shmup! (the game) to get a feel for input latency. (Only sucks (still) no real MSX around to have something to really measure against ;))

By Grauw

Ascended (9054)

Grauw's picture

18-06-2020, 18:59

When I say latency is not a factor I mean that MacOS already always vsyncs the frames (and Windows too if it’s windowed), so the immediate-setting does not reduce input lag. In fact it makes it worse because half of the frames are dropped all the time, and inconsistently too (it varies between dropping none to dropping a lot as the emulator drifts out of and back in sync with the video display).

Can you try my smooth scrolling test ROM I linked earlier? On both my Macbook and Windows PC, I can not get a consistently smooth scroll anymore out of openMSX 16.0 on the default settings (immediate).

By Grauw

Ascended (9054)

Grauw's picture

18-06-2020, 19:30

pgimeno wrote:

When the screen is controlled by the OS and not by the emulator, i.e. in probably 100% of the software emulators, you're going to get either tearing or stuttering, unless the emulator is able to synchronize to the video frequency of the system, which few do. And those which do depend on the OS running on a screen mode with a frequency similar to that of the emulated system.

Of course a frame will be skipped or repeated here and there, but there’s a difference between one frame being dropped every 12.5 minutes due to the difference between 59.92 Hz and 60 Hz, and the constant inconsistent judder that is present now.

In other words, what you say is true, but it is unrelated to the issue at hand Smile.

pgimeno wrote:

As for the change in the default, I believe it's not due to the migration to SDL2, but was introduced in this commit: https://github.com/openMSX/openMSX/commit/706793b5e27a012b71... which apparently is hard to revert now.

I have tried it;

9e31999: Smooth, like with SDL_GL_SetSwapInterval(1) (vsync enabled).
9e31999 with SDL_GL_SetSwapInterval(0): Choppy, fast-forward works even with maxframeskip 0.
9e31999 with SDL_GL_SetSwapInterval(1): Smooth, fast-forward does not work with maxframeskip 0.

706793b: Smooth, like with SDL_GL_SetSwapInterval(1) (vsync enabled).
706793b with SDL_GL_SetSwapInterval(0): Choppy, fast-forward works even with maxframeskip 0.
706793b with SDL_GL_SetSwapInterval(1): Smooth, fast-forward does not work with maxframeskip 0.

So, that change had no influence on the issue.

By ren

Paragon (1455)

ren's picture

18-06-2020, 21:12

Oh, I just noticed this ticket in the issue tracker: Add run-ahead to reduce/avoid lag #1270

@Grauw, yeah, I tried already, just haven't gotten around doing the testing in a proper organised fashion. I'm messing with driver vsync off/auto/adaptive as well, plus the 'threaded optimization' setting. Triple Buffering might have impact as well.

I think I'll just set t.o. to 'off' (default = auto), and disable TB (= default), which, as I understand it, should, when enabled, improve the experienced smoothness, but should have increased input lag (somewhat) (as 3 frames are now buffered instead of 2 right?). Anyway this reddit thread seems to shed some light / provide some answers: Double or Triple Buffered VSYNC for Lowest Input Lag. I'll leave desktop compositing (which does have an impact as well) on (as only freaks know you can turn that off anyway ;))

As I said earlier: at first sight it seems things are worse indeed, like you described. I'll probably get around doing the testing somewhere tomorrow.

By Manuel

Ascended (16632)

Manuel's picture

18-06-2020, 21:16

ren wrote:

I'll stick to windowed testing, as probably it won't matter a lot since it's a windowed FS mode now?

Please test whether you see differences. IIRC some people did report a difference between fullscreen on and off.

Quote:

Should I set triple buffering on or off? One of those settings I'm never sure about Smile

Where is that setting? EDIT: oh, in your driver. Well, just keep it on default.

Quote:

That doesn't show if the sync applied is adaptive or regular (full) Smile

Do you really care??

Quote:
  • 0.16 seems to require a (little) bit more CPU (question is how much of that is due to (changed) video processing);
  • going back from FS to windowed the window doesn't restore properly: it's outside of the top left corner, with part of the window chrome (inc. the titlebar) out of reach.

What machine were you testing with? How much more? And with which settings? (On my system, vsync takes a lot of extra CPU time, due to how the NVIDIA driver works.)

About the FS to windowed mode: I recently added code that makes it restore at the same location as where it started. And that works for me. Can you give more details on the scenario? Does it always happen? Do you start windowed or fullscreen?

By Manuel

Ascended (16632)

Manuel's picture

18-06-2020, 21:14

Grauw wrote:

Yes, and more concretely, I’ve confirmed that 0.15 with SDL1 does vsync on both my Mac and Windows PC, so the default has changed and the statement in the release notes that “added setting to control vsync. Default is still disabled” is incorrect. If anything 0.15 might never have explicitly configured vsync so what it defaults to was left to the system or something.

Well, indeed we never explicitly set it enabled. On my Linux PC, it is disabled with 0.15.0. So, it's unclear what the default behaviour was... but now you can control it explicitly.

By max_iwamoto

Champion (482)

max_iwamoto's picture

18-06-2020, 23:12

Any idea when 0.15 will be released?

Page 34/42
27 | 28 | 29 | 30 | 31 | 32 | 33 | | 35 | 36 | 37 | 38 | 39