Giant window size (> 10x screen res): Lix opens & closes repeatedly

[Silken Healer]

If you put an irregular value as your Lix window size it opens and closes again. At least I think that this is what this is. Maybe add a warning before making it an regular value?

[Simon]

What exactly did you put? Numbers? Which exact numbers? Negative numbers? Letters? Nothing (empty string)?

Where did you put it: For window size, or for hardware fullscreen resolution?

On which version of Windows are you?

Surprised you get a window at all that is not the fallback size 640x480. But I haven't checked exactly which cases lead to the fallback.

-- Simon

[Silken Healer]

by "irregular" I mean like a value that is bigger then your actual monitor. I havent tried negative numbers letters or nothing. I'm using Windows 10

[Silken Healer]

also it doesn't just close it like continually closes and opens again. It would probably give you a seizure if you had epelepsy

[Simon]

"irregular" I mean like a value that is bigger then your actual monitor.

What exactly is your native monitor resolution?
What exactly did you enter for the window size?

At least on my system*, I can't reproduce your bug by specifying a window bigger than the native resolution. For the window size, I can put 4000 x 2000, which is bigger than my monitor's current and native resolution of 3440 x 1440. I get a window that is bigger than my screen as expected. It won't open and close.

*) 64-bit Linux with X (i.e., not Wayland) and Allegro 64-bit version 5.2.8, running 64-bit Linux Lix 0.10.19.

Lix's mouse cursor will be confined to roughly the top-left quarter, but that's a separate issue.

Neither can I reproduce the bug in Wine 8.21, running Windows Lix 0.10.19 64-bit on that same Linux machine. Difference though: The Lix window with Wine doesn't open as 4000 x 2000, it opens as 3440 x 1440, but still with a border, i.e., not a software fullscreen.

doesn't just close it like continually closes and opens again

Yes, this is a problem, and we should catch that.

At minimum, this bug locks you out of Lix's options menu. To recover, you can erase the options file, but some users won't think of that or find that file.

-- Simon

[Silken Healer]

I can't remember if I just eventually got out of it or deleted and re-obtained Lix. Also It was like a lot bigger like at least about 10 times bigger.

[Forestidia86]

I have tried some big resolutions:

10000x10000 resulted in having no visible window at all. But when looking at tile view it shows a white window.
20000x20000 had it flickering on the task bar (no window visible) and after a while it gave up and defaulted to 640x480 window.

Lix 0.10.18 (binary distro via github), Win 10, native resolution 1920x1080

[Forestidia86]

Have run 20000x20000 resolution with allegro debugging libararies and this problem appears in the allegro.log (excerpt):

Code: [Select]

d3d      D         d3d_disp.cpp:1677 d3d_create_display_internals     [   0.05236] Trying format 0.
d3d      I         d3d_disp.cpp:1353 d3d_display_thread_proc          [   0.05263] Chose a display format: 23
d3d      I         d3d_disp.cpp:1422 d3d_display_thread_proc          [   0.05270] Normal window.
d3d      I         d3d_disp.cpp:786  d3d_create_device                [   0.07843] Using no depth stencil buffer
d3d      D         d3d_disp.cpp:815  d3d_create_device                [   0.10418] trying D3DCREATE_SOFTWARE_VERTEXPROCESSING
d3d      D         d3d_disp.cpp:820  d3d_create_device                [   0.12004] trying D3DDEVTYPE_REF
d3d      D         d3d_disp.cpp:825  d3d_create_device                [   0.15057] trying D3DDEVTYPE_REF|D3DCREATE_SOFTWARE_VERTEXPROCESSING
d3d      E         d3d_disp.cpp:831  d3d_create_device                [   0.17016] CreateDevice failed: UNKNOWN
d3d      I         d3d_disp.cpp:910  d3d_destroy_display              [   0.17025] destroying display 000001428170afd0 (current 0000000000000000)
d3d      D         d3d_disp.cpp:894  d3d_destroy_display_internals    [   0.17030] waiting for display 000001428170afd0's thread to end
d3d      D         d3d_disp.cpp:1703 d3d_create_display_internals     [   0.17034] Resumed after wait.
d3d      I         d3d_disp.cpp:1711 d3d_create_display_internals     [   0.17038] Format 0 failed.
d3d      D         d3d_disp.cpp:1719 d3d_create_display_internals     [   0.17160] d3d_display = 000001428170afd0
d3d      D         d3d_disp.cpp:1720 d3d_create_display_internals     [   0.17165] win_display = 000001428170afd0
d3d      D         d3d_disp.cpp:1721 d3d_create_display_internals     [   0.17166] al_display  = 000001428170afd0
d3d      D         d3d_disp.cpp:1677 d3d_create_display_internals     [   0.17168] Trying format 1.
d3d      I         d3d_disp.cpp:1353 d3d_display_thread_proc          [   0.17195] Chose a display format: 23
d3d      I         d3d_disp.cpp:1422 d3d_display_thread_proc          [   0.17200] Normal window.
d3d      I         d3d_disp.cpp:786  d3d_create_device                [   0.19104] Using no depth stencil buffer
d3d      D         d3d_disp.cpp:815  d3d_create_device                [   0.21447] trying D3DCREATE_SOFTWARE_VERTEXPROCESSING
d3d      D         d3d_disp.cpp:820  d3d_create_device                [   0.22966] trying D3DDEVTYPE_REF
d3d      D         d3d_disp.cpp:825  d3d_create_device                [   0.25002] trying D3DDEVTYPE_REF|D3DCREATE_SOFTWARE_VERTEXPROCESSING
d3d      E         d3d_disp.cpp:831  d3d_create_device                [   0.27007] CreateDevice failed: UNKNOWN
d3d      I         d3d_disp.cpp:910  d3d_destroy_display              [   0.27016] destroying display 000001428170afd0 (current 0000000000000000)
d3d      D         d3d_disp.cpp:894  d3d_destroy_display_internals    [   0.27020] waiting for display 000001428170afd0's thread to end
d3d      D         d3d_disp.cpp:1703 d3d_create_display_internals     [   0.27022] Resumed after wait.
d3d      I         d3d_disp.cpp:1711 d3d_create_display_internals     [   0.27026] Format 1 failed.
....
d3d      I         d3d_disp.cpp:1711 d3d_create_display_internals     [  18.39248] Format 287 failed.
d3d      D         d3d_disp.cpp:1719 d3d_create_display_internals     [  18.39369] d3d_display = 00000142817965c0
d3d      D         d3d_disp.cpp:1720 d3d_create_display_internals     [  18.39378] win_display = 00000142817965c0
d3d      D         d3d_disp.cpp:1721 d3d_create_display_internals     [  18.39380] al_display  = 00000142817965c0
d3d      W         d3d_disp.cpp:1729 d3d_create_display_internals     [  18.39384] All 288 formats failed.
d3d      E         d3d_disp.cpp:1787 d3d_create_display_locked        [  18.39385] d3d_create_display failed.
display  E            display.c:55   al_create_display                [  18.39387] Failed to create display (NULL)
....


[Simon]

It looks as if we have 3 different behaviors here.

• Silken's open-close-open-close-... at unknown resolution, 10 times bigger than native.
  
• Forestidia's white window that won't close, and that you only see in the taskbar, at 10,000 x 10,000.
  
• Forestidia's flickering window that eventually closed, and that you only see in the taskbar, at 20,000 x 20,000. After it closed, Lix produced a window at 640 x 480.
  

If Allegro 5 succeeds in creating the display, it gives me a valid pointer to it, otherwise I get null.

More investigation/problem detection is hard. E.g., we can try to catch case 1 (Silken's case) by looking at the time until the window self-closes, and force 640 x 480 if it closes too quickly. But I have no good ideas yet to prevent the strange windows in cases 2 and 3.

-- Simon

[Dullstar]

Out of curiosity what is the applicable benefit to allowing larger resolutions? I assume something related to making the game display on multiple monitors at once? (I know there's a few games that support that but I've never looked into how exactly that works).

I'm assuming there's a reason that the solution isn't "Just don't let the user do that."

[Simon]

The problem is classifying a resolution as too large.

Reason: Mac Retina displays have many small pixels. And there exist 8K displays with native resolutions of 7680 x 4320. Wikipedia list of resolutions goes up to 16384 x 8640, although that's for multiple monitors.

If you type in, e.g., 12,000 x 8,000, and I get a valid pointer from Allegro for that, what reason do I have to reject it? If we decide that anything over, e.g., 7,000 x 4,000, is only useful in the far future, I can theoretically hardcode a time bomb that allows big resolutions only after 2034. But it still would be speculation.

-- Simon

[Dullstar]

To clarify, by "larger resolutions" I'm considering this any resolution that's larger than the monitor's native resolution. We certainly wouldn't want to reject a resolution that we're not 100% certain shouldn't fit.

But I suppose the "larger than the monitor" part probably isn't the actual problem. Just hazarding a guess: could excessively large resolutions just use too much e.g. VRAM and then the application doesn't know what to do?

From looking at what's been posted here, I do have a possible guess as to why Forestidia got a different behavior than Silken: from other reports we know Silken prefers hardware fullscreen, so it's possible the behavior may be dependent on it.

[Forestidia86]

Maybe there is a possibility to write the current desktop resolution next to the input fields to minimize user errror.

Maybe with get_desktop_resolution

[Simon]

write the current desktop resolution next to the input fields to minimize user errror.
get_desktop_resolution

Yes, this sounds like a great idea: Print the monitor's native resolution as a hint, but allow the user ignore it. The game doesn't try to be smarter than the user then.

get_desktop_resolution is the A4 way; the A5 way appears to be al_get_monitor_info. I'll have to research what to do with multiple monitors.

-- Simon