No, with graphical I mean it utilizes the LCD
You can compile a rootfs with a nice splash screen if you want to.

Why should I?

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.

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

startx should be there...
You can mount it read-write by doing "mount -o remount,rw /".

I tried to fix the depth issues and had to use floats (or int_fast64_t which is equally slow to divide somehow) which is slower (depends on vertex count)
Which version is better? Or should I keep both?

You can disable NFS by rm-ing /etc/init.d/rpc.nfsd

Oh, I got ninja'd while editing...

Does this require a specific (as in "not too old") revision of Ndless ? Because I can run nCraft but not crafti ("not supported").
And yeah, I have a really old revision

edit Indeed, works with r914.

crafti uses c++ which supposedly needs bFLT to work correctly...

However, I only figured out part of the controls, and my calc froze at some point

Are you sure it froze and didn't just display the sky? I haven't had a freeze in a while, only crashes until I (hopefully) fixed them