We need it for proper working. When it's not available, then function glEnable(GL_FRAMEBUFFER_SRGB) doesn't take any effect, and then displayed image is too dark.
It doesn't solve the issue that the screen is too dark for intel graphics cards on linux, because the driver ignores this request. But still, this is the proper way to do it and it may avoid similar issues in future.
Actually we should detect that the visual is not srgb-capable, and in this case maybe make some gamma correction or filter it on our side to get similar effect.
Now supertuxkart can do:
Windows (fully test in win8 and win7 built with vs2015, mingw not tested):
Input characters using ime (CJK tested).
Fix crashes when try to paste unicode text into editbox in stk.
Linux:
Different keymap can be used in stk now, ie typing russian,hebrew (not bidi-aware) is now possible.
IME not supported.
Mac:
No work has been done, sorry mac fanboys/girls:( Though testing is welcome, esp when pasting words into stk.
Limitation:
No ime box is shown in fullscreen
(Windows)Only the used language in current setting of non-Unicode programs can be typed with its supported IME.
Now we are waiting until window state is already changed to fullscreen. We are getting real window size at the end of creating window function and previously it was sometimes reporting size of the window in windowed mode, which could causing issues in gui. Previously this was workarounded by forcing minimal window size to be at least in screen resolution, but window managers don't like to have non-resizeable fullscreen windows. Now this workaround is not needed anymore.
- choose best available refresh rate
- if resolution doesn't exist, choose first available
- other minor changes.
Works fine with Gnome, but I notices some issues on Openbox and Unity.
Now you can play STK on one screen and watch TV on the second ;-)
Currently I use first (main) screen. We can detect from which screen STK was executed using xinerama.
Will be improved.
In some cases STK was barely playable because of very low refresh rates (25-30Hz).
This may be caused by last changes in display drivers. I remember that previously refresh rates for resolution were in order from the lowest to the greatest. Now I see it in reversed order.
Irrlicht didn't check refresh rates and always set the last available for specified resolution.
Now we use the highest available refresh rate.
Perhaps we should use xrandr library instead of vidmode. It should be much smarter and maybe would solve some multimonitor issues.
