No rush, I will take some time until I get all optimized and mipmapping to work.
I will put all graphics + my scritps for making them to GitHub soon.
No rush, I will take some time until I get all optimized and mipmapping to work.
I will put all graphics + my scritps for making them to GitHub soon.
I tested this and surprisingly it did not affect to the fps. After a second thought, it was quite understandable:
What is counter-intuitive is that when I switched my LUT to have 8-bit values instead of 32-bit values, it is slightly faster (!). This is not the first time I notice this kind of oddity.
Wait, but with the original approach you also have to convert each fixed point coordinate to int coordinate, which is an additional step? This is the main reason I precompute these indices.
Yes i was storing int values to the Lut.
There is no more need to make te billboard objects a square size.
I think I will try loop unrolling optimisation next.
How do you do that? With #pragma unroll
? Doesnāt -O3 do most of this?
By hand ofcourse.
When accessing a byte LUT, the index can be used directly. For 32-bit, the index must be shifted left (multiplied by 4) first. Thatās just one cycle, so itās probably not noticeableā¦ but it might occupy an extra register, forcing GCC to push something else to RAM then read it back later. The amount of registers available is really limiting on Thumb2.
The compiler does not know how many items to unroll, if the loop limit is not constant. @jonne has used this a lot when blitting the buffer to LCD.
You are correct. Checking in the assembly, this time the optimizer has a spare register and it decides to maintain separate (in addition to index) counter for the LUT which it increments by 4 each round.
The attention to textures really helps, it looks better than the original F-zero.
There are 32 billboard objects on screen (including cars). Only one div-instruction is needed per object (i.e. 1/z) when calculating the billboard object position and size. No mipmapping is yet used for billboard objects.
Well they probably donāt need mipmapping since they always are at the same angle anyway.
Great job! Itās looking really nice and smooth.
Thanks! Mipmapping is also used to dim the objects in distance, and to reduce contrast to reduce flickering. But it might be that it is not so much needed as with tiled textures. Letās see when I get the implementation ready.
Mipmapping is for downscaling, which is going on here when the sprites get far away, so they would be helpful. For objects that scale down nonuniformly (e.g. tilt in respect to camera) there is an extension of mipmapping called anisotropic filtering.
My concern with mipmaps here is that youāre supposed to create them manually, right? It can be a little bit of extra burden on the artist ā normally they get generated automatically. But if they were computed by the game, theyād have to be stored in RAM, which is bad. How about creating a tool that would precompute mipmaps before compilation? Or instead of ārealā mipmapping just do some āsmartā scaledown ā e.g. try to preserve sharp lines, automatically lower contrast, always preserve the edge columns/rows etc. (this could be partially precomputed). Just thinking aloud.
I am soon going to have lap times in the race. For that I need numbers as a bitmap. I can always use PokittoLib fonts as a base, or get free fonts from the web. But if @Pharap or somebody else in the community feels like drawing some numbers, and leave his or her mark in the game, I am happy to include that in there.
What font size do you need? And do you want them in colour? If so which colour?