Please help testing upcoming openMSX release!

Page 47/50
40 | 41 | 42 | 43 | 44 | 45 | 46 | | 48 | 49 | 50

By ren

Paragon (1636)

ren's picture

27-08-2020, 22:54

Are you running WebMSX in Chrome? Chrome (Chromium) does a pretty good job on vsync, which WebMSX hooks onto. Firefox (a bit) less so. Interesting: https://www.vsynctester.com/

So it seems I get best (sync) performance out of openMSX when I also enable vsync at driver level (instead of leaving it on 'auto'/application controlled), but on your laptop you can't control that right? I'll have a fresh look tomorrow.

By ren

Paragon (1636)

ren's picture

29-08-2020, 11:26

So had a look.. (1080p @ 60Hz) Findings are pretty much like the last findings I posted here, so that means for me I get the best results (steady smoothness) when I turn vsync on at driver level (program 3D settings). Doesn't seem to matter then whether I have openMSX's vsync setting on or off.

But only good smoothness in FS. BUT with the net stop uxsms trick windowed becomes as smooth as FS.

So all other variations of settings vary in outcome, mostly it's a matter of being smooth for a while, then the occasional stutter, stutter may prolong a bit, becomes smooth again etc. Pausing the emulation, of ffwd a bit may help to get sync/fluidity again...

Indeed, WMSX is pretty smooth throughout. An odd thing is that in FF (Chrome is fine) it detects the native vid frequency (see browser console) as 60 Hz even when I have the display @ 50 Hz. (Should double check that with a clean FF profile.)

I might still try a custom resolution with a freq close to 59.92274340431231 Hz to see if results may improve (my 50 Hz results did seem to improve using a custom res @ 50.159 Hz ..)

@mzoran: how is blueMSX for you in this regard? You could also try RetroArch w/ the blueMSX core. That does seem to do a pretty good job keeping things synced/smooth. Audio is synced as well (not sure how openMSX handles things in this regard, I do wonder sometimes about the variation I see in the fps reported by the fps indicator) , and I couldn't seem to remedy (very) slight audio crackles (sync related?) every now & then when testing FAC IV.

Another question: do you also run a real MSX? How do you feel is the difference in input lag (on your game) between your real MSX and the various emulators? Thanks :)

By mzoran

Expert (102)

mzoran's picture

31-08-2020, 15:36

Thanks for testing. I did try on another computer with Win 10 and Catalyst drivers and created a profile for openMSX and activated vsync permanently. In full screen it does start a big chunky but settles afterwards. Since I know of now way to disable Aero on Win10 as there is no uxsms service I will just have to live with this.
Short summary: enable vsync in drivers and use same frequency on the monitor as in openMSX
use openMSX for development and excellent MSX hw support
use webMSX inside Chrome for best smoothness if you can't kill off various Windows features that affect display

By Manuel

Ascended (17301)

Manuel's picture

08-12-2020, 21:03

So, we might be releasing an update for openMSX soon. Can you guys please give the latest development build a spin and tell us whether everything is working as you expect?
See http://openmsx.dev/

By ericb59

Paragon (1030)

ericb59's picture

09-12-2020, 10:08

Not 100% sure , but it seems Debugger is not working with MacOS Big Sur. Even after re-installation of QT5

By Manuel

Ascended (17301)

Manuel's picture

09-12-2020, 10:47

Can you be a bit more specific on what is not working exactly? What are you trying to do and what is happening exactly?

By Sylvester

Champion (492)

Sylvester's picture

09-12-2020, 11:56

I have the same problem, the debugger starts (but no window appears), then the spinner appears and it gets the state 'Application not Responding'. After that I need to force kill it.
Also reinstalled QT5, but same behavior, the console log only gives:

Date/Time:        2020-12-09 11:50:44.880 +0100
End time:         2020-12-09 11:52:15.383 +0100
OS Version:       macOS 11.0.1 (Build 20B50)
Architecture:     x86_64h
Report Version:   32
Incident Identifier: 461A7B8B-1654-424B-8937-C3451333F956

Data Source:      Microstackshots
Shared Cache:     1E362DBC-F66C-3135-BCA0-C1BBAE12BC7C slid base address 0x7fff20005000, slide 0x5000

Command:          openmsx-debugger
Path:             /Applications/OpenMSX_debugger.app/Contents/MacOS/openmsx-debugger
Identifier:       org.openmsx.openmsx-debugger
Version:           ()
PID:              2882

Event:            cpu usage
Action taken:     none
CPU:              90 seconds cpu time over 91 seconds (99% cpu average), exceeding limit of 50% cpu over 180 seconds
CPU limit:        90s
Limit duration:   180s
CPU used:         90s
CPU duration:     91s
Duration:         90.50s
Duration Sampled: 81.38s
Steps:            54

By Sylvester

Champion (492)

Sylvester's picture

09-12-2020, 19:22

WorkAround to start openmsx.net debugger version on MacOs Big Sur: type export QT_MAC_WANTS_LAYER=1 and run openMSX from the terminal, then it starts.

Ok, I just compiled the openMSX Debugger and then it starts again Smile Only got some warnings during linking:

Linking openmsx-debugger...
ld: warning: dylib (/usr/local/Cellar/qt/5.15.2/lib/QtCore.framework/QtCore) was built for newer macOS version (10.13) than being linked (10.7)
ld: warning: dylib (/usr/local/Cellar/qt/5.15.2/lib/QtXml.framework/QtXml) was built for newer macOS version (10.13) than being linked (10.7)
ld: warning: dylib (/usr/local/Cellar/qt/5.15.2/lib/QtWidgets.framework/QtWidgets) was built for newer macOS version (10.13) than being linked (10.7)
ld: warning: dylib (/usr/local/Cellar/qt/5.15.2/lib/QtNetwork.framework/QtNetwork) was built for newer macOS version (10.13) than being linked (10.7)
ld: warning: dylib (/usr/local/Cellar/qt/5.15.2/lib/QtGui.framework/QtGui) was built for newer macOS version (10.13) than being linked (10.7)

But some things are wrong, the code view is missing the line numbers, and the main memory table is messed up:

By ericb59

Paragon (1030)

ericb59's picture

09-12-2020, 20:13

arf... too late ... Sylvester answered ...

By sdsnatcher73

Paragon (1363)

sdsnatcher73's picture

09-12-2020, 20:50

I wondered before why openMSX for macOS targets 10.7 that seems such an ancient OS. I think if you change the target to 10.13 (even for your private build) it will probably work fine again. Another option may be that Qt5 is handled as a 3rd party external during the build (and as such also build with 10.7 as target).

Page 47/50
40 | 41 | 42 | 43 | 44 | 45 | 46 | | 48 | 49 | 50