Here's a version where the miscalculations are more clearly visible:
If it's further away the depth resolution decreases, in this .gif it's moving away with CONSTANT speed, so
the small "breaks" in movement are just differences beyond the precision.

It's weekend again, so some more progress:

• Replaced terrain.png with original terrain.png from Minecraft (Copyright Mojang AB)
• Trees
• Infinite world generation (The trees are the only thing changing for now)
• Faster startup (cos uses sin_lut)
• Faster

With textures it's smooth now also with some more blocks visible (~25 fps):


I had to use imgur for that one as I couldn't upload it to img.ourl.ca.
The file was probably too large and every file I try to upload now (name doesn't matter)
doesn't get uploaded and it shows "crafti_world.gif" (the old file name!) was uploaded successfully and a 404 NOT FOUND next to it...

Without textures we can expand the viewable distance a bit further and we get to ~11 fps:


But for comparision fps-wise with the same distance as with textures above (~40 fps):


Known bugs:
-Weird lines if textures enabled
-Sometimes a triangle hitting the right screen border shows random data if textures enabled
-Sometimes it displays garbage if perfectly aligned to Z axis

I know where the lines are coming from and it's not exactly that.
It's a bit harder to fix though, because simply testing the coordinates EVERY PIXEL would be to slow.
But I kind-of know what I can do in this case.

Since these textures are repeated, it would actually make more sense to wrap the texture coordinates. It would have to be tested per-pixel, however it should be fairly fast (as long as textures are a power of two size), just a bitwise AND on each coordinate value. For a minecraft engine, this would also open up the ability to simplify meshes in large, flat areas of the same block.

You are using fixed-points, right? Well, then you can kinda cheat a bit by setting the coordinates to e.g. 0.1 and 15.9 instead of 0 and 16. It's just as fast as the previous code, but after experimenting a bit with the values, you can get rid of the lines witouth visuall distorting the texture.

I'm doing that already. I have a nice SAFE_MODE #define which tells me if something is read out-of-bounds and it was triggered with OpenGL like texture coords (0 - 1 on the edges) vs. nGL coords (0-1 - 1px on the edge pixels). As the lines are a unique color (for each texture) I don't think it's some out-of-bounds read (texture atlas, see below).

Since these textures are repeated, it would actually make more sense to wrap the texture coordinates. It would have to be tested per-pixel, however it should be fairly fast (as long as textures are a power of two size), just a bitwise AND on each coordinate value. For a minecraft engine, this would also open up the ability to simplify meshes in large, flat areas of the same block.

The problem here is that I'm using a texture atlas.
As I preprocess every Chunk and basically just have to iterate over a array of vertices, I'd have to determine which texture to bind for every triangle.
That'd be horribly slow.
The problem is rather a rounding issue, as with fixed-point x / y = z can be true, but z * y = x doesn't have to be.
Or maybe I'm just completely wrong. Who knows. I'll have to fix those bugs anyway...

I'd say go for the fastest. It' only disturbing when blocks are really far.

Actually, with the improved indexed-rendering I'd have to do less floating-point calculations so it's not that slow.
Still 18 fps if textures enabled.

BTW: Who told me that floats wouldn't be much slower than fixed-point? It was you, Levak, wasn't it?

I'd say that you should include both mode (with and without textures) in the final version so that we can make beautiful screenshots with textures and build quickly too
(not that it is slow with textures, but it is faster without so if we want to make quick changes, we might want a quick way).

That'd mean switching without recompiling, the problem here is that I enable and disable textures by #define ing TEXTURE_SUPPORT
and an if EVERY PIXEL would be horribly slow. So:
- Code duplication (Copy nglDrawTriangle)
- Ugly preprocessor usage: Move nglDrawTriangle into a header file and #include it with various #define s.

Why should I?

It avoids all the problems of texture atlases

Which problems? Without texture atlasses I would have the same problems as I have no.

You bind to one texture, and then because the format and size of the different textures in the array are the same, you only need to select the appropriate location for the texture data, which can be done by storing an integer ID with every triangle.

That's the problem. I'd have to switch the texture (even if it's just a id or pointer) every triangle and ALSO have UV-coordinates.
Of course it's nicer from the application's point of view.

All the pixels from one texture will be together, increasing cache coherency as well.

What about texture atlasses?

Edit: I built a quick hack into the engine:

The remaining artifacts are a mixture of inaccuracies and rounding errors.