Bjarni wrote:

odd. 1024x768 works here when monitor resolution is set to 1280x800.

Is this something that happens every time?

This comment was imported from FlySpray: https://bugs.openttd.org/task/458#comment746

PinguTux wrote:

Yes, the crash happens everytime I change the resolution.

I have also reproduced the crash with OpenTTD 0.4.8 and the current trunk (r7648)

This comment was imported from FlySpray: https://bugs.openttd.org/task/458#comment748

Bjarni wrote:

try making a clean install (only 0.5.0-RC1 and the TTD grf files and sample.cat) and see if this continues. Do not reuse anything else, specially not openttd.cfg.

This comment was imported from FlySpray: https://bugs.openttd.org/task/458#comment749

PinguTux wrote:

I hava downloaded "openttd-0.5.0-RC1-osx.dmg" from openttd.org, copied the original grf files to data, started and changed the resolution and it still crashes ...

Backtrace:
0 org.openttd.openttd 0x000060b1 0x1000 + 20657
1 org.openttd.openttd 0x0000a92d 0x1000 + 39213
2 com.apple.Foundation 0x925f0207 _nsnote_callback + 230
3 com.apple.CoreFoundation 0x908543f6 __CFXNotificationPost + 345
4 com.apple.CoreFoundation 0x9084bc11 _CFXNotificationPostNotification + 600
5 com.apple.Foundation 0x925e8860 -[NSNotificationCenter postNotificationName:object:userInfo:] + 121

But when I change the dock to auto-hide and then set the resolution it just barely fits on the screen and shows corruption at the window title (see attachment) but it doesn't crash. When I restart OpenTTD it works without corruption or crash, with and without dock auto-hide.

Attachments

• ottd-window-corruption.png (250.34 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/458#comment750

Bjarni wrote:

Well, you do have 800 pixels in your screen height. You want to use 768 for the window. Then there is the menu from the OS and the window "top". 800 - 768 = 32, which leaves 16 for each. I can't remember how big they are (zoom in on the screenshot to tell if you like), but I would recommend starting in 640x480 and drag the window to the size you want (something like 1280x700). Alternatively you can use fullscreen where 1280x800 is supported. In fact fullscreen is always recommended unless you want to multitask while playing because the window mode use more CPU power (and hence battery lifetime).

As for the crash... it shouldn't happen, but it's kind of hard to do anything about since it just works here (with the corruption, but clearly nothing can be done about that one)

This comment was imported from FlySpray: https://bugs.openttd.org/task/458#comment751

PinguTux wrote:

OK, thank you for the explanation! Bug can be closed now.

This comment was imported from FlySpray: https://bugs.openttd.org/task/458#comment752

Bjarni wrote:

well, it should reject switching to a resolution where it can crash/corrupt the window, so even though it's a user input error (the request is not valid on the hardware), the game should catch that condition and prevent it from being done.

This comment was imported from FlySpray: https://bugs.openttd.org/task/458#comment753

Darkvater wrote:

Will we get a fix for this sometime in the near future?
On win32 at least a list of default resolution is queried and found from the OS.
A non-crashing fix would be great though, cause right now it looks really amateuristic.

This comment was imported from FlySpray: https://bugs.openttd.org/task/458#comment798

Bjarni wrote:

The OS generates the list of available resolutions. I don't really know how to solve this. It will need some investigation. I can't set a timeframe on this, but since I'm not going to look at GUI stuff at least withing the next few weeks, I would say that this is not solved for 0.5.0. This bug appears to have been introduced in 3182 (or 0.4.5) and since nobody complained until now, I guess it's not that urgent.

This comment was imported from FlySpray: https://bugs.openttd.org/task/458#comment799

Darkvater wrote:

I disagree with that. A crash is always and in any form unwanted. An excuse that nobody has experienced it due to the specific circumstances does not mean it shouldn't be fixed in a reasonable timeframe.

This comment was imported from FlySpray: https://bugs.openttd.org/task/458#comment819

matthijs wrote:

A friend of mine tried on his MacBook Pro with Core 2 Duo. No crashes. He tried switching to 102x768 in various system resolutions, all worked fine. He was running MacOS 10.4.10. Perhaps this has been fixed in MacOS?

Does the original bug reporter still have the problem?

This comment was imported from FlySpray: https://bugs.openttd.org/task/458#comment1473

PinguTux wrote:

Bug does still occur with current trunk (r10362) on Mac OS X 10.4.10.
When I switch to a Mac OS X resolution of 1024x768 I can not select the resolution 1024x768 in OpenTTD anymore (Windowed Mode).
If I click on the maximize button the resolution 1280x675 will be saved in openttd.cfg

Backtrace:
0 org.openttd.openttd 0x0018287c QZ_WindowBlitIndexedPixelsToView32(unsigned, unsigned, unsigned, unsigned) + 148 (cocoa_v.mm:1005)
1 org.openttd.openttd 0x0018299e QZ_WindowBlitIndexedPixelsToView(int, int, int, int) + 70 (cocoa_v.mm:1030)
2 org.openttd.openttd 0x00182c05 QZ_DrawWindow() + 301 (cocoa_v.mm:1115)
3 org.openttd.openttd 0x00183744 QZ_Draw() + 38 (cocoa_v.mm:1613)
4 org.openttd.openttd 0x0018680e QZ_GameLoop() + 556 (cocoa_v.mm:735)
5 org.openttd.openttd 0x00186aff -[OTTDMain applicationDidFinishLaunching:] + 17 (cocoa_v.mm:1853)

gdb says:
# 0 0x0018287c in QZ_WindowBlitIndexedPixelsToView32 (left=0, top=0, right=1024, bottom=768) at /Users/philipp/devel/openttd-trunk/src/video/cocoa_v.mm:1005

This comment was imported from FlySpray: https://bugs.openttd.org/task/458#comment1477

matthijs wrote:

I see you use gdb, perhaps you could try to find the exact cause of tthe problem with gdb? If you'd drop by on IRC (# openttd on oftc) I (or another developer) will be happy to debug this together.

This comment was imported from FlySpray: https://bugs.openttd.org/task/458#comment1480

PinguTux wrote:

Today I had some time for debugging.

The problem was that _cocoa_video_data.qdview (view) was larger than _cocoa_video_data.window (window). Because of this the array offset (cocoa_v.mm:1216) resulted in a negative value. I fixed this (with my small Cocoa/C knowledge) by ensuring that "frame height - title bar height" is always larger or equal to the view height. This also fixes the corruption problem (see screenshot above).

I hope this helps a little for fixing this bug.

Attachments

• fix-crash-bug.diff.txt (1.02 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/458#comment1517

Bjarni closed the ticket.

Reason for closing: Fixed

added your diff (in a slightly modified version) in revision 10410

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