Hello and welcome back!
This time I am writing the blog with emacs. It's actual the first time that I use this editor. Just for fun: is anyone of you using this it?
Ok, last time there was a strange bug where the depth map wasn't updated. This means that new blocks didn't cast a shadow. But this strange bug only occurred when the torches casted a shadow and not when the sun light did this. And as the torches are using a cube map as shadow map and the sun light doesn't I suspected that the problem could be in the graphics driver and not in our game. And I was indeed right. We tested the game on several non Mac computers and everything worked fine. So it works on Linux and Windows but not on Mac. We will try to find a workaround.
It's actually quiet interesting how the shadow cube map is generated. The hardware we are targeting does not very well support the combination of a cube map with a shadow map and a framebuffer. So we are actually not using a real depth buffer with depth values. Instead we are using a cube map with RGB format and we store the current depth color-coded in the texture. This means that when the "depth map" is generated the depth value is color coded. In the lighting shader this value is decoded. Here are is an example how the depth map actual looks:
This also means we can't use the GLSL shadow2D command to evaluate the depth texture (because it isn't technical a depth texture). Instead we implemented our own Stratified Poisson Sampling algorithm directly in the shader. You can see the effects of this if you combare the shadow of the sun (which uses shadow2D) with the shadow of a torch:
Shadow of a torch:
Shadow of the sun:
And I also improved the speed of the GUI as I had the impression that the performance dropped a little bit when the new GUI is used. The problem here was that we were still using glBegin/glEnd which is rather slow and of course deprecated. We switched now to VBO's to draw the GUI. This of course would have improved the performance but I wanted more. To understand how this can be achieved you must understand that every draw command costs a certain amount of time. And this does not scal with the amount of polygons which are drawn with this command. So it is a good idea to draw as much polygons in a single command. We created a VertexBuffer in the drawing canvas which collects all polygons which should be drawn. Whenever the texture or the pen type is changed these polygons are drawn in a single command. The difference can be seen in the following screenshots. For illustration every single drawing command uses a different color. Here is a screenshot from the old system:
It can be clearly seen that every letter for example has it's own color. So we have one letter equals one drawing command. And yes today is birth day party (because of the colors of the letters :-) )
Now watch the new system:
Here you can see that the letters have usually the same color. This means that these are drawn in a single command which is much faster. The particle renderer using a similar system. Here is a screenshot of the finished GUI:
I am curious which crazy YouTuber uses the two colored images to show how bad my game is :-): "Look guys this crazy dev made a blue/yellow GUI which changes the color every frame".
So I hope now that the GUI is fast enough.