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

Vogtinator · « **Reply #210 on:** April 27, 2014, 12:34:46 pm »

Quote

I voted for the inventory because I thought it would not take ages to code (unlike mobs, water and lava or redstone)

After the necessary refactoring, water, lava and redstone should be very easy. Inventory would mean creating more textures and a whole new API.

Meanwhile I fixed the GUI issues with external textures and rotation beyond your neck's capabilities.
I won't publish v0.8.1 yet, as I still have to implent rotation of normal blocks, which requires refactoring a lot.

bb010g · « **Reply #211 on:** April 27, 2014, 03:18:30 pm »

Quote from: Vogtinator on April 27, 2014, 12:34:46 pm

I won't publish v0.8.1 yet, as I still have to implent rotation of normal blocks, which requires refactoring a lot.

So, upside-down stairs?

Vogtinator · « **Reply #212 on:** April 27, 2014, 03:25:24 pm »

Quote from: bb010g on April 27, 2014, 03:18:30 pm

Quote from: Vogtinator on April 27, 2014, 12:34:46 pm
I won't publish v0.8.1 yet, as I still have to implent rotation of normal blocks, which requires refactoring a lot.
So, upside-down stairs?

Maybe. Stairs aren't implemented yet, but that shouldn't be much work. I was referring to furnaces, crafting tables, bookshelves and pumpkins, actually. Stairs are "special blocks" as they don't consist of 6 axis-aligned quads with coords aligned to BLOCK_SIZE which is necessary for optimizations.

bb010g · « **Reply #213 on:** April 27, 2014, 03:33:41 pm »

Quote from: Vogtinator on April 27, 2014, 03:25:24 pm

Quote from: bb010g on April 27, 2014, 03:18:30 pm
Quote from: Vogtinator on April 27, 2014, 12:34:46 pm
I won't publish v0.8.1 yet, as I still have to implent rotation of normal blocks, which requires refactoring a lot.
So, upside-down stairs?
Maybe. Stairs aren't implemented yet, but that shouldn't be much work. I was referring to furnaces, crafting tables, bookshelves and pumpkins, actually. Stairs are "special blocks" as they don't consist of 6 axis-aligned quads with coords aligned to BLOCK_SIZE which is necessary for optimizations.

Wait...what do you mean by rotation then? Will the firery side of the furnace face you when you place, or is it something different?

Vogtinator · « **Reply #214 on:** April 27, 2014, 05:13:09 pm »

Quote from: bb010g on April 27, 2014, 03:33:41 pm

Quote from: Vogtinator on April 27, 2014, 03:25:24 pm
Quote from: bb010g on April 27, 2014, 03:18:30 pm
Quote from: Vogtinator on April 27, 2014, 12:34:46 pm
I won't publish v0.8.1 yet, as I still have to implent rotation of normal blocks, which requires refactoring a lot.
So, upside-down stairs?
Maybe. Stairs aren't implemented yet, but that shouldn't be much work. I was referring to furnaces, crafting tables, bookshelves and pumpkins, actually. Stairs are "special blocks" as they don't consist of 6 axis-aligned quads with coords aligned to BLOCK_SIZE which is necessary for optimizations.
Wait...what do you mean by rotation then? Will the firery side of the furnace face you when you place, or is it something different?

Exactly that! The torches do that already (dependent on the side of the block you place it on).

GinDiamond · « **Reply #215 on:** April 27, 2014, 06:15:43 pm »

Will sunlight/shadows ever be implemented, rather than the global illumination?

Vogtinator · « **Reply #216 on:** April 27, 2014, 06:23:13 pm »

Unlikely, that would require three additional multiplications per pixel. Day/night should be possible, though.

GinDiamond · « **Reply #217 on:** April 28, 2014, 09:41:18 am »

Per pixel?

What rendering algorithm does nGl use? I was guessing a raster engine

Vogtinator · « **Reply #218 on:** April 28, 2014, 11:13:42 am »

Jup, I would essentially have to do:

Code: [Select]

for(int x = x_start; x <= x_end; ++x)
{
COLOR c = texture->bitmap[u + v*texture->width];
RGB rgb = fromCOLOR(c);
r *= light;
g *= light;
b *= light;
c = fromRGB(rgb);
screen[x + y*width] = c;
}

For each horizontal line of every triangle visible. Maybe it's possible to premultiply the textures, but for 4 different levels of light that's already 2MB for a 512px texture. I don't know, maybe in a later version.

Runer112 · « **Reply #219 on:** April 28, 2014, 12:44:35 pm »

Quote from: Vogtinator on April 28, 2014, 11:13:42 am

Maybe it's possible to premultiply the textures, but for 4 different levels of light that's already 2MB for a 512px texture. I don't know, maybe in a later version.

I was going to suggest exactly this. Keep in mind that (I believe) a lot of people are happy with the original 16px textures, and with those you could have copies of one texture for all 16 light levels in only 8KB. Of course, if you implemented this for all block types it would start to add up, but it would still only be about 2MB for basically every block in current Minecraft, which includes far more block textures than you'd need with the current set of blocks supported.

Also, hi.

I normally don't tread outside of 83+/84+ threads, but this is the one thread that I make an exception for and keep track of because your work on this is awesome. Out of curiosity because I don't have an Nspire and couldn't see the statistics anywhere in recent posts, what's the performance of this like relative to the draw distance?

kevinkore3 · « **Reply #220 on:** April 28, 2014, 05:00:18 pm »

If you mean draw distance as in how many chunks far you can see, then I'd say it's about 15fps with 3 chunks (or however many blocks are in one +/1) rendering distance(overclocked to 198MHz).

Vogtinator · « **Reply #221 on:** April 28, 2014, 05:43:27 pm »

Quote

I was going to suggest exactly this. Keep in mind that (I believe) a lot of people are happy with the original 16px textures, and with those you could have copies of one texture for all 16 light levels in only 8KB. Of course, if you implemented this for all block types it would start to add up, but it would still only be about 2MB for basically every block in current Minecraft, which includes far more block textures than you'd need with the current set of blocks supported.

Considering that the CX has 64MB RAM and the OS runs on older models with 32MB, there's at least 32MB free (maybe badly fragmented), so that could actually work quite well (but slow down startup time significantly). I added it in the poll above.

Quote

Also, hi. I normally don't tread outside of 83+/84+ threads, but this is the one thread that I make an exception for and keep track of because your work on this is awesome.

Thanks, what an houor

Quote

Out of curiosity because I don't have an Nspire and couldn't see the statistics anywhere in recent posts, what's the performance of this like relative to the draw distance?

Quote

If you mean draw distance as in how many chunks far you can see, then I'd say it's about 15fps with 3 chunks (or however many blocks are in one +/1) rendering distance(overclocked to 198MHz).

That entirely depends on how many triangles are visible. If you have a flat area, it's not much slower, but with hills it slows down quite a lot.
For viewing distance I compute the distance to each chunk with sqrt, so it's not a cubic area, more like a sphere. Anyway, I made a few "benchmarks" with nspire_emu (fps counter makes crafti instable on real HW, which is also quite a bit slower):

	Normal distance, 28 fps		Normal + 1, 22 fps
	Normal + 2, 17 fps		Normal + 5, 10 fps
	Normal - 1, 36 fps		Normal - 2, 57 fps
	Looking up at Normal + 5, 41 fps

And yeah, I should probably make a video. GIFs are so damn ugly with just 256 colors but on the other hand it's quite annoying to record with a camcorder and play simultaneously.

Runer112 · « **Reply #222 on:** April 28, 2014, 06:12:11 pm »

Quote from: Vogtinator on April 28, 2014, 05:43:27 pm

Quote
I was going to suggest exactly this. Keep in mind that (I believe) a lot of people are happy with the original 16px textures, and with those you could have copies of one texture for all 16 light levels in only 8KB. Of course, if you implemented this for all block types it would start to add up, but it would still only be about 2MB for basically every block in current Minecraft, which includes far more block textures than you'd need with the current set of blocks supported.
Considering that the CX has 64MB RAM and the OS runs on older models with 32MB, there's at least 32MB free (maybe badly fragmented), so that could actually work quite well (but slow down startup time significantly). I added it in the poll above.

Should we perhaps reset the poll, now that a new option has been added?

Legimet · « **Reply #223 on:** April 28, 2014, 09:06:12 pm »

Sorry for the delay, but here's the pull request. You can look at freetype_demo in the samples directory.

Vogtinator · « **Reply #224 on:** April 29, 2014, 08:44:28 am »

Quote

Should we perhaps reset the poll, now that a new option has been added?

No, my intention is to remove an option from the poll after I implemented it and add considerable suggestions and possible features on-the-fly.
It shouldn't make a huge difference anyway, as lighting doesn't have an impact on gameplay at all (yet).

Quote from: Legimet on April 28, 2014, 09:06:12 pm

Sorry for the delay, but here's the pull request. You can look at freetype_demo in the samples directory.

Looks good so far, but freetype seems to be a really big chunk of code with a complex API. Nevertheless I'll try it, once my fork gets up-to-date with upstream. Merging both can take a while, there are still two major issues (ndless_resources crashes and ndless_installer as well

).
I updated to GCC 4.9.0 by the way and the problem with elf2flt sucking all RAM out (if iostream is used) is there again

Also, I would suggest not copying freetype's source into the ndless tree, just the static lib with includes and a script to build it.
nSDL and nspireio are seperate libraries as well. Maybe we could use git's submodules?

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

Vogtinator

Re: nGL - a fast (enough) 3D engine for the nspire

bb010g

Re: nGL - a fast (enough) 3D engine for the nspire

Vogtinator

Re: nGL - a fast (enough) 3D engine for the nspire

bb010g

Re: nGL - a fast (enough) 3D engine for the nspire

Vogtinator

Re: nGL - a fast (enough) 3D engine for the nspire

GinDiamond

Re: nGL - a fast (enough) 3D engine for the nspire

Vogtinator

Re: nGL - a fast (enough) 3D engine for the nspire

GinDiamond

Re: nGL - a fast (enough) 3D engine for the nspire

Vogtinator

Re: nGL - a fast (enough) 3D engine for the nspire

Runer112

Re: nGL - a fast (enough) 3D engine for the nspire

kevinkore3

Re: nGL - a fast (enough) 3D engine for the nspire

Vogtinator

Re: nGL - a fast (enough) 3D engine for the nspire

Runer112

Re: nGL - a fast (enough) 3D engine for the nspire

Legimet

Re: nGL - a fast (enough) 3D engine for the nspire

Vogtinator

Re: nGL - a fast (enough) 3D engine for the nspire