Page 2 of 3
Posted: Fri Mar 18, 2011 5:30 am
by 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.
Posted: Fri Mar 18, 2011 9:05 am
by 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.
Posted: Fri Mar 18, 2011 9:28 am
by 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 :-/
Posted: Fri Mar 18, 2011 8:25 pm
by 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.
Posted: Mon Jun 06, 2011 5:15 pm
by 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..
Posted: Mon Jun 06, 2011 6:27 pm
by 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.
Posted: Tue Jun 07, 2011 1:40 pm
by 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...
Posted: Tue Jun 07, 2011 1:57 pm
by CuteAlien
xDan wrote:
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.
Posted: Tue Jun 07, 2011 2:40 pm
by 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.
Posted: Tue Jun 07, 2011 3:29 pm
by 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.
Re: Fullscreen (focus?) problems in 1.6 [update: and with 1.
Posted: Sat Feb 25, 2012 2:58 am
by robmar
Did this get resolved? I have exactly the same problem
Re: Fullscreen (focus?) problems in 1.6 [update: and with 1.
Posted: Sat Feb 25, 2012 10:43 am
by 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..
Re: Fullscreen (focus?) problems in 1.6 [update: and with 1.
Posted: Sat Feb 25, 2012 11:36 am
by 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
Re: Fullscreen (focus?) problems in 1.6 [update: and with 1.
Posted: Sat Feb 25, 2012 3:25 pm
by 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...
Re: Fullscreen (focus?) problems in 1.6 [update: and with 1.
Posted: Sat Feb 25, 2012 3:28 pm
by CuteAlien
Well, yes - most of the discussion here was about a problem on X11. Maybe describe exactly what your "same" problem is.