vogtinator / ngl

3D graphics lib for Ndless (and possibly other systems)

nGL

3D graphics library for Ndless (and possibly other systems). It's not a complete 3D engine, so there's no collision detection, animation etc.

Features

• Fixed-function pipeline like OpenGL
• Matrix stack with custom size
• 3D transformations, like translation, rotation and scaling
• Perspective with custom FOV
• Depth buffer that can also be read from
• Fast blitting of TEXTUREs
• Fast sine and cosine using LUTs
• Safe and fast mode
• Texture mapping, with transparency

Used in crafti, the winner of 2014's ticalc.org POTY contest!

Tutorial

You can find a tutorial in the Tutorial subfolder.

ngl's Issues

Textures not rendered

Hey,
Since today the next-branch works fine because previously quads haven't been rendered properly if their z distance to the camera was less than ~170.

But textures don't work for me.
A quad/triangle just changes to a single color instead of the complete texture.

Here's my glconfig:

//Colored triangles can still be used with nglForceColor(true)
#define TEXTURE_SUPPORT

//Warning, this is slower than textured rendering!
//#define INTERPOLATE_COLORS

//#define WIREFRAME_MODE

//If disabled, triangles partially behind the CLIP_PLANE will be discarded
#define Z_CLIPPING

//Deactivate after you don't get any warnings.
//Otherwise it may corrupt random memory and crash.
#define SAFE_MODE

//If some geometry inaccuracies annoy you, enable this.
//It's a bit slower though.
//#define BETTER_PERSPECTIVE

//Print "FPS: <fps>\n" to stdout every second
//#define FPS_COUNTER

#if defined(TEXTURE_SUPPORT) && defined(INTERPOLATE_COLORS)
#error "Colors and textures cannot be used simultaneously!"
#endif

#define CLIP_PLANE 25

#define MATRIX_STACK_SIZE 10

I also tried it with other options but it doesn't want to apply the texture.

Drawing to screen

I was wondering about the usage of lcd_blit(void*) versus using the raw LCD screen memory address.

Looking through lcd_blit.cpp, the lcd_blit(void*) calls a hardware-specific function in the array lcd_blit_320x240_320x240_565 or 2 others. This then performs a memcpy from the passed buffer into the LCD screen address.

Why not just write each pixel as needed into the LCD screen address? Since 2 writes I see are done, one from triangles into the nGL screen buffer (looking at triangles.inc.h), then the last one in lcd_blit() when that same buffer is now copied to the screen address. Is this not done because of safety/ease of use, or does it makes little difference in speed?

Is there a way to draw to the screen faster or is this best we have?