That's weird. Which version of ndless and crafti are you using?

They don't even support chroot to get rid of their ubuntu...
Combined with their terrible UI that's enough reason to delete my account.

Is this demo optimized for cubes

Kind-of. I generate a list of Positions (x,y,z) and a list of IndexedVertices (a reference to a position, a color and uv-coordinates).
As it's likely that a position is used multiple times (flat area: each position 4 times), I don't have to transform it more than once.

But as "transformation" also includes perspective, I can't do z-clipping before perspective projection, which is bad
as divisions / 0 or a really small value can happen. And they do happen if I increase the cube size or the camera is in a bad spot.
I'll have to fix this, although it may get slower. I don't know what dominates here, the few "perspective divide"s I don't have to do because of z-clipping
or the "perspective divide"s I will have to do because of z-clipping (If you know what I mean)

will it run as fast when it's smooth terrain with the same amount of vertices?

It depends on how much triangles are visible. The "benchmarks" I performed earlier in this thread were totally wrong as my line drawing is slooooowwww.
Even slower than triangles. I don't now how I did that...

The problem with the texture atlases is that you can't wrap the coordinates, which will eliminate all the out-of-texture-bounds artifacts you are getting

No, it won't. It would just look different!

Consider the following atlas:
AABB
AABB
CCDD
CCDD
It would get stored as AABBAABBCCDDCCDD. An array would get stored AAAABBBBCCCCDDDD - all the information for each individual texture is together in memory.

Could work, but wouldn't make a huge difference. 2*16*16 = 512 Byte, no problem for the cache to store multiple textures.

Another thing that might help is to set GCC to the highest optimization level if you haven't already.

My flags: -O3 -Wall -W -marm -ffast-math -mcpu=arm926ej-s -fno-math-errno -fno-tree-vectorize -fomit-frame-pointer -fno-exceptions
any suggestions?

It SHOULD at least mention something like "ehci.0: registered" or whatever the usb controller is called in the DT.

Does lsusb show something?
Did you switch to host mode before booting into linux?

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.

That'd require external storage and woudn't be very useful.. LXDE works, that's about it.