0.3.0, with a few changes:

• Full compatibility on all TI-Nspire calculators without recompiling, i.e., only one library file, one compile for all calculators
• SDL errors are shown through a text box
• Resolutions smaller than 320x240 are supported
• Odd coordinates now are correctly handled on TC models
• Fixed mouse leaving trail on some occasions
• Fixed sprites getting messed up with odd-width array-based images
• SDL_nCreatePalette() now creates a color palette on both TC & CX 8 bpp mode
• Again, a lot of cleaning up and rewriting

Here's the Zelda example running in 100x100:


This version should be quite useful for porting SDL programs.

Download here.

Very nice

Also, since it's a "universal binary", what the size difference with the version before ? Probably not much ? (which means it's easier anyway for the programmer/user)

Very nice

Also, since it's a "universal binary", what the size difference with the version before ? Probably not much ? (which means it's easier anyway for the programmer/user)

There's practically no difference.

Nice!

GCC has __builtin_fscanf() as far as I know.

We can easily port only:
- games whose source code is available
- games which relies on the SDL library
- games which doesn't use assembly (between an MS-DOS and a Linux version of the same game, we should choose to work on the Linux version)
- games written in C (no C++)

Also resolution should be taken into account, as nSDL handles resolution <= 320x240. Oh and global variables can be a source of frustration on bigger programs as there's no stable loader currently. Thankfully GP32/GP2X and some other machines have many games, use SDL, have a 320x240 resolution and many (most?) of the games are written in C. Oh and of course all the DOS clones/ports in SDL (C-Dogs, OpenTyrian and whatnot) and generic flexible SDL games.

EDIT:

I hardcoded (using a simple script) the map data in the program and compiled it. Magic happened:

I've attached the game here in my post. I'd appreciate it if someone with a CX could try it (just dump the whole folder in the Examples folder on the TI-Nspire) and tell me how it runs. Even better would be to upload a video about it. If you have a Touchpad/Clickpad you can try it too, but the games' colors are quite dark; I couldn't see much (that made me think of a function that inverts the palette...hmm).

The controls are CTRL, tab, arrow keys (player 1) and 8/2/4/6, enter (player 2). Yes there's 2 player mode also.

Please correct me if I'm wrong:

We can easily port only:
- games whose source code is available
- games which relies on the SDL library
- games which doesn't use assembly (between an MS-DOS and a Linux version of the same game, we should choose to work on the Linux version)
- games written in C (no C++)

Meaning that until we've got a C++ toolchain for Ndless, most of the greatest SDL games/emulators can't be ported?...

To address some points:

- Yup, but that goes without saying. There is no way we can do any binary translation; otherwise, iOS apps could then be ported to Android. (OK, bad example, but you know what I mean)
- Yeah, pretty much. But SDL will still let people create new games too
- Somewhat - assembly can be ported too. SDL emulators in particular can use this. More or less, C -> ASM for any emulator work because C would be (somewhat) slow.
- There's a bFLT loader that is supposedly done, which supports C++ programming. (See here.) I do not know of its status, and whether or not it has merged with the official ndless tree, or if it's stable or not. (I think the author, tangrs, is busy with his finals, so... ExtendeD and tangrs can clarify its status.)

There's one little thing that I'd like to see implemented before it gets off: replacing library IDs with Java-style names. (For instance, "com.alberthrocks.myawesomelibrary") There's a max of 256 libraries that can be had, which in the future may not be enough. (I've indicated that idea here.) Unfortunately I don't have enough experience to try this, so...

Quote

I do not know of its status, and whether or not it has merged with the official ndless tree

It has not yet.

Ahh... if only I had time to work on this (I have college-like finals, aka CollegeBoard AP tests this week.)

If it cannot be done with standard bFLT (and I'm not aware it can be done), it's unlikely to be something we want to do: hacked up formats require non-standard toolchains, which are a maintenance burden in the long term

True Well... I guess we could reserve a few numbers for ndless' core and particular important libraries, and then use some kind of ID manager for the rest. I just hope implementing all of this won't get too messy...

As the porting went rather well, I'm now working on an improved public version (named Dodgin' Diamond 2X) of the aforementioned game, Dodgin' Diamond 2. As usual, a screenshot, of the game's menu: