Please help testing upcoming openMSX release!

Page 33/42
26 | 27 | 28 | 29 | 30 | 31 | 32 | | 34 | 35 | 36 | 37 | 38

By DrWh0

Paladin (785)

DrWh0's picture

12-06-2020, 22:56

Thanks Manuel

I tested multiple configurations and I detected exactly how to reproduce the error on a clean configuration:

The drag and drop error occurs in Windows when you run the emulator from a drive different from C:

In other words:

If I drag the file with the emulator installed in any folder in drive C: it works properly (no matter where the zip file is located). Everything is ok

But...

If I drag the file with the emulator installed in any folder in drive D: -for example- it does not work (no matter where the zip file is located)

The emulator then drops a "Don´t know how to handle (zip name)...

Sorry for not being more specific before and don´t test the emulator on multiple drives (I should have supposed it, but the kind of error message confused me)

By Manuel

Ascended (16632)

Manuel's picture

12-06-2020, 23:25

Can you show a screenshot? Does it show the full path of the zip file?

Does this work:
1. open command prompt where openMSX.exe is
2. openmsx.exe D:\whatever\the\path\is\of\your\file.zip

As I don't run Windows, it's a bit hard to debug without your help...

By DrWh0

Paladin (785)

DrWh0's picture

12-06-2020, 23:40

I run in dual boot enviorement so I can test both Hannibal

I tested anyway and it works via commandline in fact the emulator load the roms via menu without problems, the issue only appears in drag and drop mode with emulator already running (I run the emulator, and drag a zip onto emulator windows).

Drag and drop the file over the exe from explorer always worked.

It seems an error in TCL script (probably) parsing the object.

By Manuel

Ascended (16632)

Manuel's picture

12-06-2020, 23:50

That's the thing: the file is parsed by the same code that parses the command line arguments... So I would expect it to refuse then also on the command line.

What kind of file is it? A zipped ROM file? What is the full path?

By Manuel

Ascended (16632)

Manuel's picture

13-06-2020, 00:44

OK, I could reproduce it with Wine Smile I think I fixed it. Can you try the new build 0.15.0-851-gd6d80cf62?

By DrWh0

Paladin (785)

DrWh0's picture

13-06-2020, 01:23

I have just downloaded the new binaries and problems is FIXED

Thank you very much Manuel Smile

By Manuel

Ascended (16632)

Manuel's picture

13-06-2020, 10:28

Thanks a lot for testing, reporting and confirming!

By ren

Paragon (1455)

ren's picture

17-06-2020, 18:27

Grauw wrote:

Can some people play this ROM on the latest openMSX development build, and walk up and down for a while to check if the scrolling is smooth? For example, a smooth scroll vs. a choppy scroll.

Test both in windowed and full-screen, first with set sync_to_vblank_mode immediate and then with set sync_to_vblank_mode sync, and state your experience on the smoothness with both settings, and provide some details on your system like OS and graphics card.

Had a quick look, 0.16 def. seems worse here (windowed & fullscreen).
I reported some issues/findings regarding vsync & 'threaded optimization' (Win7+Nvidia) around 0.14 time. Those settings still seem relevant, but I'll have to investigate some more..

@Manuel and/or mth: could having exclusive FS mode again be an option (so a fullscreen mode setting: windowed or exclusive)?

Note to other ppl who might go testing: the command is set vsync now.

By Manuel

Ascended (16632)

Manuel's picture

17-06-2020, 19:00

Can you explain how it performs with and without vsync?

By ren

Paragon (1455)

ren's picture

18-06-2020, 13:37

Having a look ATM. Kinda a bitch to test, as there are quite some variables Smile

I'll stick to windowed testing, as probably it won't matter a lot since it's a windowed FS mode now?

Should I set triple buffering on or off? One of those settings I'm never sure about Smile

To sum the 0.16 changes up, if I get it right:

  • due to the move to SDL2 this vsync thing became available,
  • default setting is 'off';
  • Grauw noticed there's a loss in smoothness however (when 'off');
  • (I noticed pre-0.16 it makes a difference when I set vsync to a hard 'off' in the driver settings);
  • turning vsync on should improve smoothness (when machine & monitor refresh match), but will also lead to increased latency.

Some things:

  • is there any vsync applied for PAL machines? (And would that work, you think, e.g. when running @ 100hz refresh?)
  • I think it would be nice to have some (debug) info available so one can verify which vsync mode is active (none, adaptive or full).

Some things I have noticed:

  • 0.16 seems to require a (little) bit more CPU (question is how much of that is due to (changed) video processing);
  • going back from FS to windowed the window doesn't restore properly: it's outside of the top left corner, with part of the window chrome (inc. the titlebar) out of reach.
Page 33/42
26 | 27 | 28 | 29 | 30 | 31 | 32 | | 34 | 35 | 36 | 37 | 38