OpenTTD

Tasklist

FS#5889 - [OS X] Toggling animation in the options menu while paused makes things go black

Attached to Project: OpenTTD
Opened by Simon Smith (Simons_Mith) - Friday, 31 January 2014, 00:37 GMT
Last edited by frosch (frosch) - Saturday, 11 March 2017, 12:54 GMT
Type Bug
Category Core
Status Closed
Assigned To No-one
Operating System Mac OS X
Severity Low
Priority Normal
Reported Version 1.4.0-beta3
Due in Version 1.4.0
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I was mucking about with visibility settings for town names, station names, animations and detail settings in the Options menu. (While paused) Toggling animation while paused seemed OK, but when I tried to put things back all the game windows and many game graphics just went black!

Not quite sure which order I turned things on and off in, but you're left clicking in the dark to restore normality.

Low priority, because who mucks about with those settings? And it seems there's an easy workaround - unpause.

However, /why are those settings even on the menu bar in the first place/? Shouldn't they have a control window like the transparency window? It's quite a big UI inconsistency to have these settings displayed and controlled from there; nothing remotely similar is done for any other game control!
This task depends upon

Closed by  frosch (frosch)
Saturday, 11 March 2017, 12:54 GMT
Reason for closing:  Fixed
Additional comments about closing:  in r27774. Thanks JGR
Comment by Remko Bijker (Rubidium) - Sunday, 09 February 2014, 18:47 GMT
I can't reproduce this under Linux; it might be an OS X specific bug.
Comment by fonsinchen (fonsinchen) - Sunday, 23 February 2014, 14:35 GMT
MJP writes in  FS#5867  that adding a GfxInitPalettes to CheckBlitter fixes it:

> And what about that?
>
> void CheckBlitter()
> {
> if (!SwitchNewGRFBlitter()) return;
> ClearFontCache();
> GfxClearSpriteCache();
> GfxInitPalettes(); // fix  FS#5889 
> UpdateCursorSize(); // fix  FS#5867 
> }
Comment by fonsinchen (fonsinchen) - Sunday, 23 February 2014, 16:15 GMT
I can reproduce part of this on Mac OS 10.4. There is an additional precondition: You must use zBase or possibly something else 32bit. And simply adding GfxInitPalettes() doesn't help.
Comment by Simon Smith (Simons_Mith) - Sunday, 23 February 2014, 20:43 GMT
GfxInitPalettes() successfully fixes the problem I initially saw, but you're right about 32bit graphics. I see that problem even on build 26368, and what's more unpausing does NOT make it clear up. I'm on MacOS 10.5.8.
Comment by fonsinchen (fonsinchen) - Sunday, 23 February 2014, 22:22 GMT
If I add that GfxInitPalettes() the effect actually changes in that the windows I click on become normal again. Without it they stay black. A MarkWholeScreenDirty() after the new GfxInitPalettes() does not help with that.
Comment by fonsinchen (fonsinchen) - Sunday, 23 February 2014, 22:40 GMT
The fact that the Mac OS video driver doesn't do threaded drawing and skips QZ_CheckPaletteAnim when paused has nothing to do with it. Moving that code around to be also run when the game is paused, doesn't change anything.

The effect only occurs when switching full animation on, not when switching it off.

When the game is not paused, all windows go black, too, but they recover bit by bit, as they are triggered to be redrawn. Also, pausing the game recovers all windows at once, but starting a game that was paused when the blitter was switched, only starts the bit by bit recovery.
Comment by Transportman (Transportman) - Wednesday, 14 May 2014, 14:30 GMT
I can reproduce this with the latest nightly (r26585) on Windows 8.1 64 bits, with OpenGFX, NightGFX and zBase. It happens when turning full animation ON. I haven't set a specific blitter in my openttd.cfg-file, but when I set one, the black screen does not happen.
Comment by andythenorth (andythenorth) - Wednesday, 16 September 2015, 19:17 GMT
I can reproduce this in OS X 10.9 and 10.10 using 8 bit or 32 bit blitters.
Comment by J G Rennison (JGR) - Tuesday, 07 March 2017, 23:51 GMT
The attached patch fixes this bug, which is caused by the animated blitter's palette not being initialised until the first call to PaletteAnimate, such that the first screen refresh is drawn with an uninitialised palette.
Comment by frosch (frosch) - Saturday, 11 March 2017, 12:37 GMT
When checking which video drivers call PaletteAnimate:
sdl_v is the only one which calls PaletteAnimate in VideoDriver_SDL::CreateMainSurface. None of the other video backends have comparable code.

This code was added in r23978.
Comment by frosch (frosch) - Saturday, 11 March 2017, 12:53 GMT
Reverting r23978 also makes this issue reproducible with SDL. JGR's fix then fixes it again,

So, I reverted r23978 and committed JGR's new fix, so that backends work the same now.

Loading...