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.

Output:
$ nspire-ld sdl.o libSDL.a
c:/program files (x86)/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2\libgcc.a(unwind-arm.o): In function `get_eit_entry':
C:\msys\1.0\home\yagarto\gcc-build\arm-none-eabi\libgcc/../../../gcc-4.6.2/libgcc/../gcc/config/arm/unwind-arm.c:614: undefined reference to `__exidx_start'
C:\msys\1.0\home\yagarto\gcc-build\arm-none-eabi\libgcc/../../../gcc-4.6.2/libgcc/../gcc/config/arm/unwind-arm.c:614: undefined reference to `__exidx_end'
c:/program files (x86)/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib\libc.a(lib_a-abort.o): In function `abort':
C:\msys\1.0\home\yagarto\newlib-build\arm-none-eabi\newlib\libc\stdlib/../../../../../newlib-1.19.0/newlib/libc/stdlib/abort.c:63: undefined reference to `_exit'
c:/program files (x86)/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib\libc.a(lib_a-signalr.o): In function `_kill_r':
C:\msys\1.0\home\yagarto\newlib-build\arm-none-eabi\newlib\libc\reent/../../../../../newlib-1.19.0/newlib/libc/reent/signalr.c:61: undefined reference to `_kill'
c:/program files (x86)/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib\libc.a(lib_a-signalr.o): In function `_getpid_r':
C:\msys\1.0\home\yagarto\newlib-build\arm-none-eabi\newlib\libc\reent/../../../../../newlib-1.19.0/newlib/libc/reent/signalr.c:96: undefined reference to `_getpid'
collect2: ld returned 1 exit status
Seems like some ARM specific errors. Doesn't seem to recognize the entry point.

There is an issue with documents not always sending although the user pressed "Connect". Although it's a bit of a surface fix, at least now every document should be sent once it's connected. (file attached)
It seems to have actually caused more of exactly what it was supposed to fix, at least on my side. Removed the attachment.

Nice

But as said before, Albert and totorigolo are also busy with an SDL port.
Maybe you should contact them, and eventually work together?

But I thought you said (or whoever it was) that they were "looking" at it, from which I concluded they weren't actually writing any code.

SDL for the TI-Nspire

nSDL is a port of the widely used, cross-platform and open source SDL graphics library for the Ndless-fueled TI-Nspire.

nSDL 1.1.1 is here! Click here for the new updates.

To download the latest nSDL build and access the wiki, check out the nSDL website.

nSDL also has its own little wiki, which you can access by clicking here.

nSDL features:

• Full one-binary-for-all support on every TI-Nspire calculator.
• Very fast & stable buffered drawing.
• Supports all graphics-related functions, events, non-threaded timer functions, and more.
• Supports 8- and 16-bit display bit depth.
• Supports resolutions up to 320 × 240.
• Draw text using fonts you choose.
• Load images directly from the executable (image converter included) or use BMPs.
• SDL_image (supports GIF, LBM, PCX, PNM, TGA and XCF formats) and SDL_gfx available.
• Full-featured sample program included (it has Link in it!).
• Based on the robust SDL 1.2.15.

Links:

• nSDL website & download
• nSDL wiki
• nSDL FAQ
• nSDL source code
• SDL documentation

And I thought the 1st prize was every single game on Steam.

EDIT Weird I don't notice much of a frame difference. Is it just due to the getkey speed limitation and lack of smooth character movement?

Actually I just noticed that that TNS used the timer to refresh the screen every 0.01s (I was measuring the FPS), rather than updating after moving Link (I uploaded again and updated the link). I think why it doesn't seem to be that much faster is because of the key repeat limitation indeed. Also if I had used a map with loads of sprites you would have seen a huge improvement, but even now it should be quite a bit more responsive.

Just to let you know, Owl now runs at a good 50 FPS (from a previous 9 FPS) when not scrolling (thanks to jimbauwens for clearing me up).
Here is a small demo you can try out yourself to see how it runs speed-wise: http://bb.xieke.com/files/1/owl_test.tns
(The code itself is crappy, but I quickly did something dirty so I have a good base from which to write clean code)
It won't work on the official TI-Nspire emulator though, so you have to try it on the actual hardware if you want to actually see something. Also I changed Link to a Link that is the size of a tile (16x16 in this case), as it is currently too much of a mess to deal with arbitrary sized sprites.