OpenGL – PC and Android

The container pattern also turned out to be a great solution for unified handling application lifecycle, various input sources, and assets. And the best is that I can easily add drivers for various sensors, cameras, or robotic pizza restaurants.

There is an interesting difference inside the shader language. OpenGL ES doesn’t allow you to define a sampler array and then refer to its elements by anything which isn’t a constant. This effectively means that it’s not possible to write a loop to apply multiple textures. This led to a number of if statements, where each branch has the same code with a different texture.

Working across different screens. The main thing is that aspect ratio dramatically changes. If you tune everything for the landscape orientation, then the portrait one won’t work. I implemented a way that things like camera or UI components have the ability to decide their properties based on the display size. And everything can change during the runtime. This is not difficult to do, but it eats away a good chunk of your time.

There are two major careables – precision and performance.

Precision is related to the z-buffer and floating-point numbers. When I first run my application, I discovered that my mobile phone uses lower precision than my PC. Interesting. The result is more noticeable z-fighting and shadow artifacts. You might see other artifacts as well. In any case, you render objects close to each other. Typical advice on how to deal with these is about offsets and bias values. More advanced ones go into a way how to fake a higher precision. For example, split the scene into parts and render each of them with a separate z-buffer.

The first time tried to run the shadow light example, I was shocked by seeing something like 3fps while rendering a simple cube with shadow. It took me a few days to discover that it was caused by two problems. The first problem was that I couldn’t specify empty color attachment during frame buffer creation in the OpenGL ES. 

This didn’t make the program fail, but it made it run terribly slow and keep showing some error in the log. The second problem was related to mobile phone architecture. Apparently battery life length is important, so they decided to use a different architecture to save some power. This lead to an extra shuffling in between memories which took time. The solution for this was to explicitly clear the shadow buffer right after binding, so the copying didn’t need to take place.

Although having all this in place, the performance on mobile is still much lower than on PC. For example, 3 shadow lights already cause noticeable slowness on the mobile. And when I implemented PCF to make smooth shadows, it was a disaster. So I decided to keep shadows ugly on mobile phones.

As a lesson, I plan to do these two things in the feature.