I can either make the game have a high peak frame rate, or have a smooth frame rate. I’ve condensed it down to a single constant number called CHUNK_SIZE.
If it’s set to 32, the game does this while rebuilding chunks (sunrise, sunset, loading a level, walking fast:)
The red bar is how long each frame takes in ms. Huge differences like that means stuttery performance.
And this when finished rebuilding chunks:
A chunk size of 16 looks like this when rebuilding:
And like this when finished:
So while a chunk size of 32 has a peak fps of almost twice that of 16 fps, the time it takes to rebuild a chunk is waaaay longer, causing much more uneven fps, to the point where the bare minimum of one rebuild per frame still causes the average frame rate to drop to a third of the maximum, and causing a lot of stuttering.
With 16 chunk size, the maximum frame rate is almost half that of 32, but the game runs a lot smoother, and more importantly, the difference between rebuilding chunks and not is much less noticeable.
(The regular spikes are the game logic ticks)
I honestly have no idea what any of this means :D
but, it seemed like important progress-news, so I put it on here.
if anyone can tell me what it means, that would be very much appreciated :D
its about regenerating some stuff when the map is changed (like sunrise: blocks change color (kinda :p))
one question from me tho, what changed
i compared the before and after ones, and the only thing i saw was one was missing a sheep (prolly moved) and the water/clouds (animated)
so bottom line, i don't get it either :p
the Blocks also called Chunks.
If you set them to 16 then theyr bigger.
When you set them to 32 theyr smaller.
Example:
Chunk size 16 .. you would need lets say 27 Blocks to create a Qube.
Chunk siez 32 .. to create the same sized qube would you need 54 Chunks.
The important part of the screenshots is the graph along the bottom.
First screenshot the graph is crazy uneven, indicating a huge difference in delay from frame to frame. This is the graph of chunk updates with a setting of 32, and gameplay would feel jittery.
Second shows very quick frames with tiny spikes, for a pretty smooth high framerate. This is the graph of normal play (no major updates happening) with chunks at 32, and the framerate is higher than any of the other shots.
Third screenshot is a kind of wild graph, but not nearly as uneven as the first one. This is chunks updating while set to 16, and it wouldn't be nearly as bad as what was happening during the first shot.
Fourth is a pretty smooth graph but things are taking longer than in the second shot. This is the graph of no updates with the chunk set at 16; the framerate is lower than it could be because of the chunk size.
So basically by lowering the chunk setting the framerate of the game gets somewhat worse, but it also prevents the framerate from suddenly getting really bad when lots of things start updating at once. I assume it can't change the chunk size during play so he's trying to make the hard decision between them.
ah, thanks a lot! ^^
the graphs are sorta hard to read. orange on red and gradients and all.
Good thing there are people who first care for the FPS and then for the graphics.
From what i can tell from reading about your game, it isn't a crazy competitive fps like Counter Strike where FPS really matter. Would much rather have a smoother frame-rate in a game like this.