The problem is that textures with float internal formats can be used in framebuffers only when some extensions are available. This is a basic functionality and we need something that is supported on all drivers. As far as I tested, the basic integer GL_RGBA8 format works fine.
Another problem is with GL_BGRA format. The extension with GL_BGRA support is available for almost every device and irrlicht is able to load all textures from files (it has a fallback mode anyway), but when it's used as a texture for framebuffer, it produces a black screen. Again it works fine with GL_RGBA format.
The only issue that is not fixed is SSAO rendering. It uses linear depth rtt, which has GL_R32F type and which can't be easily changed to something other. I disabled SSAO for now, because it is too slow for embedded devices anyway.
I didn't change anything in original OpenGL 3.x rendering, so everything should work as before.
On desktop medium and high precision is generally the same, at least for mesa drivers. But on some Android devices medium precision is much worse, which causes artifacts. We need high precision float variables in vertex shaders for proper scene rendering. Setting different precision for fragment and vertex shaders seems to be not possible, so we just set it to high for both shader types when it's available.
The GL_CONDITION_SATISFIED says that the sync was signaled before the timeout expired. In this case there is no reason to make another glClientWaitSync execution.
It allows to increase performance on devices that have only one available resolution.
It also allows to draw GUI elements in full resolution while rendering the scene with slightly lower resolution, which gives you few additional FPS.
Note that particles don't work as expected yet with this feature.
* pass timeout to driver, rather than unconditional 1ms sleep
This way if the fence is signalled earlier, we can get on with life
sooner.
* optimize displacement bind/clear/render
Stop thrashing render targets, and group things together into single
render-passes. And only bind/clear if we will actually draw.
It adds support for OpenGL ES renderer, which is needed for Android port and for running STK on other embedded devices such as Raspberry Pi.
Currently it works in two ways:
- Shader-based pipeline, which requires OpenGL ES 3.0 (Android >= 4.3)
- Fallback to irrlicht-based fixed pipeline that needs OpenGL ES 2.0. The fixed pipeline generally works, but it is affected by the same issues as our OpenGL 2.1 fixed pipeline renderer.
I tried to modify our OpenGL renderer as little as possible to avoid regressions. The only one major change is that we are now using the "#stk_include" directive in shaders instead of linking multiple shaders into one program.
Currently it works only on linux. The Android port needs some refactoring. In theory it should be possible to make it working on Windows, but we would need some OpenGL ES SDK, or maybe modified libglew.
At this stage it is playable with current mesa drivers. I tested it on intel graphics card and I didn't notice any issues.
On Android only the OpenGL ES 2.0 renderer with fixed pipeline has been tested for now.