Please help testing upcoming openMSX release!

Page 30/47
23 | 24 | 25 | 26 | 27 | 28 | 29 | | 31 | 32 | 33 | 34 | 35

By Manuel

Ascended (16974)

Manuel's picture

03-06-2020, 23:40

And you mean that if you close Catapult completely and start it up later, you got the last selected ROM in the Cart A box with openMSX 0.15.0?

By Manel46

Hero (595)

Manel46's picture

04-06-2020, 00:38

Yes. In previous versions of 0.15.0.
This was very practical for me.
But it is a minor detail.

By ren

Paragon (1522)

ren's picture

04-06-2020, 12:14

I can confirm what Manel is talking about - just went from 828 to 840, in the former it was still working fine. So you still have your history in the dropdown, but there's nothing selected when starting up Catapult, where formerly the last selected item was (pre-)selected.

Manuel wrote:
Manuel wrote:
ren wrote:

Not sure if this has been reported before, an annoyance: when changing renderers, the openMSX window re-initializes itself centered on the primary screen.

Esp. annoying when you've got the window on an other display than Primary Smile

I think I can do something about it. Will let you know.

Should be solved now in 0_15_0-836-g510738e40 and later. Please confirm when you can.

Yes, convenient, thanks!

By Manuel

Ascended (16974)

Manuel's picture

04-06-2020, 13:19

It's interesting, because there is no change in the Catapult code. But there's a new version of the wxWidgets library used. I'll check it out.

By Manuel

Ascended (16974)

Manuel's picture

04-06-2020, 14:08

You're right! See https://github.com/openMSX/wxcatapult/commit/6fdb4b5d817ce4d...
Thanks a lot for reporting guys!

Fixed binary will be up soonish, I hope! :)

By Manuel

Ascended (16974)

Manuel's picture

05-06-2020, 23:47

Yes, should be up now on https://openmsx.dev/ Can you confirm ren or Manel?

By Manel46

Hero (595)

Manel46's picture

06-06-2020, 00:58

Yes, confirmed. It works perfectly, thanks.

By Manuel

Ascended (16974)

Manuel's picture

06-06-2020, 00:58

Thanks for testing. Anything else that got broken? Smile

By Manel46

Hero (595)

Manel46's picture

06-06-2020, 00:59

All good! Smile

By Manuel

Ascended (16974)

Manuel's picture

06-06-2020, 11:45

Grauw wrote:
mth wrote:

With SDL1, it could be that vsync on or off was never explicitly selected, so we'd end up with the default which could differ per OS or even per graphics driver.

Looking at Grauw's video, in the stuttering parts, the screen updates only every other frame, instead of every frame. This goes for both the MSX part of the screen and the stats overlay, so it is the entire application output that ends up in limbo.

Immediate page flipping causes tearing, but apart from that tearing, it should be fluent. However, that assumes that what the application outputs gets displayed immediately by the OS as well and it seems at least macOS has extra buffering. What I don't understand though is why it would drop every other frame over an extended period of time; I had expected one frame to be dropped or repeated every now and then if openMSX doesn't output exactly at the monitor's refresh rate.

The best solution is adaptive vsync with hardware support (like G-Sync and FreeSync), but I don't know if this technology will become the standard for everyone or remain a niche feature for gaming monitors. I'm also not sure that the SDL2 "adaptive" setting is actually using hardware adaptive vsync; the documentation wasn't clear about that.

The busy waiting that Manuel encountered is a problem, in the sense that we need to work around it. But it's a problem of a particular graphics system, not a problem of vsync in general.

Anyway, fixing this properly is going to take some time, so for the short term I think we should keep the vsync setting and figure out what the best default value would be, perhaps separate per OS.

Is this still on your list of things to address before this release?

Just making sure it isn’t forgotten :).

Grauw, this issue is not so easy to solve. What would be a good default for one situations might not be a good default for the other. On your macOS and hardware/driver combination, the immediate (no sync) is a bad default. But on others it may be the best.
E.g. ericb reported 60fps on his mac with the default settings.

So what can we do? Can other testers report their OS and their results with the new sync_to_vblank_mode setting?

Page 30/47
23 | 24 | 25 | 26 | 27 | 28 | 29 | | 31 | 32 | 33 | 34 | 35