Please help testing upcoming openMSX release!

Page 27/42
20 | 21 | 22 | 23 | 24 | 25 | 26 | | 28 | 29 | 30 | 31 | 32

By friguron

Master (166)

friguron's picture

28-05-2020, 03:56

Oh my bad, I completely misunderstood the situation, please forget my question.

By DRomero

Expert (125)

DRomero's picture

28-05-2020, 12:35

Thanks a lot for the a new version, love the new features.

I dindt read all the pages to see if the issue was corrected. Truth is i didnt used openMSX reverse feature since almost the begining because if you use 4Gb hard drive images the emulator takes ages to just load, 10 minutes at least.

I think i posted this issue 2 years ago, and i was told here it was because the reverse feature and the SHA1 sum checking of hard drive images if i remember correctly. Te problem is not perceptible on 32MB images but on 4GB its another story. At least on Windows, its still working this way?

Another nice feature would be making openMSX trully portable. Some config files are still saved in My Documents folder in Windows, why is this hardcoded this way?

Stil issues on european keyboards under Windows, only Windows, most are Alt.Gr Key related. But i can live with it.

Anyway, nice set of new features, thanks a lot for your hard work.

By Manel46

Hero (554)

Manel46's picture

28-05-2020, 15:31

When trying to install the 0.15.0.834 msi version I get this:
https://drive.google.com/file/d/129taG_SJk_MRsUDSqoc9g176-bS...
Version 830, ok.
W7 64

By donluca

Expert (69)

donluca's picture

28-05-2020, 17:40

Manuel wrote:

Do you think it's even useful to have a 32-bit binary for Mac or Windows?

On macOS, no, absolutely no reason.

For Windows, actually yes, since there's a lot of people who build emulator-only machines recycling old hardware and want to use windows XP or 7 or whatever the lightest OS is supported on their machines (I know because I'm one of them Tongue ) and the 32-bit version is often faster and take less space on disk since they don't need a compatibility layer.

Please try and keep alive 32-bit windows versions, if possible. MAME has recently discontinued support for 32-bit builds and people are working around this creating their own builds, which should tell you a lot about the importance of supporting 32-bit builds on Windows (and Linux).

By Manel46

Hero (554)

Manel46's picture

28-05-2020, 18:24

But it always worked well for me with Windows 7 64 bit. Because now no?

By Manuel

Ascended (16642)

Manuel's picture

28-05-2020, 20:22

donluca: the 64-bit version will be faster if you run a 64-bit OS. That's for sure. The compatibility layer is to run 32-bit applications on 64-bit OS. So if you only use 64-bit on your old hardware, it's faster after all Smile

Manel46: apparently the recent (yesterday evenings) building of Catapult was not OK.

By Manel46

Hero (554)

Manel46's picture

28-05-2020, 20:39

You fix it fast. Smile

By Manuel

Ascended (16642)

Manuel's picture

28-05-2020, 22:06

DRomero wrote:

Thanks a lot for the a new version, love the new features.

Thanks, but the release isn't official yet. But, of course, you're free to try out our development builds any time Smile We even encourage you to do that.

Quote:

I dindt read all the pages to see if the issue was corrected. Truth is i didnt used openMSX reverse feature since almost the begining because if you use 4Gb hard drive images the emulator takes ages to just load, 10 minutes at least.

I think i posted this issue 2 years ago, and i was told here it was because the reverse feature and the SHA1 sum checking of hard drive images if i remember correctly. Te problem is not perceptible on 32MB images but on 4GB its another story. At least on Windows, its still working this way?

This is still an open point indeed. Reverse doesn't work well with hard disk images and I recommend to avoid using that combination.

Quote:

Another nice feature would be making openMSX trully portable. Some config files are still saved in My Documents folder in Windows, why is this hardcoded this way?

We have been thinking about it, but it's not that easy for all kinds of techincal reasons. This will not be in the coming release. See also https://github.com/openMSX/openMSX/issues/248 and more recently https://github.com/openMSX/openMSX/issues/1246
The reason it is like this: openMSX uses the concept of 'home directory', which is very commonly used on Linux/UNIX like systems. The current implementation on Windows tried to port that idea to Windows and originates from the Windows 9x/XP days. It is not so easy to throw this concept over board. One thing is that when users would upgraded to a newer version, their old data won't be found anymore. The data migration is not straight forward.

Quote:

Stil issues on european keyboards under Windows, only Windows, most are Alt.Gr Key related. But i can live with it.

Upcoming release will have a new POSITIONAL keyboard mode that can be used to work around this. It works a lot better than the KEY mode.

[quoteAnyway, nice set of new features, thanks a lot for your hard work.

Thanks for your feedback!

By Grauw

Ascended (9072)

Grauw's picture

30-05-2020, 19:56

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

By ren

Paragon (1455)

ren's picture

30-05-2020, 22:21

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

Page 27/42
20 | 21 | 22 | 23 | 24 | 25 | 26 | | 28 | 29 | 30 | 31 | 32