Yeah it sucks that you are planning to stop working on this and retiring from TI-Nspire dev, although I can understand why. You are not alone who stopped developing for the same reasons. I personally was kinda interested in Nspire development when ASM/C arrived, hoping that someone released nAxe or something and perhaps trying Lua, but with everything that TI did, I finally decided against it. It is hard to stay motivated to code for a platform, fully knowing that in one year, almost nobody will be able to use our programs anymore.

By the way have you ever considered developing for the Casio PRIZM, HP Prime or TI-84 Plus C Silver Edition instead? I know calcs becomes pretty much irrelevant after hi school, but look at KermMartian, BrandonW and Ranman, who still actively made calculator programs over a decade after finishing hi school. Ranman was 40 years old, yet, during his free time (limited due to having kids and work), he still worked on TI-89 clones of Commodore 64 games. I myself released new calc games 10 years after finishing hi school, although much less than before. IIRC, someone was working on pSDL for the PRIZM, but I don't know what happened to it. The HP Prime is not hacked yet, but its BASIC language is even faster than Nspire Lua (by far) and people are already working to hack the calc. As for the 84+CSE, it's much slower, but if you like old school platforms and pushing them to their limits that could be a nice alternative, plus it's incredibly popular (just see how many downloads per week a simple Frogger or Snake clone can get). All those three calcs are open to ASM development (especially the 84+CSE, which has an Asm() command), although the HP Prime isn't released yet.

PRIZM (FX cg20):
-Max 94.3 MHz SH4
-2 MB RAM (61 KB for BASIC coders)
-16 MB Flash
-384x216 color LCD supporting both 65536 and 8 color modes

TI-84 Plus C Silver Edition:
-15 MHz Z80
-128 KB RAM (21 KB for user)
-3.5 MB Flash
-Color LCD supporting both 320x240 and 160x240 resolution, along with 65536 and 8 color modes
-Built-in horizontal scrolling support

HP Prime:
-Max 400 MHz ARM processor (supposedly clocked at 266 MHz by default)
-32 MB RAM (16 used by the OS)
-256 MB Flash
-320x240 LCD supporting 65536 colors
-BASIC language supports sprites of any size, sprite scaling, decuple buffering (10 buffers, although I don't see much need for anything higher than double or triple buffering), rectangles and transparent text (7 different sizes) that is anti-aliased.

Yeah I remember that with the 68K models, TI kept changing the hardware, causing most old programs to break. At one point in 2000 or so, most people thought that on HW2 grayscale would never be possible. Then came HW3 a few years later, which broke all ASM programs.

On the 84+, we had to deal with compatibility issues with TI-Graph Link-generated groups, then came the 2007 hardware change causing games using extra RAM to break. MP OSes also caused major problems and several of my older games don't work properly on them.

Casio calcs had their shares of issues as well, especially the FX 9860G hardware changes last year or so.

I know this is a bit off topic, but is there any reason in particular you are considering Korea? Also, life> than calculators.

Good luck in university, and I hope you continue developing nSDL!

Now that this is going all the way off-topic, i might just say that you can always start off with short distances travels (to a neighbouring country, for instance) to get a feel, and later decide what you should do next. As already said by DJ, it's not a very good idea to go very far to start with and specially to travel alone when you are very young < 18 years. But do learn to take risks when you're young, it will certainly be very useful, funny and sometimes troublesome as well.

I found out that nSDL_GetPixel(SDL_Surface*, int, int) is incompatible with surfaces loaded with SDL_LoadBMP(char*) it works with images loaded by IMG_Load(char*) though.

Hmmmm, that's interesting, because I knew about a same bug in the OCaml SDL binding where grayscale images (bmp here) were incompatible with set/get pixel.

Is your bmp a grayscale image by any chance ?

No, it's a classical 24-bits bitmap.

From the nSDL wiki:

Returns the pixel's color at (x, y). Assumes the surface has been locked. Does no clipping. Supports 8-, 16- and 32-bit surfaces.

I intentionally did not want to support 24-bit surfaces as they require a few extra operations, and I wanted to keep the pixel manipulation functions as fast as possible.

I just looked at the pixel manipulation code in nSDL, and apparently it should call SDL_Unsupported(), which I think IIRC calls SDL_SetError(). Did you try doing SDL_GetError() after the pixel thing?

Also you shouldn't be handling 24-bit images in speed critical code, as neither of the machines use that as their native display bit depth. You'll lose a lot of performance if you start blitting 24-bit stuff on 16-bit surfaces etc. as the conversion is done on the fly. Convert the surface as you load them.

TL;DR it's not supposed to work