Frame Time so low, we’re drawing the future.

Last devlog I said Raylib was slow. It is on me, I am dumb. I didn’t have to look more into it, DrawMesh did the exact thing I required!

Currently, the frame renders in my laptop under 0.9ms instead of 3-4ms earlier and in this devlog I document the changes I made.

Batch Rendering

Earlier I iterated over all the vertices and rendered them.

for v in vertices {
    rlgl.Color4ub(v.color.r, v.color.g, v.color.b, v.color.a)
    rlgl.Vertex2f(v.pos.x, v.pos.y)
}

That was very slow, when I profiled it I saw that just iterating over the vertices took about 1.4ms. Drawing took another 1.5ms.

So I changed the vertices data:

// old
vertex :: struct {
    pos: rl.Vector2,
    color: rl.Color,
}
vertices: [dynamic]vertex

// new
vertices_pos: [dynamic]rl.Vector3
vertices_col: [dynamic]rl.Color

Then I generate a terrain_mesh using these arrays in this function. And use that to render everything at once!

if mesh_initialised && terrain_mesh.vaoId != 0 {
    rl.DrawMesh(terrain_mesh, default_material, default_transform)
}

Results

Went from 3-4ms to 0.5ms. But when we move we have to generate the vertices at each frame! So if we don’ t move it is 0.5ms but if we move it is 4.0+ms!!!

Chunking

Since our terrain doesn’t change, we can store the results in GPU memory and render them at will.
But if we try to render a texture of size 5120x5120, our gpu will suffer really bad. So we chunk.

We divide the terrain in chunks, load them into gpu and show only the parts that are visible currently.

Sounds easy. But for stupid ppl like me it is hard, took me a long while to fight the memory, logic and silly mistakes.

But finally, it did work.

Results

It renders about 0.8ms avg and 1ms in high load, sometimes goes down to 0.6ms too! That too while moving!