Nice ! But what is that glass pane for ?

Oh ok lol.

I'm curious: With nGL, would it be faster to render a variable-resolution texture in front of the camera than, say, doing a nearest-neighbor scaling in a 2D lib? I mean, all the GL will slow things down a bit, but the optimizations for texture handling may help make up for it. It would also allow for some effects that wouldn't be possible in 2D environments, and would allow you to restrict colorspaces as well.

nGL renders only triangles, so is much more flexible in drawing textures at an arbitrary scale, rotation, translation etc., but that comes at the cost of:

• Clipping
• Culling
• Z-Buffer
• Interpolation along X and Y-Axis (With textures: 3 divisions per scanline, without: 1)

which wouldn't be necessary for simple 2D stuff. That's also the reason I wrote a basically seperate lib "texturetools.cpp" to do 2d transformations (basically blitting, scaling, font etc.) on TEXTUREs. And yes, it's faster than n2dlib

Well I personnally didn't know about your 2D lib until recently (after n2Dlib was started) but you should definitely have bragged told about it sooner. The goal of n2Dlib was not to make something new, just to make a lib that runs at the same speed on CXes and non-CXes (and also that used the same format for "sprites" as nSDL). And apparently, not only it's slower on CXes but it's not even fast on the fastest model -.-
So could you share a link to your 2D lib and to a documentation about it ?

Well, it only does crafti-relevant parts, so no 2d primitives, just texture operations, but the header files should be enough documentation:
texturetools.h
font.h

Small example:
#include <libndls.h>

#include "texturetools.h"
#include "font.h"

int main()
{
    TEXTURE *screen = newTexture(SCREEN_WIDTH, SCREEN_HEIGHT);
    nglInit();
    nglSetBuffer(screen->bitmap);
    while(!isKeyPressed(KEY_NSPIRE_ESC))
    {
        //Draw
        glColor3f(0, 0, 0);
        glClear(GL_COLOR_BUFFER_BIT);

        drawString("Hi!\nThis is a small test!", 0xFFFF, *screen, 0, 0);

        nglDisplay();
    }
    nglUninit();
    deleteTexture(screen);
}

Edit: Forgot to #include <libndls.h>

Okay so stop saying texturetools is faster than n2DLib : I just looked at your drawTexture routine, it's exactly the same as n2DLib's drawSprite

It isn't (probably a typo, but drawTexture = drawSpritePart). I know, I probably sound like an asshole now (), but I already told you how you could optimize it:

• Compile flags! With -Os gcc won't inline most functions etc.
• Multiple unnecessary checks, e.g. "x < 320 && y < 240"
• Unnecessary calculations per pixel, although you could do "c = ~c" once for each sprite
• getPixel and setPixel are unnecessary
• Too many branches. You should now that branches are the slowest thing ever on the nspire.
• Const correctness for pointer variables, e.g.
  void drawSpritePart(unsigned short *src, unsigned int _x, unsigned int _y, Rect* part).
  Otherwise part can't be cached by the caller
• Various micro-optimizations gcc doesn't do somehow

And there's still more to optimize. Partial loop unrolling as 2x16bit access is slower than 1x32bit for example.

To give you an example of a almost fully optimized function, I optimized drawTexture some more: https://github.com/Vogtinator/crafti/blob/master/texturetools.cpp#L151
GCC does some partial unrolling, but doesn't transform 2 16bit accesses (ldrh/strh) to 32bit access(ldr/str), although -Ofast should do something, should I report a bug?
    8e28: e15392b4 ldrh r9, [r3, #-36] ; 0xffffffdc
    8e2c: e14292b4 strh r9, [r2, #-36] ; 0xffffffdc
    8e30: e15392b2 ldrh r9, [r3, #-34] ; 0xffffffde
    8e34: e14292b2 strh r9, [r2, #-34] ; 0xffffffde
Some suggestions:

• Use a Texture struct rather than a unsigned short* for better readability.
• drawPolygon shouldn't use a va_list but rather the pointsList directly, for flexibility and performance

But now it's getting rather off-topic...

Edit: I didn't downvote you. I really like discussions both sides benefit from.

Quote from: Vogtinator on July 06, 2014, 01:58:34 pm

• Use a Texture struct rather than a unsigned short* for better readability.

Well, two of us come from Axe and care less about readability than about speed (even though it seems like we are not Nspire pros ) or efficiency.

It should compile to the same code. If not, it could be faster due to alignment if you use a "flexible array member" (StackOverflow question)

Jup, I wanted to nGL to be as flexible as possible, but without neglecting performance.
I actually thought about rendering the block list to a TEXTURE and letting it "fly in" from up front. I could also render the inventory/quick-select to a ribbon in circle shape (forgot the word) and rotate it so that the currently selected slot points towards the cam (or in a \_/ shape, viewed from above)
The opposite direction is possible as well, e.g. mirrors, portals, side-by-side view - but I don't know how to integrate it into crafti easily.