Perfect, now, there isn't any crash on my calc! Just a point: I have the impression to fly one block over the floor. By the way: did the system light disappear?  Blocks of the same color are undistinguishable. To have a further view, you could enable textures only for the close blocks. Why is the scenery built per big blocks and not normal blocks? (when we walk, a cube of blocks are built on the same time).

I think a filled triangle should not be as fast as a textured triangle... Because a textured triangle works with a per-pixel basis, and a filled triangle with a per-line basis. You must be doing something wrong in your triangle filling.

It took a bit longer this time, I had to trace a really weird bug down to an overflow in the backface culling function 
The first playable release of crafti!

Changes:

• Fewer bugs
• Larger cubes
• Better controls:
  8-4-6-2: Move
  5: Jump
  1-3: Change block (top left corner)
  7: Put block down
  9: Remove block
  Touchpad: Look around like you are using a mouse
• More blocks! Planks, coal ore, brick wall
• Faster! (A bit laggy, but playable)
• If no textures enabled, the color of a block is determined by calculating the average of its texture

Please tell me what you think!

The use of the touchpad like a mouse is really a great idea!
The problem of the splitting into 16x16x16 pixels is that the variation of the length of view can have a factor of 2... Why not split into 8x8x8?

I can't wait to be able to save! :p

What are your settings for nover to play this?

You don't need nover at all, in fact, it would make it even slower as crafti's performance is more dependant on memory speed than CPU frequency.
As you would have to decrease the AHB freq., it also decreases SDRAM speed. I didn't measure anything as the fps timer doesn't work reliably yet.

The use of the touchpad like a mouse is really a great idea!
The problem of the splitting into 16x16x16 pixels is that the variation of the length of view can have a factor of 2... Why not split into 8x8x8?

It's easier to have those chunks only on one layer. As 8 blocks maximum height isn't enough, it would mean stacking chunks on top of each other.
That complicates the terrain generation (currently two sine waves) and it would degrade performance a bit as more blocks are neighbors of other chunks,
which means calculating the global block position, finding the corresponding chunk and calculating the local block position in the chunk for every block of the chunk's edges. Chunk loading is also horribly slow (light calculations, notifying the chunks around it, building the mesh) so it would be quite noticable when you're walking around. But I'll try it, I need to find the perfect size first before I implement saving.

I can't wait to be able to save! :p

Don't worry, I already started implementing it, only a matter of some weeks 
I'll also try to improve terrain generation and create a nice menu and inventory/HUD.
Should I go the creative-mode way or rather survival-mode?

Edit: Implemented loading and saving. You can also make a file extension association in your ndless.cfg.tns (untested). Please tell me whether it works for you! The default filename is /documents/ndless/crafti.map.tns
 

The file association works! Could you add a loading bar when we quit the program when it saves the world?

The next thing I do will be a nice menu. A "saving bar" is unnecessary in my opinion (and difficult to implement as loading/saving isn't async).

Now, if I could suggest something: make the different same nature blocks distinguishable.

How? Exactly how I did it when textures are disabled? (color *= 0.8f)
Or two different texture packs?
Both versions would increase loading time (before you can see anything) as I either have to precalculate the textures or load another one.
Or should I seperate textures from the main executable which also makes "texture packs" possible?

The next version is ready!
New features compared to v0.5:
- Loading and saving (If you exit with ESC it's saved automatically)
- File association (configure with ndless.cfg.tns) for worlds
- Blocks can have a different texture on each side
- More blocks: redstone ore, iron ore, gold ore, diamond ore, sponge, dark planks, bright planks, tnt, furnace, crafting table, bookshelf
- A menu you can open with the menu key (8+2: Choose option 5: Select)
- An "inventory" with all available blocks (period key)

Animated screenshot of nspire_emu:

Disclaimer: It's a gif, so some colors look really awful. The menu transparency looks better than it does here.

If you want to compare the speed of nspire_emu vs. hardware, open the menu on your calculator!

Quote from: Vogtinator on March 09, 2014, 10:07:35 am

A "saving bar" is unnecessary in my opinion (and difficult to implement as loading/saving isn't async).

It enables the user to know that it is normal that nothing happens and to know how much times he has to wait. If it is difficult to know the time needed to save, you could just display on the screen "saving...".

It doesn't take a noticable amount of time to load and save. The delay you experienced was the call to refresh_osscr() which isn't really necessary, so I removed it.

Quote

How? Exactly how I did it when textures are disabled? (color *= 0.8f)
Or two different texture packs?
Both versions would increase loading time (before you can see anything) as I either have to precalculate the textures or load another one.
Or should I seperate textures from the main executable which also makes "texture packs" possible?

Not like when textures were disabled but put a different luminosity for each side (the same for all tops, the same for all east-oriented faces etc.). But yes for color*=0.8f. Since the loading time is currently really short, I think the better solution is the precalculation.

But that would mean on a "wall"-like structure you couldn't see where you put a block. Checkerboard ((x + y + z) % 2 == 0) would make more sense, I think.