glx wrote:

Did it work in 0.5.2 ?

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1546

SirkoZ wrote:

Yes - of course.
If set at 640x480, in 0.5.2 and all the releases (apart from 0.4.0 I think) the resolution stayed at 640x480 or any other for that matter.

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1555

SirkoZ wrote:

Perhaps I failed to mention this was in Win2k.

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1592

KUDr wrote:

I am unable to reproduce it on WinXP (both 0.5.3-RC2 & trunk). Can you post your .cfg?

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1650

SirkoZ wrote:

Yes - of course.
Interesting - upon actually opening the .cfg and editing "resolution" to 640, 480 - openTTD started in 640x480 - I then closed it and when I re-ran it, it was again in 1024x768 - 1024, 768 was also written in .cfg. That is in both - trunk and RC2 0-5-3.

Here's the .cfg of my 0.5.3-RC2 and also trunk's.

Attachments

• openttd_0-5-3_RC2.cfg (5.13 KiB)
• openttd_r10411.cfg (6.20 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1651

Rubidium wrote:

Does the attached patch fix this issue?

Attachments

• fs998.diff (0.61 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1743

SirkoZ wrote:

Yes!

That move of shutdown commands to after the config is saved helped a heap! :-)

Now the set resolution, fullscreen or not, stays. Thank you.

Only one more thing though - perhaps should I open a new bug report?
When switching from full screen, with resolution other than desktop's, to window mode, the window doesn't retain its fullscreen size but is stretched to the desktop resolution and it says "other" in resolution box (again - Win2k). The other way around works ok.

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1748

Rubidium wrote:

The only way I can reproduce your 'issue' is by maximizing the window before going fullscreen. Did you do that too?

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1751

SirkoZ wrote:

Nope. Anyways - your patch works for the issue reported in this bug report and I didn't say anything about going fullscreen.

If however I go from full screen (640x480) to 1024x768 (my desktop res) the window doesn't retain its 640x480 size - it's stretched across the whole 1024x768. The other way around works OK.

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1759

Rubidium wrote:

The only reason I can think of why the window would be stretched is the fact that the window's state was "maximized" before going fullscreen. Otherwise the window retains the original window size; none of the code gives pointers to the Windows API calls to go from full screen to windows mode, so Windows cannot change the resolution. Unless the window state was maximized, which only occurs when it was maximized before going full screen. Even with a shutdown of OpenTTD in between.

And the reason I do not commit my patch is because it just hides the real issue; the resolution should not change when going from/to full screen. UNLESS the window was maximized.

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1760

SirkoZ wrote:

First - I never maximise OpenTTD window - ever. Only with ALT+Enter - I enter into 640x480 fullscreen or out of fullscreen to 640x480 windowed.

About your not applying your patch:
Of course the default code can't work - you DO NOT save the config information before shut-down of the OpenTTD window only after - whatever logic that follows. At any rate - the patch works and I don't know bout that second issue why it would pop-up. But it does.

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1761

Rubidium wrote:

I, nor any of the other developers, can reproduce this "issue", unless we maximize the window before going full screen. Furthermore I cannot find a single line that would cause the resolution to change when the window is not in maximized state.

And without a way to reproduce it, it is impossible to fix :( Not to mention that my knowledge of windows is virtually nil.

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1762

SirkoZ wrote:

I am very sorry to hear that - although I don't blame you for not knowing Win... :-)

I'd say - for the time being - with inclusion of your fs998.diff patch - you'd greatly improve the current state of affairs at least
till you or some other developer or even player come up with a better solution. ;-)

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1763

Lupin III wrote:

I can confirm the problem on WinXP with 0.5.3-RC2, r10592, r10641, r10604-ChrisIN and r10717-ChrisIN.

As long as I use the window mode, the selected resolution is remembered for the next start. The windows will always be the same size. (openttd.cfg always contains e.g. "resolution = 800,600")

When I check fullscreen in the options (from a non-maximised game window), the resolution of the monitor is immediatly changed accordingly. But after closing the game, openttd.cfg always contains the current desktop resolution (e.g. "resolution = 1280,1024") instead of the previously selected one, which is then used at the next start of the game (the fullscreen option is correctly remembered). If I manually change the resolution in the config file before starting the game, this resolution is correctly used.

(I never maximised the window in the process.)

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1774

SirkoZ wrote:

Thank you Sansei (Lupin III)!

I hope this get's things moving. Or perhaps this patch is too radical for non-0.6.0?

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1777

Rubidium wrote:

As I said before, it is not a fix, it is an ugly work around which causes fixing the real bug a much lower priority, which is IMO not the way to go.

There must be some common ground for the environments that have this issue, but so far there is no knowledge about that. Without making it reproducable for the developers or someone with a little programming knowledge looking where things go wrong, it is just a very big gamble to fix the bug.

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1778

SirkoZ wrote:

What the blimey are you talking about?!

Just apply the patch till you get a better understanding of the problem - I mean - I already described to you exactly it lacks in behaviour if applied so it's no gamble at all - well - at least not if nothings is broken under other OS-es than Windoze which you can simply ask someone on IRC to test it... Work-around or not - tis good enough for now - for Windoze.

Oh by the way - tell to one of the developers who actually has a Windoze machine to test it in exact way as I and Sansei (Lupin III) have described.

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1781

Rubidium wrote:

So, you say that if I do the following in Windows that I reproduce it (Windows XP, desktop resolution 1024x768, unpatched nightly from a few days ago, VMware)?
- make sure openttd.cfg is writable
- start OpenTTD non-maximised non-fullscreen
- open the "Game Options"
- select 800x600
- click on fullscreen
- close the "Game Options" menu
- close OpenTTD
- restart OpenTTD
== now OpenTTD is started in full screen ==

According to you the resolution is 1024x768. In my version the resolution is 800x600.

Ergo, I cannot reproduce it on Windows. And I've gotten the exact same report from glx, peter1138 and KUDr (the developers that actually use Windows).

It is not only not broken on non-Windowses, it is even not broken on some Windowses. Even though we use the exact same procedure to reproduce it.

So, could you please explain me how to reproduce it on my machine (or glx's, peter1138's or KUDr's machine)?

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1782

SirkoZ wrote:

Ahh - that's just impossible! :-(

I mean you did all the steps. Please - do 1 more try - with the OTTD resolution of 640x480 (native) in full screen.

In any case - the whole thing is that OTTD doesn't write the chosen res. in the CFG...

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1783

SirkoZ wrote:

I get the same results (not written in cfg) with 800x600...

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1784

Rubidium wrote:

In the case of 640x480 it puts "640,480" in the resolution line of openttd.cfg and when coming from full screen the resolution of OTTD is still 640x480.

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1785

Lupin III wrote:

It seems to be something that is really specific to some Windows settings or the hardware (although this would astonish me, as you can't call OTTD a hardware dependent game). But the only thing I consider not standard on my WinXP installation concerning the display is: I'm using the Windows classic look. And the graphics driver is the non official Omega 6.05 driver for an ATI 8500. Ok, clinging to straws now, but maybe there is some similarity?

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1786

Lupin III wrote:

I now tried this in a vmware window, too.
0.5.2 works as expected (as it does on a "real" Windows), 0.5.3-RC2 has the same problem even in the virtual machine. I did not configure any patches, just used the zips from the downloadpage, copied the few required files into the data folder and repeated the steps. 0.5.2 works as expected, 0.5.3-RC2 does not.

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1787

Rubidium wrote:

Odd, very odd. I downloaded the the same binary and could not reproduce the issue. There must be something else that is messing with it.

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1788

Rubidium wrote:

Could one of you apply the attached diff to trunk, give it a test and report what it dumped to the console?

Attachments

• might_get_us_some_useful_information.diff (1.28 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1789

Lupin III wrote:

How can I apply this patch? I tried BuildOTTD, but it always gave me an error message that the patch file is in use by another application (which it isn't, as every other program can read and write the file). I managed to apply the patch manually with "patch -p0 < might_get_us......". While patch worked in the shell environment set up by BuildOTTD, compiling didn't. And Starting the compilation with BuildOTTD always overwrites the changes made by the patch, because it downloads the original version from the svn.

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1817

Rubidium wrote:

I have got absolutely no experience with BuildOTTD. I think it is best when you ask kaan about this issue, as he has written BuildOTTD and should also be able to debug the issue you are having.

As far as I am aware the patch itself is a valid one, but I think BuildOTTD expects the patch to be in a different format, but then again I've got not idea only hunches.

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1818

Lupin III wrote:

What exactly should the patch do? I think I got the game compiled with the patch now. I compiled once directly from trunk with BuildOTTD without the patch, then I build again. Normally BuildOTTD wouldn't do anything then, because all compiled files are up to date. But I applied the patch right after the SVN-check finished and before BuildOTTD started compiling. It seems to have worked as win32_v.cpp got compiled as the only file and then openttd.exe was linked again. But starting the exe doesn't give any output (I started openttd.exe from a console, too). Where would the output be?

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1819

glx wrote:

openttd -d should show you the output

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1820

Lupin III wrote:

Yes, this opens a second textoutput window, where debug messages are appearing, depending on the number behind -d. But there is no output from the patch above appearing (searched for the strings in the diff-file). If the output would only be after clicking the quit button in the game, then there is another problem: the text window immediately closes (it can't be redirected to any file either).

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1821

glx wrote:

Run convert.exe in the same dir as openttd.exe and it will convert it to a console app, so you will be able to redirect output.

Attachments

• convert.zip (3.55 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1822

Lupin III wrote:

Thanks, no I can capture the output. But there is non from the diff. I'm sure it is compiled into the binary, as I found the strings from printf in openttd.exe. Any ideas?

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1823

Rubidium wrote:

The idea was that you run the binary and "reproduce" the issue of this bug, i.e. go to full screen and close and restart openttd.

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1824

Lupin III wrote:

I tried all that, but there is no output from the diff above. I get the debug messages (YAPF, sprites, ...), but no "csc: # # , # # " or "cr: # # , # # ". So the lines from the diff never seem to get executed.

Btw I managed to compile OTTD within a cygwin environment (but without png and freetype support). Even when I start the game from there the same problem exists. It's really astonishing how others can't reproduce this bug while I can observe it on WinXP, WinXP in vmware and in a cygwin environment.

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1826

Rubidium wrote:

Cygwin isn't that different from Windows; it still uses all the Windows libraries for GUIs. The difference between the vmware and non-vmware version might not be there either as I assume you're running the same Windows installation in VMware, that is: installed from the same CD.

And what does it show if you run it with the attached patch?

Attachments

• might_get_us_some_useful_information.diff (1.26 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1827

Lupin III wrote:

Now I get output. Here are two logfiles.

In one I started in 1024 windowed mode, selected fullscreen from the options (1024 fullscreen), quit the game.
In the other I started 1280 fullscreen, selected 1024 as resolution, quit the game.

Both files have an "csc 1280" at the end, which I shouldn't be there in my opinion.

If you need another sequence, tell me what to try.

Attachments

• logfile_1024w-1024f-q (38.31 KiB)
• logfile_1280f-1024f-q.log (35.19 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1828

glx wrote:

Next time add a .txt extension ;)

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1829

glx wrote:

Could you try the attached diff, tell us if it works or not and report what it dumped to the console?

Attachments

• another_try.diff (0.62 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1832

Lupin III wrote:

No change.
Again like above:

1. start windowed in desired resolution, switch to fullscreen, quit
2. start fullscreen (desktop res), switch to desired resolution, quit

Attachments

• logfile_1024w-1024f-q.txt (0.14 KiB)
• logfile_1280f-1024f-q.txt (0.14 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1835

Rubidium wrote:

I fear we need to get that particular VMware image that was used to be able reproduce the bug. We are basically out of ideas what might be the problem and the few hunches we had did not get any (real) result.

Is there any way you can provide the image to us?

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1836

Lupin III wrote:

I don't think so, it's an over 10GB image.

But I tried other things by adding some printfs to win32_v.cpp and openttd.cpp. I post the log right here since it's easier to explain. I changed win32_v.cpp (which also still contains the patch from above) and openttd.cpp. The latter mostly to track where the change of resolution occurs before saving the config. The numbers are the contents of "_cur_resolution[0]" and "_cur_resolution[1]" at the given time. Again the game is started in 1280 fullscreen, then changed to 1024 fullscreen and finally closed.

"win32_v # WndProcGdi # case WM_....." are printfs at the beginning and end of the matching case of the switch statement in the WndProcGdi function. I did this because there the value of _cur_resolution is copied to/from _bck_resolution. But this didn't seem to be a problem the problem as it is only used when maximizing the window, not for fullscreen.

More important is the part in "VideoDriver_Win32::Stop". After "DestroyWindow" is called the resolution has changed (see from line "VideoDriver_Win32::Stop # 3" and "... # 4"). I couldn't split it up any further at this point, because I could find a "DestroyWindow"-function in the source (is this a Windows function?).

win32_v # WndProcGdi # case WM_SIZE: 1280x1024
win32_v # WndProcGdi # case WM_SIZE: 1280x1024
active 1, minimize 0, fullscreen 1
active 0, minimize 0, fullscreen 1
win32_v # WndProcGdi # case WM_DESTROY: 1280x1024
win32_v # WndProcGdi # case WM_DESTROY: 1280x1024
win32_v # WndProcGdi # case WM_SIZE: 1280x1024
win32_v # WndProcGdi # case WM_SIZE: 1280x1024
active 1, minimize 0, fullscreen 1
openttd # before _video_driver->Stop(): 1024x768
win32_v # VideoDriver_Win32::Stop # 1: 1024x768
win32_v # VideoDriver_Win32::Stop # 2: 1024x768
win32_v # VideoDriver_Win32::Stop # 3: 1024x768
active 0, minimize 0, fullscreen 1
win32_v # WndProcGdi # case WM_SIZE: 1024x768
win32_v # WndProcGdi # case WM_SIZE: 1024x768
win32_v # WndProcGdi # case WM_DESTROY: 1280x1024
win32_v # WndProcGdi # case WM_DESTROY: 1280x1024
win32_v # VideoDriver_Win32::Stop # 4: 1280x1024
win32_v # VideoDriver_Win32::Stop # 5: 1280x1024
win32_v # VideoDriver_Win32::Stop # r: 1280x1024
openttd # after _video_driver->Stop(): 1280x1024
opentdd # if (save_config): Saving CFG...

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1838

glx wrote:

Please attach your patch so I can try it. I'd like to compare the outputs.

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1839

Rubidium wrote:

Can I conclude from your report that WM_SIZE is called from DestroyWindow (i.e. after DestroyWindow was called but before it returned)?

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1840

Lupin III wrote:

Rubidium: yes, it seems so.

I never created a patch file (always applied them), so I hope this is working.

Attachments

• patch.diff (3.37 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1842

glx wrote:

Hehe, will be easier for you to use "svn diff" next time :) (and for us too ;) )

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1843

Rubidium wrote:

If I read the documentation right WM_SIZE shouldn't be called when destroying a window; it says it calls the window proc with two other constants, but not with WM_SIZE. So somehow Windows is not behaving as it is documented to behave.

Could you check how your Windows reacts on the attached patch?

Attachments

• yat.diff (0.97 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1844

Rubidium wrote:

It's likely that the patch won't compile; you just need to replace the return with return 0.

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1846

Lupin III wrote:

"replace the return with return 0" Already did that ;-)

Other resolitions are saved with this patch, but the behaviour is a little complicated to describe now. If I start the game in 1280f and switch to 1024f the resolution changes, but the size of the game window doesn't. It is still 1280 although you can't see parts of it because they are off screen (and the starting menu is off center for example). The same goes the other way round from 1024f to 1280f, the resolution changes to 1280 but the game stays 1024. The windows desktop can be seen below and right of the game. The game still is in fullscreen mode, there are no window controls.

Second: If I start the game 1280f, switch to 1024f and quit, the config will still contain 1280. The same the other way round again. Starting 1024f, switching to 1280f, quitting, gives 1024 in the cfg. So the game size, which stays the same with this method as described above, is saved.

To actually get the right resolution saved, you have to changed to windowed mode, change the resolution, then switch to fullscreen again. But with this method you can't set a resolution bigger than the desktop resolution, actually not even the desktopn resolution itself. Windows doesn't allow a window that's larger than the desktop minus the window title bar. So if I select 1280x1024 in window mode the, the resolution in OTTD switches to "other" and actually gets set to 1280x1009 and saved. At this point the game will always start in window mode, because this is an invalied fullscreen resolution.

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1847

glx wrote:

Ok let's get some more output :)

Attachments

• some_more_info.diff (3.53 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1848

Lupin III wrote:

Done!

Btw. Thanks for all this effort for such a little bug. I hope there aren't any other serious things held back!

Attachments

• logfile_1024w_1024f_q.txt (1.13 KiB)
• logfile_1280f_1024f_q.txt (1.13 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1851

glx wrote:

And another try to fix this bug :)

Attachments

• try_again.diff (0.45 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1854

Lupin III wrote:

Yes, this did it! The game starts in the resolution that was used when closing it. I see what the fix is, but any idea why this only happens on certain Windowses? Maybe the language? All versions I used to test were german versions (but different SP Levels).

This comment was imported from FlySpray: https://bugs.openttd.org/task/998#comment1855

glx closed the ticket.

Reason for closing: Fixed

in r10399

This comment was imported from FlySpray: https://bugs.openttd.org/task/998