NIghtly builds - keybindings.tcl error

Supporter (11)

16-01-2019, 20:53

Getting the following error / invalid keycode with the nightly builds (including latest 184):

Error while executing D:/Emulation/MSX/OpenMSX/share/scripts/keybindings.tcl
Invalid keycode: CTRL+PAGEUP
    while executing
"bind_default CTRL+PAGEUP cycle_machine"
    (file "D:/Emulation/MSX/OpenMSX/share/scripts/keybindings.tcl" line 8)
    invoked from within
"source {D:/Emulation/MSX/OpenMSX/share/scripts/keybindings.tcl}"
    (in namespace eval "::" script line 1)
    invoked from within
"namespace eval :: [ source $script]"

Last working version is: openmsx-0.15.0-7-g8f7a14971-windows-vc-x64-bin[/]

By Vampier

Prophet (2288)

17-01-2019, 00:22

Thanks Zandig, we switched to SDL2 and quite some things are currently not working. Is your sound working?

the current version is not stable but this will soon change.

By Zandig Slaytanic

Supporter (11)

17-01-2019, 13:56

Thanks for the info.

I can't get it to run anything past the above error. When started with Catapult it switches to the [Status Info] tab and displays the above error message, openmsx.exe is not started.

The last working version is: openmsx-0.15.0-7-g8f7a14971-windows-vc-x64-bin.zip (2018-12-09 20:21 8.2M)

By Manuel

Ascended (15452)

17-01-2019, 16:36

This appears to be a bug in Microsoft Visual Studio, see https://developercommunity.visualstudio.com/content/problem/...

Wouter is going to try to work around it.

By Vampier

Prophet (2288)

17-01-2019, 18:12

Zandig Slaytanic actually openmsx starts but the SDL windows doesn't pop up. You can fix that by 1) switching the renderer 2) start openmsx from the cli 3) use the official openmsx release 0.15.0.

Here is what I posted on facebook:

"A quick reminder that nightly/daily openMSX builds are highly experimental. If things don't work at this time it's because we just switched over to a lot of so called 3rd party libraries and things need to be tweaked/fixed to work with these new components. For example we went from SDL1 to SDL2 in order to have better hardware support (on the host side) for openMSX."

By Manuel

Ascended (15452)

17-01-2019, 19:09

0_15_0-185-gf853aac3b has the workaround implemented. Please try it and tell us whether it works better for you.

Development builds are... development builds and not releases. Just keep that in mind. Thanks for helping testing and giving feedback! It is much appreciated.

By Zandig Slaytanic

Supporter (11)

17-01-2019, 21:59

No worries guys, I know about experimental development builds Been doing this sort of thing for a very long time.
Just tested 0_15_0-185-gf853aac3b....
- The keybinding error is gone however the openmsx window does not pop up when using Catapult.

@ Vampier: That was it! I switched the renderer and the openmsx window appeared, then switched back to SDLGL-PP.

I'll stick with official release - just wanted to give you guys a heads up.

By Grauw

Enlighted (8078)

17-01-2019, 23:27

I think it’s always good to test and run openMSX development releases from time to time. Better to find and report problems early. You can always revert back to the official release. It’s just that now they’re a little more unstable than usual, so the likelihood that you will find issues is higher .

By Manuel

Ascended (15452)

28-01-2019, 22:21

Zandig Slaytanic wrote:

- The keybinding error is gone however the openmsx window does not pop up when using Catapult.

Can you try again with the latest development build? We made a fix in Catapult that should solve this issue.

By Zandig Slaytanic

Supporter (11)

29-01-2019, 18:22

Manuel wrote:

Zandig Slaytanic wrote:

- The keybinding error is gone however the openmsx window does not pop up when using Catapult.

Can you try again with the latest development build? We made a fix in Catapult that should solve this issue.

Just tested openmsx-0.15.0-189-ga1143e0c7-windows-vc-x64-bin.zip and it's back to working properly.

By Manuel

Ascended (15452)

29-01-2019, 19:09

Great, thanks for confirming!