• nGL - a fast (enough) 3D engine for the nspire 5 4
Currently:

### Author Topic: nGL - a fast (enough) 3D engine for the nspire  (Read 172781 times)

0 Members and 2 Guests are viewing this topic.

#### Vogtinator

• LV9 Veteran (Next: 1337)
• Posts: 1192
• Rating: +108/-5
• Instruction counter
##### Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #105 on: March 03, 2014, 08:13:23 pm »
It's carnival here in germany and therefore holidays
I got around to nGL and crafti and played around with the graphics pipeline to split projection and transformation.
This fixes the division/near-zero error and therefore most artifacts but it got a lot slower as I cannot cache any vertices for projection as easily as before.
1 and 3 change the block type you'll put down (actually changing, adding isn't implemented yet).
Moving around works exactly like before but now collision detection makes it impossible to move into blocks now
I haven't tested the current version on my calculator (it works in nspire_emu, ndless r914 without crashes) and I'll upload it when I confirmed that it doesn't only work on virtualized calculators.

TODO:
-Looking around by touching the touchpad, not by clicking
-Fix remaining bugs
-GUI
-Optimize!

Edit: It works on my calc. The FPS counter doesn't like to be used simultaneously with the keypad, so I had to disable it for now.
I also disabled Z_CLIPPING so triangles will be completely discarded if only partially visible. I appreciate any kind of feedback!
« Last Edit: March 04, 2014, 11:06:44 am by Vogtinator »

#### mdr1

• LV6 Super Member (Next: 500)
• Posts: 303
• Rating: +21/-2
##### Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #106 on: March 04, 2014, 01:28:15 pm »
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).

#### Vogtinator

• LV9 Veteran (Next: 1337)
• Posts: 1192
• Rating: +108/-5
• Instruction counter
##### Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #107 on: March 04, 2014, 01:36:42 pm »
I'm splitting the world into chunks (16x16x16 blocks) which makes things much easier.
As I mentioned earlier, I cannot color textured triangles, as it would require 3 multiplications per pixel.
I could create a second texture and preprocess it, but that would either increase startup time, memory footprint or executable size.
The speed difference between textured blocks and untextured blocks is so insignificant, that a simple if(texture != nullptr) would slow things down more than simply enabling textures the whole time. I could, of course copy the function and split it into nglDrawTexturedTriangle and nglDrawTriangle, but that's code duplication.
What do you think?

#### Matrefeytontias

• Axe roxxor (kinda)
• LV10 31337 u53r (Next: 2000)
• Posts: 1982
• Rating: +310/-12
• Axe roxxor
##### Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #108 on: March 04, 2014, 02:19:07 pm »
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.

#### Vogtinator

• LV9 Veteran (Next: 1337)
• Posts: 1192
• Rating: +108/-5
• Instruction counter
##### Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #109 on: March 04, 2014, 02:44:31 pm »
The inner loop of nglDrawTexture is:
Code: [Select]
for(int x = x1; x <= x2; x += 1, ++z_buf, ++screen_buf){    if(__builtin_expect(*z_buf > z, true))    {        *z_buf = z;        #ifdef TEXTURE_SUPPORT            *screen_buf = texture->bitmap[u.floor() + v.floor()*texture->width];        #else            *screen_buf = low->c;        #endif    }    #ifdef TEXTURE_SUPPORT        u += du;        v += dv;    #endif    z += dz;}
Another conditional branch per pixel would ruin the performance.

#### Vogtinator

• LV9 Veteran (Next: 1337)
• Posts: 1192
• Rating: +108/-5
• Instruction counter
##### Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #110 on: March 06, 2014, 05:34:46 pm »
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!

#### annoyingcalc

• LV10 31337 u53r (Next: 2000)
• Posts: 1953
• Rating: +140/-72
• Found in Eclipse.exe
##### Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #111 on: March 06, 2014, 09:54:48 pm »
Wow, this is so much better than nCraft!
This used to contain a signature.

#### mdr1

• LV6 Super Member (Next: 500)
• Posts: 303
• Rating: +21/-2
##### Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #112 on: March 08, 2014, 08:41:54 am »
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

#### kevinkore3

• LV3 Member (Next: 100)
• Posts: 57
• Rating: +0/-0
##### Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #113 on: March 08, 2014, 12:21:57 pm »
What are your settings for nover to play this?

#### Vogtinator

• LV9 Veteran (Next: 1337)
• Posts: 1192
• Rating: +108/-5
• Instruction counter
##### Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #114 on: March 08, 2014, 12:42:48 pm »
Quote
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.

Quote
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.

Quote
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

« Last Edit: March 08, 2014, 05:19:20 pm by Vogtinator »

#### mdr1

• LV6 Super Member (Next: 500)
• Posts: 303
• Rating: +21/-2
##### Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #115 on: March 09, 2014, 08:24:57 am »
The file association works! Could you add a loading bar when we quit the program when it saves the world?

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

Thanks a lot for your work.

#### Vogtinator

• LV9 Veteran (Next: 1337)
• Posts: 1192
• Rating: +108/-5
• Instruction counter
##### Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #116 on: March 09, 2014, 10:07:35 am »
Quote
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).

Quote
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?

#### mdr1

• LV6 Super Member (Next: 500)
• Posts: 303
• Rating: +21/-2
##### Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #117 on: March 09, 2014, 10:59:24 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...".

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.

#### Vogtinator

• LV9 Veteran (Next: 1337)
• Posts: 1192
• Rating: +108/-5
• Instruction counter
##### Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #118 on: March 09, 2014, 05:33:45 pm »
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!

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
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.

#### kevinkore3

• LV3 Member (Next: 100)
• Posts: 57
• Rating: +0/-0
##### Re: nGL - a fast (enough) 3D engine for the nspire
« Reply #119 on: March 09, 2014, 06:05:29 pm »
Good progress so far!
Could this eventually turn into a full version of minecraft, (with a random map generator, animals, ground 10+ blocks deep) or is the Nspire processor too slow?