Please help testing upcoming openMSX release!

Page 38/42
31 | 32 | 33 | 34 | 35 | 36 | 37 | | 39 | 40 | 41 | 42

By Grauw

Ascended (9054)

Grauw's picture

21-06-2020, 22:32

Grauw wrote:
pgimeno wrote:

At 60 Hz, without vsync, the shadow was blinking somewhat randomly and there was a bit of tearing visible sometimes. With vsync, the shadow was stable most of the time and the scroll was smooth most of the time.

Thanks for testing. What about openMSX 0.15 at 60 Hz?

I’m asking because I wonder if on Linux 0.15 also used to vsync, since it did so on the other platforms.

By Manuel

Ascended (16632)

Manuel's picture

21-06-2020, 22:56

Grauw wrote:

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.

OK, so all you're saying is that things are OK for you if vsync enabled is the default.

引用:

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).

Yeah, we're looking into that if we can do something simple about that before the release. If not, it may be after the release.

The explanation? Do you mean, for you, right now? Or for users in general?
In case you're talking about the former: without vsync and doing full throttle, openMSX will output many more frames per second than 60. But with vsync, the amount of frames that can be output is actually limited to the monitor refresh rate. As the MSX frame rate is a fixed thing to the rest of the system, the whole emulation will be slowed down with it. (In the same sense, with a 50Hz host refresh rate, your MSX will be emulated too slow with vsync enabled and no frameskip.) So, what you can do is to let openMSX allow frames to be skipped, so that emulation speed won't be slowed down by the framerate of the host monitor due to vsync.

Unrelated, but funny... you can check how fast your host system can emulate a simple MSX without any video output slowing it down like this (on macOS/Linux):

$ openmsx -machine Toshiba_HX-10 -control stdio
<openmsx-output>
<openmsx-control>
<command>toggle_info_panel</command>
<command>toggle_info_panel</command>
<command>set power on<<command>
<command>set throttle off</command>
<command>info_panel::get_actual_speed</command>

repeat the last a couple of times to get some measurements.

On my 12 year old PC I get a number of around 175-205, means about 200x real time speed Smile

By Grauw

Ascended (9054)

Grauw's picture

21-06-2020, 23:20

Manuel wrote:
Grauw wrote:

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.

OK, so all you're saying is that things are OK for you if vsync enabled is the default.

Yep.

Manuel wrote:
Quote:

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).

Yeah, we're looking into that if we can do something simple about that before the release. If not, it may be after the release.

I agree the throttle cap is not a release blocker, it still speeds up, not as much as it used to but that may actually be useful depending on why you use it (since maxframeskip 100 is ridiculously fast). And there’s a reasonably logical setting to adjust it.

Manuel wrote:

The explanation? Do you mean, for you, right now? Or for users in general?

What I mean, if SDL1 used to vsync, for which I think there’s plenty of evidence by now, then why was throttle not capped in SDL1 while it is when vsync is enabled in SDL2. I haven’t read a logical explanation for that I think, so it’s a bit mystifying.

Maybe in addition to vsync, SDL1 was also triple buffering? With triple buffering you can safely discard a frame if it hasn’t been presented yet, whereas with double buffering you can’t, you must block. That could be an explanation. Though it doesn’t seem you can select between double and triple buffering from SDL.

By ren

Paragon (1455)

ren's picture

22-06-2020, 08:51

Manuel wrote:

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?

openMSX always starts out windowed, there is not way to configure it otherwise? (I think it also starts out windowed when I supply a set fullscreen CLI command, as it's applied 'after the fact'?)

Yes, it's reproducible 100% of the time, and is pretty annoying as you can imagine Wink
So what's put outside the viewport (left & top) seems to be exactly the window chrome: left window border & the title bar.

Switching renderers or the scale factor it stays on position, so that's good.

Now, another scenario: when I do Catapult Stop and Start again, it would be nice to have the window at the same position again (getting the default centered now). I think the program would then have to asses if the available screen space / configuration hasn't been changed since the last shutdown? (e.g. user changed resolutions in the meantime etc.)
If it has changed, then the default center behavior should be used I figure.

By ren

Paragon (1455)

ren's picture

22-06-2020, 09:59

Fullscreen
Regarding the new FS behaviour:

  1. Would it be feasible to implement the old exclusive FS behaviour as well (make it user-settable)? It has its merits... (see below);
  2. So now on a large monitors FS gives this huge screen, as it uses the desktop resolution. I think this is too large.
    What I could do in 0.15, which actually changes your display resolution, was play with display scaling (either monitor, or GPU/driver controlled). I generally don't want the image to 'blow up', but keep a sharp image and use a 1:1 mapping (at scale_factor 4 I then would have a 1280x960 image centered), or, on a smaller monitor, I would use aspect scaling, which is like 0.16's FS (only then I would have the benefits of a real low resolution and its refresh rate).

    So in 0.15 the FS res used was tied to the scale-factor:

    2:  640x480
    3: 1024x768
    4: 1280x960

Now with the new windowed FS would it be an idea to have a way to configure the scaling, and be able to get a centered (sharp) image (again)?

Of course, as a workaround, what I can do now, is simply change my desktop res, but that's kinda cumbersome / not ideal Smile

/ OTOH, tbh, I don't use FS all that much, and it isn't all that of a big deal changing my desktop res (which I would need to do anyway if I decide I want to run 50 Hz (windowed)) if I decide I want to play around Wink (use case: e.g. running PAL demos & stuff, getting best perf. out of games etc.)

*assess (referring to other post Wink)

By pgimeno

Master (170)

pgimeno's picture

22-06-2020, 20:34

Grauw wrote:
Grauw wrote:

Thanks for testing. What about openMSX 0.15 at 60 Hz?

I’m asking because I wonder if on Linux 0.15 also used to vsync, since it did so on the other platforms.

0.15 has vsync enabled, with all the consequences, maxframeskip included (when maxframeskip is 0, the throttle does not have any visible effect). I really thought vsync was disabled, I was wrong.

By Grauw

Ascended (9054)

Grauw's picture

22-06-2020, 21:19

pgimeno wrote:

0.15 has vsync enabled, with all the consequences, maxframeskip included (when maxframeskip is 0, the throttle does not have any visible effect).

Oh, you’re right, it is the same for me! So there is actually no inconsistency between the maxframeskip handling of 0.15 and 0.16 at all. Just in our minds. Another confusion resolved.

By Manuel

Ascended (16632)

Manuel's picture

22-06-2020, 22:12

ren wrote:
Manuel wrote:

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?

openMSX always starts out windowed, there is not way to configure it otherwise? (I think it also starts out windowed when I supply a set fullscreen CLI command, as it's applied 'after the fact'?)

Sure, go fullscreen and save your settings.

引用:

Yes, it's reproducible 100% of the time, and is pretty annoying as you can imagine Wink
So what's put outside the viewport (left & top) seems to be exactly the window chrome: left window border & the title bar.

What I understand is that if you start openMSX (from Catapult?) it ends up in the top left corner, with the window handles just outside of the screen. Is that correct?
(Note that for me, it ends up in the center of my screen.)

引用:

Now, another scenario: when I do Catapult Stop and Start again, it would be nice to have the window at the same position again (getting the default centered now). I think the program would then have to assess if the available screen space / configuration hasn't been changed since the last shutdown? (e.g. user changed resolutions in the meantime etc.)
If it has changed, then the default center behavior should be used I figure.

This is not so easy to do. openMSX is fully stopped when the STOP button is pressed and fully started when the START button is pressed. It would require that openMSX tells Catapult where it was when quitting and then Catapult telling openMSX where to start.
If you don't mind: a bit too much hassle for me right now Smile (But if someone is willing to spend effort on that, I'd be happy to assist where needed.)

By ren

Paragon (1455)

ren's picture

22-06-2020, 22:40

Quote:

Sure, go fullscreen and save your settings.

Ah, okay, or go FS & exit of course Smile

Quote:

What I understand is that if you start openMSX (from Catapult?) it ends up in the top left corner, with the window handles just outside of the screen. Is that correct?

Catapult or not doesn't matter, and yes correct. Starting from FS: same issue. Any other Windows user around who can test/verify this?
Did you try yourself on your VM (you had one with Windows installed I believe)?

Quote:

[...] It would require that openMSX tells Catapult where it was when quitting and then Catapult telling openMSX where to start. [...]

Sure, I understand. Nothing Catapult specific though. You see in e.g. quite some media player applications the option 'remember window position', that's what I'm talking about. openMSX does remember e.g. scale_factor, it could store 'window position' in the same fashion? (O/c difference is scale_factor is set by explicit user command.) I guess you would only need to check if the stored position is within boundaries when you're creating/positioning the window, if not try to put it where it's relatively most close to the old position (or simply centered Smile)

By pgimeno

Master (170)

pgimeno's picture

22-06-2020, 22:36

Manuel wrote:

This is not so easy to do. openMSX is fully stopped when the STOP button is pressed and fully started when the START button is pressed. It would require that openMSX tells Catapult where it was when quitting and then Catapult telling openMSX where to start.

I think there's an easier way. Some programs save the window position on exit and restore it on load. Firefox works like this for me, for example. OpenMSX could have an option to do the same.

That looks like 17.0 material, though.

Page 38/42
31 | 32 | 33 | 34 | 35 | 36 | 37 | | 39 | 40 | 41 | 42