Great job! I'll have to learn how to use SDL

That's ~400 100x100 BMP images per second.
What are the figures for 32x32 and 16x16 bitmaps (if possible, drawn with various modes: replace, masked, transparent), i.e. game sprites ?

Thanks

So... as there are 20*15 16x16 sprites on the Nspire's 320x240 screen, 8-9K blits per second for 16x16 sprites translates to 26-30 FPS for redrawing the entire screen using only 16x16 clipped sprites. That's better than the performance achievable on TI-68k calcs (shown by e.g. ExtGraph demo12), which is good news, but it's still insufficient for completely getting rid of a tilemap engine for platform games. But unlike what we did on TI-68k calculators (reimplementing tilemap engines), we'll surely be able to take advantage of a number of existing tilemap engine implementations

Seems pretty good for a start. Performance hasn't really been my main thing yet though, as I have been dealing with more important stuff. In later versions I'll optimize whatever possible to squeeze all the juice out of the TI-Nspire.

Sure

On a side note, I'm working on getting SDL_image to run, i.e. support for a lot of different image formats.

Nice

0.1.2's out, it contains mostly just minor changes. One useful addition though is printf-like formatting for SDL_nDrawString (along with NSP_COL and NSP_ROW to easily align text).
For example, to draw "Hello 0xFFFF, 42, world!" in row 1 (starts from 0) column 5, you could do something like (just replace the values by variables of course, otherwise it's useless):

SDL_nDrawString(screen, font, NSP_COL(5), NSP_ROW(1), "Hello 0x%X, %d, %s!", 65535, 42, "world");

It also supports tabs and newline characters, and text wrapping.

I've looked at the mouse stuff, and I might be able to implement that for the next release. I'll also write a full how-to guide to (I reckon it's not very homely when I just dump the headers and static libs in a zip file) and a few example codes in the thread soon.

EDIT:

Could somebody check how fast sprites are blitted on the CX? Download the zip and copy both TNS files to the Examples folder on your TI-Nspire, then run sdl_test.tns. I'm not sure how well memcpy is optimized, but with some magic it might (it's a vague guess though) be faster on the CX than on the non-CX. Thanks a lot.

1000 blits in 113 ms means 8850 blits/s for a 32x32 BMP image, while on the non-CX it was 2994 blits/s. If your figures and my calculations are correct, that's nearly three times faster than on the non-CX. Damn.

Is that correct or am I just missing something and failing at basic math? (EDIT: indeed I messed up, it was 16x16 not 32x32)

EDIT:

Could you (or anyone else for that matter) replace the image.bmp.tns, by the one attached (it's the 16x16 one)? Thanks a lot, you're doing a great favor.

Oh wow what a mistake, so it was the 16x16 after all. No wonder the results seemed too great to be true.

Well seems like there's not much difference with the 16x16 (although maybe 1000 blits is too little), but in a 1000-blit run it seems to be about 50 ms faster on the CX with the 32x32 image. Thanks for the information.

Once I get the more important stuff working (mouse for instance), I'll look into performance.

EDIT:

Good news. I hadn't compiled with any GCC optimization yet and had forgot about it. Now I compiled SDL with -O3 (i.e. highest optimization level), and the size went from 383K to 241K. But most importantly, with the exact same 32x32 image on a 1000-blit run, it took 325 ms without optimization, and 155 ms with optimization. That's over twice as fast.

I checked and rechecked, and it is indeed true. I tried with a 10000-blit run this time, one program compiled with no optimization and the other one with O3. Here are the results that fit the previous finding:

(10000-blit run, 32x32 BMP image)
Unoptimized: 3261 ms or 3067 blits/s (+0%)
O3 optimized: 1555 ms or 6431 blits/s (+110%)

Really nice