102.2.2 pak64 Simutrans flickering after losing focus

[unnamedrand]

This isn't a nightly build, however I don't see the bug in a search.

Simutrans 102.2.2 (Gentoo Linux official ebuild)
Awesome Window Manager
xcompmgr (though no trans settings set for simutrans)*
NVidia 8600 using nvidia-drivers-260.19.29 (this problem occures with other drivers, as well)

Most of the time when simutrans loses focus, it begins to flicker. This doesn't occure when I switch to a second monitor (WinKey+Ctrl+j), however when I move the mouse to a new window or move focus to another window via keyboard, it (ususally) does. The flickering is generally steady and blocks input sometimes (click registering on a blank/black screen?), requiring a restart of the game to fix this issue. This also will produce blank screenshots sometimes as I found earlier today.

*) My setup uses a variety of transparency settings for diffrent apps set using c.opacity. I can not see how this would affect simutrans, but am including it just in case

[prissi]

Since simutrans relies on SDL, look up if there is a problem there. Moreover, simutrans uses 16 bit bitmaps, which some drivers do not support porperly even though they claim it. Try a new version of SDL might help with this.

[unnamedrand]

Currently updating libsdl. However, I feel a need to ask why some drivers don't support 16-bit graphics properly. Do you have any clue?

[unnamedrand]

Updated to libsdl 1.2.14-r4 (-r4 being the ebuild revision),enabled the xv USE flag, and recompiled simutrans. Apparently no problems. Previous version: 1.2.13-r1 (w/o xv support).

Thanks. This seems to have sorted out the problem

EDIT:

This doesn't seem to have resolved the issue. The flickering continues. I noticed it when switching back to the previous screen. I have restarted the game and I am trying to see if I can reproduce the problem reliably.

EDIT #2

Ok, here is what I am experiancing:
1) Unable to change game speed. The button is pressed, but the game speed won't change.
2) No flickering with T=1.00 (that I notice). Pressing fast-forward (|>|>) causes flickering and seems to have no affect on game speed. T seems to switch between T~0.00 and T=2.?? randomly.

EDIT #3

3) Loss of cursor icon. The cursor's functionality remains, but the graphic depicting the current function does not appear until after left clicking
4) Flickering continuing as before, though not it doesn't apear to occure constantly
5) Pausing causes constant flickering.

[prissi]

Ok, this looks very much like you overloaded the game engine or have a too large window size. If fast forwards cannot exceed 2x normal, you screen update will become slow and the game engine might lag. Thus you will see a partly black screen until the next time events are processes.

I still would recommend to try a nightly, as usually we do some optimisations in the nightlies. YOu can also gain something by not using a DEBUG-compile.

[unnamedrand]

Ok, this looks very much like you overloaded the game engine or have a too large window size.

1680x1050 window size, though I do use twinview (2620x1050 total size).

I'll look into the nightlies.

[unnamedrand]

After getting sim-linux64 installed, things seem to improve. There is a sluggishness when running full screen, and a delay when changing the speed, however this seems to resolve most issues I was having (including a forgotten problem with Follow Me slowing the game down considerably)

[prissi]

If you use a 64 bit system, using 32 bit version should be 5-15% faster, especially with large screen sizes (as it contains assembler optimized drawing routines for images).

[sdog]

Can you try if the flickering still persists without using twin-view?

I had massive flickering for maximized windows on one screen when using twin view under gnome. In single screen mode the flickering was gone. Also not having maximized windows prevented flickering too.

[unnamedrand]

Performance did improve with a smaller window. I left the game running overnight and return to no apparent problems this afternoon.

As for 32 vs. 64 bit, I would prefer to use 64 since that is native for the CPU. I can appreciate optimizations for 32, however I believe there is additional overhead for running 32 bit programs in a 64 bit enviroment. I will double check this, but if there is, then that would negate part or all of that 5-15%.

@sdog:

Turning off Twinview would require restarting X every time I wanted to play simutrans and eliminate the reason I use two screens (namely, so I can keep up with a larger amount of data without swapping workspaces constantly).

If there is an issue with performance under Twinview, then this should probably be addressed.

Some additional info:

Watching conky while running Simutrans shows my CPU remaining at 1.0 GHz (max speed is 2.5) and disk IO remaining at a negligible level even with flickering problems. I am curious how simutrans handles screen drawing and elapsing time now. Is this done every time the screen is drawn?

[inkelyad]

I think it old textur_resize event problem. Can you test it?
Run simutrans from terminal command prompt. When simutrans flicker you wil see something like that:

Code Select Expand


expose: x=1676, y=511
textur_resize()::screen=0x8d91ed8
expose: x=1676, y=511
textur_resize()::screen=0x8d91ed8
expose: x=1676, y=511
textur_resize()::screen=0x8d91ed8
expose: x=1676, y=511
textur_resize()::screen=0x8d91ed8
expose: x=1676, y=511
textur_resize()::screen=0x8d91ed8
expose: x=1676, y=511
textur_resize()::screen=0x8d91ed8
expose: x=1676, y=511
textur_resize()::screen=0x8d91ed8
expose: x=1680, y=1050
textur_resize()::screen=0x8d91ed8
expose: x=1676, y=511
textur_resize()::screen=0x8d91ed8

'fullscreen' hotkey of Awesome fix problem.

[unnamedrand]

I think it old textur_resize event problem. Can you test it?
Run simutrans from terminal command prompt. When simutrans flicker you wil see something like that:

Code Select Expand


expose: x=1676, y=511
textur_resize()::screen=0x8d91ed8
expose: x=1676, y=511
textur_resize()::screen=0x8d91ed8
expose: x=1676, y=511
textur_resize()::screen=0x8d91ed8
expose: x=1676, y=511
textur_resize()::screen=0x8d91ed8
expose: x=1676, y=511
textur_resize()::screen=0x8d91ed8
expose: x=1676, y=511
textur_resize()::screen=0x8d91ed8
expose: x=1676, y=511
textur_resize()::screen=0x8d91ed8
expose: x=1680, y=1050
textur_resize()::screen=0x8d91ed8
expose: x=1676, y=511
textur_resize()::screen=0x8d91ed8

'fullscreen' hotkey of Awesome fix problem.

Interesting. I was seeing that sort of output with simutrans-102.2.2 (was running it from a menu, tried from urxvtc). I am running it now (term on screen 2, Simutrans in a fullscreen window on screen 1). I'll see how things work for awhile and see where I end up.

[inkelyad]

I am running it now (term on screen 2, Simutrans in a fullscreen window on screen 1).

In fullscreen you will not see it. It happens only when simutrans on window mode.

[unnamedrand]

So this is a known bug?

[inkelyad]

Bug about resize event was reported and fixed. I don't know why it active again.
It is annoying but matters only in awesome/dwm-like window managers.
And here you just need use fullscreen.

[prissi]

The problem might be that SDL usually sets window width/height to border of 16 but then aparently it reports the requested size to div_by_16-1. As a reseult there would be a resize request again.

But it never happend on my system, so I do not know.