You mean controls similiar to a rubik's cube?
(Except rotating the individual rings of course)

Edit: FPS counter works now. 100+fps in wireframe mode,  50 in color mode, 30 with textures and 25 with interpolated colors.
But I get some issues with the keypad/touchpad interrupts. If I enable IRQ 16, it just freezes on the real calculator, it works on the emulator.
I acknowledge by writing ~0 to 900e0008 and 900e0044. Can someone give me a clue what might be wrong here?

Now that I think about it, 3D snake would be too easy.

Depends. At first yeah, you are doing it on purpose if you hit something. But when you start being long, you don't see where your tail is when it is not on the face your head is on
And it can be even worse if there are walls and you don't know where.

Well it's written nowhere that you have to do +1 on both numbers
It would be a bent object in a 3D world yes, but still a 1D object.

The way I make snake games, is I have a buffer of coordinates and to increment the snake, I erase the tail, shift the buffer down, and add a new head at a coordinate computed by the direction you are turning.

You *could* do a snake game where the arena is stationary, the snake always moves forward, and can turn left/right/up/down. However, the controls would get very confusing, especially if you turn the snake upside down. Instead, it would be much easier and probably more fun and cool looking if you rotated the arena and kept the snake oriented the same. Of course, you would have to redraw every element of the snake each time, but that looks like it would be trivial with this engine. To visualise, the head would always be centered in the screen, facing away from the camera, looking in the direction the camera is looking. When you turn left/right/up/down, you could use a different sprite for those directions, but still centered. Then, you just change the camera angle. Incrementing the snake would have to be done based on the current view angles, and you would have to increment it with the camera.

You could just call it a dragon and pretend you were riding one and steering it.

One idea I had for a 3D Snake was in the space and with the ability to go in every direction (360° vertically and horizontally), but it would need multiple fruits to eat at once, else a radar would be needed to avoid spending 10 minutes trying to find the next fruit.

True, although I guess if there were many apples to eat it wouldn't be too bad. The problem would probably be coding movement since you could move in every direction.

Anyway, when posting this, I totally missed the other screenshots on the previous page or they were not showing up:

UPDATE! 

I made some progress on nGL and made another demo (which is again, not intended to be "played"): crafti!

Changes:

• Faster! A lot faster, actually. I can't tell any numbers, but with large triangles it went from slow to smooth
• Interpolating colors between vertices, which is actually slower than textured rendering
• Prefixed functions with ngl (for example nglInit)
• Something like vertex arrays (nglAddVertices)
• Wireframed rendering
• Doesn't crash anymore
• Some documentation
• Clipping! (X: Per pixel Y: Per line Z: Per triangle)

Todo:

• Colored textures (non-interpolated)
• Compressed textures (zlib). nGL doesn't lose performance with higher-resolution images, they just get too big in raw format
• Make a real, playable, good looking game which uses nGL
• FPS counter

It looks a lot better on the emulator and on calc than these gifs (byzanz-record is crap):

(The emulator runs at 90% speed here, I accidentially hit F9)

The textures used aren't mine this time, terrain.png came from http://www.planetminecraft.com/texture_pack/fancycraft-by-jjjas0n-64x64-version-100.
Also, the controls (same as nGL in the first post) are a bit weird to use on a PC so the twitches you see are just my fingers finding the keys.

It's a bit slower on calc than on the emulator, I suspect it's the touchpad polling every frame, but if that get's a real issue, I'll take care of that.
If you want to use nGL, grab gl.cpp, gl.h, fastmath.h, fastmath.cpp, fix.h and don't forget to read gl.h and #define SAFE_MODE in gl.h!

Do you think this engine would be powerful enough for a Minecraft game? Chockosta made one in Lua with no textures but it ran at 10 FPS at 230 MHz, even if it only rendered stuff within a three tiles radius.

Do you think this engine would be powerful enough for a Minecraft game?  Chockosta made one in Lua with no textures but it ran at 10 FPS at 230 MHz, even if it only rendered stuff within a three tiles radius.

"crafti" runs at > 20 fps with textures and ~50 without, so it should be possible to play with.
I'm currently working on a game using nGL, but it's not ready yet.
However, I could also imagine some kind of "Portal" game with real portals (move camera to other portal, render into buffer, bind buffer to texture, render portal with texture) which would certainly run fast enough if the level geometry isn't too complex.
Chockosta didn't code ncraft in lua (That would be a PITA, really) he did in in C, but with floats. It would run much faster if he would use fixed-point math like nGL does. Also, nCraft is more optimized to render blocks (culling etc.) so it could turn out even slightly faster than nGL now.