Please help testing upcoming openMSX release!

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

By Manuel

Ascended (16632)

Manuel's picture

19-06-2020, 00:17

December 2018 Smile

By max_iwamoto

Champion (482)

max_iwamoto's picture

19-06-2020, 01:24

Manuel wrote:

December 2018 Smile

LOL. I mean 0.16, the new version.

By pgimeno

Master (170)

pgimeno's picture

19-06-2020, 02:44

Grauw wrote:

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.

You're assuming that the monitor's frame rate is 60.00 Hz. Some have 100 Hz. Some have 70. Some have 62 or 63. Some have 59.5. And that's assuming that the MSX is used in NTSC mode. The frame rates can easily vary enough to make it annoying.

Grauw wrote:
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).

Isn't that what you got in 0.15 with SDL1? If so, you're confirming what I've said: that the migration to SDL2 was not the problem.

For me, both 0.15.0 and 9e31999 had vsync disabled, and 706793b enabled it.

The problem now, is that reverting that commit doesn't seem to be on the table, so the default vsync value has to be chosen in some other way, which will inevitably differ from how 0.15 did it. Or that's my understanding, at least. The current way (as of the date of this post) seems to make many users unhappy. There has been quite some discussion on IRC about what default to set, but no final conclusion yet IIUC.

By ren

Paragon (1455)

ren's picture

19-06-2020, 10:40

Quote:

Do you really care??

Yeah! You don't obviously? The vsync modes act differently, why wouldn't I want to know what's used/applied exactly? Seems helpful for debugging (kinda like we're doing now), and one might decide to not use vsync if it can't use adaptive..? (So I don't quite understand why this is on the heap of 'what's the use of it' (again).)

I think this could be nicely solved by introducing a vsync_mode setting. The current set vsync would be/remain the main toggle. The new setting would report the mode that's active. Then when user does set vsync_mode adaptive, and that would fail (idk what the conditions need to be to fail or succeed, simply driver support?) the command would return 'full' or 'regular' (since that's set instead then).

Still I think it would be interesting to have access to WHY it failed, there could be multiple reasons for that? Idk how that works, SDL and/or the video driver returns an error message?

I did notice, not sure, that the 'Status Info' tab in Catapult seems to report less info than before? That area is meant for these kind of debug/info messages am I right? Most of the time it's completely empty I notice.

Regarding (true, OpenGL) triple buffering: I think I've come to understand it's a good option (when using vsync). Problem is vendors, but also implementers seem to juggle with terms. There's this Anandtech article about it: Triple Buffering: Why We Love It. So true triple buffering isn't a linear buffer. (So it's weird that the guy from the video from that reddit link has bad results w/ triple buffering, that shouldn't be?)

Btw: you, nor the team experience the video rendering regression we're discussing ATM?
Will do some testing later.

By Manuel

Ascended (16632)

Manuel's picture

19-06-2020, 13:28

Which video rendering regression do you mean exactly?

The current idea is: you enable vsync or not. And adaptive is the 'best' vsync, so that is attempted and if it doesn't work, you get normal vsync. If you don't like it, you change the setting. The reason why adaptive isn't working is not known to openMSX, SDL2 doesn't report about that. Keeping things simple also has its merits Smile

What are you missing in the status info tab? It can be completely normal that it's empty.

By pgimeno

Master (170)

pgimeno's picture

19-06-2020, 13:33

ren wrote:

I think this could be nicely solved by introducing a vsync_mode setting.

I advocate instead for an info command that retrieves the current actual value. Having a setting for that seems to imply you can set it to whatever (legal) value you want, which is not always the case, and probably create confusion with the other setting.

ren wrote:

Still I think it would be interesting to have access to WHY it failed, there could be multiple reasons for that? Idk how that works, SDL and/or the video driver returns an error message?

AFAIK there's only one reason for it to fail, that the driver does not support it. See https://wiki.libsdl.org/SDL_GL_SetSwapInterval

By Grauw

Ascended (9054)

Grauw's picture

19-06-2020, 13:43

Triple buffering increases latency. Should not be needed unless the emulation process is sometimes slower than the framerate.

By ren

Paragon (1455)

ren's picture

19-06-2020, 15:48

Grauw wrote:

I can not get a consistently smooth scroll anymore out of openMSX 16.0 on the default settings (immediate).

Well, 0.15 isn't consistently smooth either (judging on your vid) (neither it is here), there simply are the occasional hiccups, sometimes more, sometimes less.
It does looks better overall than the 0.16 vid. Are these consistent results you're getting?

I seem to get better results than yesterday (for some reason), bus still (perceived) smoothness seem to be somewhat like a fluke. 0.15 sometimes (quite often) starts out smooth, and stays that way for a while, at other times it's choppy from the beginning.

The 0.15 behavior seems comparable to 0.16 w/ vsync on (slightly better perhaps). 0.16 vsync off is sometimes smooth, but 0.15 seems to be more often smooth.

I'm having my driver's vsync to 'application controlled'. Also made an effin table, let's see if I can paste that, I'm kinda done testing this thing Wink

@Manuel: normal vsync could mean you're falling back to 30 fps? Keeping things simple, but cater to the power user? I don't get it why you seem set on abstracting this setting away.

@pgimeno: I think just the set vsync command could cater to everything. Instead of reporting 'true' it could e.g. report the current mode. But if the current setting reported differs from what can be given as input that might deviate from how the other set commands work I think?

Btw: so I believe it's fine to toggle vsync on-the-fly in openMSX, i.e. I don't have to restart the emu?

By Grauw

Ascended (9054)

Grauw's picture

19-06-2020, 15:51

Thanks for testing!

ren wrote:
Grauw wrote:

I can not get a consistently smooth scroll anymore out of openMSX 16.0 on the default settings (immediate).

Well, 0.15 isn't consistently smooth either (judging on your vid) (neither it is here), there simply are the occasional hick-ups, sometimes more, sometimes less.

On both my Macbook and my Windows PC the 0.15 video is silky smooth[1], and it should be on your system too. If the video is not playing smoothly do you have a system issue perhaps? If smooth video playback can’t even be guaranteed you can’t compare openMSX results properly I think.

[1] There is a slight pause at 0:02 but that is me releasing the cursor keys briefly, if you step through the frames the shadow keeps alternating every step.

ren wrote:

It does looks better overall than the 0.16 vid. Are these consistent results you're getting?

Yes.

ren wrote:

I seem to get better results than yesterday (for some reason), bus still (perceived) smoothness seem to be somewhat like a fluke. 0.15 sometimes (quite often) starts out smooth, and stays that way for a while, at other times it's choppy from the beginning.

So in summary: both 0.15 and 0.16 are quite bad for you Smile.

ren wrote:

I'm having my driver's vsync to 'application controlled'. Also made an effin table, let's see if I can paste that, I'm kinda done testing this thing Wink

This part I don’t get. Driver? That sounds like a Windows thing, on macOS there are no driver settings afaik, even if you use an eGPU? You’re testing on macOS aren’t you?

Regardless, I have not tweaked anything related to video display of my Macbook, everything is on default settings insofar anything could possibly be tweaked using special utilities or anything like that. Same on my Windows PC. This “application controlled” setting you mention, it is the default?

By ren

Paragon (1455)

ren's picture

19-06-2020, 16:47

Nope, still on Win7 here (postponing the Linux switch.. Tongue)

Quote:

If smooth video playback can’t even be guaranteed you can’t compare openMSX results properly I think.

Surely not, and f* me!
I jumped back to a jumpy/stuttery part in your vid. an then there was none (well, at another point in time there was Wink)!

My box *is* seriously aging, in fact I was about to tell that perhaps I might not the best candidate to verify against Smile

I do have a serious deviating system clock issue for a while now, kinda forgot about that, remedied it by syncing the clock w/ internet time every 30m. Smile Could that be related to this issue as well you think, and could that in turn be related to a depleted CMOS battery? (I do for sure know I should replace that one Wink)

Quote:

This “application controlled” setting you mention, it is the default?

Yes.

-edit: though 2D perf./sync is different from 3D/OpenGL handling.. Another Windows (7) user (or Linux user perhaps) that can report how smooth the linked video by Grauw is for him/her? (I can e.g. get a smooth result from TestUFO...)

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