NGL is a very lightweight graphics library that I've written that provides buffered access to the TI-Nspire's framebuffer. It provides only a few functions and is not supposed to be a full-fledged graphics library with every drawing routine available, it only includes the basic bricks required (i.e. drawing pixels, filling rectangles and drawing sprites). If it even means anything, I'd say I'm sticking to the SDL philosophy.

It is compatible with CX and non-CX calculators, although binaries are not interchangeable between the two, for flexibility- and speed-related reasons. You can find the "documentation" on the project's github, although the code should be self-documenting and not too difficult to grasp.

Github: https://github.com/Hoffa/NGL

I have one last issue to tackle/understand before I can provide a nice package of the library (and there are still a few bugs to hunt down and improvements to be made). How am I supposed to declare sprite data? ngl_load_image takes as input raw image data and then parses it, but the problem with defining the raw data array is that either the resulting binary cannot be sent to the calculator, or then that GCC doesn't compile the code (with some undefined reference's to memcpy). If I put the array in another translation unit (i.e. in some header or other file) the former happens. If I declare the array in main's scope, I get the memcpy issues. I see little logic in this, maybe the TI-Nspire doesn't like big chunks of statically allocated data (but GCC itself is a very good compressor). Once I manage to deal with that, drawing sprites would be no issue. Any help regarding that?

EDIT: on hold; working on the SDL port.

A suggestion:

ngl_create_surface(ngl_uint w, ngl_uint h)

Should probably be

ngl_create_surface(ngl_uint x, ngl_uint y, ngl_uint w, ngl_uint h)

ngl_create_surface only allocates memory for the surface. The surface can then be blitted to another surface (which can then be copied to the framebuffer using ngl_flip) using ngl_blit_surface, which asks for the position (the ngl_rect dst_rect parameter).

Edit:
Added support for 16-level grayscale format.

Great

Is it complementary to http://ourl.ca/14731/275989 ?

If I had to define it that way, I'd say alternative.

Also, I think I more or less know why there are issues with big chunks of data and the fact that sometimes my code doesn't run even though I changed practically nothing. I'm pretty sure it has to do with the way GCC optimizes for ARM. For instance the way it optimizes structs/enums/unions might cause alignment issues and whatnot (I noticed it won't run when I specify the blit destination with a struct ngl_rect).
http://www.aleph1.co.uk/chapter-10-arm-structured-alignment-faq
Seems like it's a rather common issue, at least according to the number of results on "arm struct alignment" on Google.

hoffa, will you still continue to try the SDL port?

Yes, I will continue with the SDL port.

either the resulting binary cannot be sent to the calculator

What do you mean exactly?

Using nspire_emu, if I try to send the file nothing happens. No errors no nothing. Now that you mentioned the memcpy issue (didn't anyone was aware of it), I think it might very well be because of that.

or then that GCC doesn't compile the code (with some undefined reference's to memcpy).

See http://www.unsads.com/projects/nsptools/ticket/27 .
I'll quickly fix it if it's a blocking problem for you.

I'd appreciate it a lot if you could fix it, it would allow me to advance with the SDL port and with this library. I'm pretty sure it's what's causing the file not being sent.

Are you sure that the file not being sent isn't just a bug in nspire_emu? Try to connect and send again.

I'm quite sure it isn't a bug. It's difficult to explain why, but nspire_emu's behavior feels consistent and more or less logical.

edit: Isn't that the issue you wrote about and fixed here?

That was just a quick hack (that doesn't seem to always work) for nspire_emu disconnecting the USB link every once in a while. It's not it.

Sure.

Edit: disregard that, got it to work.