Fullscreen (focus?) problems in 1.6 [update: and with 1.7.2]

[agamemnus]

I think your problem is in Windows, too.

Here are cases where I have had odd problems due to alt+tab/focus events:

When starting my program, if I alt+tab out before it finishes loading, the program crashes.

As before -- alt+tabbing twice out of a full-screen program with a different res than the Windows system screen will give me a screen size of 240x16.

[CuteAlien]

@agamemnus: Those problems should be unrelated even if they look similar. This is one of the places where Windows and X11 work rather different.

[REDDemon]

is it possible fixing the problem with that code:?

Code: Select all

if(device->isWindowActive() && device->isWindowFocused() )
{
//rendering& update gameplay & sounds
}
else

device->yield();

just try with that. Usually on windows the active window has also the focus, maybe on linux it is not the same :-/

[xDan]

> is it possible fixing the problem with that code:?

No, doesn't seem to help

I will just reiterate once again that I think my "reproduction" of the bug is not a reproduction at all, but is probably unrelated, though the resulting effect seems similar.

[xDan]

My apologies for bumping this.

But does anyone have any new ideas?

Every so often someone playing the Linux version of my game will report this.

I just randomly tried SuperTuxKart on Ubuntu, that also had the problem the first time I ran it.

I also tried out CuteAlien's hcraft demo a few times, and didn't get the problem. Maybe it was just randomly not appearing though...

I've also tried the SDL device instead of the X11 one - but it seems that has problems too. Most often, in full screen, it freezes completely in a similar manner to the X11 device. And when in windowed mode, it *always* requires clicking on the window to give it focus before it runs at all. (it just appears black until you click. Seems similar to this bug report, though I'm pretty sure I'm running in release mode)

I've only tested SDL with Irrlcht 1.6.1 though, guess I should test a later version as well... and I've not tried the examples with SDL either..

[CuteAlien]

HCraft was prefering xrandr instead of the usual x11_vidmode (as xrandr was way(!) faster on my card), so maybe that's why it worked.

[xDan]

Thanks CuteAlien!!

Initial tests.... that seems to work. At least I've alternated between two versions of the binary, one with xrandr tried first and the other regular Irrlicht, and the xrandr has been perfect while the regular Irrlicht has had the problem several times.

Is there any reason why xrandr could not default to be enabled and be put first as standard in Irrlicht? Or even be a run-time flag ? (e.g. in createDeviceEx)

Well, due to the random nature of the problem I guess it's too early to know for sure if this really fixes it though...

[CuteAlien]

Is there any reason why xrandr could not default to be enabled and be put first as standard in Irrlicht? Or even be a run-time flag ? (e.g. in createDeviceEx)

Not sure about making it the standard (I don't know enough about it to decide that), but I suppose it could be coded to be more flexible. I think (not sure!) xrandr does some real mode-switch, which is faster, but will mess up your desktop when your game ever crashes.

[hybrid]

Well, this implementation is now about 5 or 6 years old. At that time, the xf86vm was quite default, while randr was only emerging and not in every distribution. At least not with the required version.
Due to the linking problems it's not as easy to use any combination of those extensions. You can only prepare a binary which then requires those versions you linked against. It's probably possible to do this with some kind of server check and lazy linking, but I never did this for X11.
We should probably first integrate some kind of linker config binary into the engine, and ease up the makefile configuration process (i.e. a small executable which echos the required paths and linker opts when run, which needs to be included into the makefiles). Then changing the IrrCompileConfig.h won't require changing makefiles so often.

[hendu]

xrandr is not universally better; on some combos (Catalyst & hdmi, Catalyst & vga crt come to mind) it can cause bad flickering for a second or two for every probe.

[robmar]

Did this get resolved? I have exactly the same problem

[xDan]

Switching to xrandr as described above worked for me... at least I didn't get any more reports of this problem after that.

It required modifying CIrrDeviceLinux::switchToFullscreen so that XRandr was tried before XVid. Or I think there are compile flags you can use...

I'm afraid I lost my source and have been away from Irrlicht for a while so can't help more than that..

[hybrid]

Yeah, if you disable xvidmode and enable xrandr (which you have to do in IrrCompileConfig anyway) xrandr will be used. There's no way to modify the priority

[robmar]

Isn´t Xvid a linux mode? I´m testing with Win 7. I looked in the config header but can´t find anything like this for windows...

[CuteAlien]

Well, yes - most of the discussion here was about a problem on X11. Maybe describe exactly what your "same" problem is.