nSDL 1.1.1 Anniversary Edition—The Ultimate TI-Nspire Graphics Library!

[hoffa]

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.

[Hayleia]

This looks great
I hope a lot of people will code games for Nspires with this

Btw, if it is now v0.3.0, you might want to change the title of the first post Nevermind

[adriweb]

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)

[willrandship]

hmm....

BASIC commands that use this....mmmmm

[hoffa]

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.

[hoffa]

I've been doing some porting lately to see how it works.

First of all I ported a small CHIP-8/SCHIP emulator:



(Joust up in this mothafaqa)

But because of the way the CHIP-8 system works, it flickers (no buffers) and requires fine configuring (how many opcodes before drawing etc.), can't bother to play around with it to get everything to run smoothly.

Then I tried a space shooter I found on the web, and seems to work well except there's no fscanf on the TI-Nspire, and as such I cannot load the mission files, which means I only see this: (I can move around and shoot and everything)

(That's a screenshot from the two player mode)

Haven't had any major issues or troubles porting the programs currently.

[compu]

Nice!

GCC has __builtin_fscanf() as far as I know.

[critor]

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?...

[hoffa]

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.

[adriweb]

Awesome !

I just tried it on my CX-CAS and took a video of my lame playing-while-recording skills

http://www.youtube.com/watch?v=acdAqxiwG7I :
<a href="http://www.youtube.com/watch?v=acdAqxiwG7I" target="_blank">http://www.youtube.com/watch?v=acdAqxiwG7I</a>

(Anyway, this was filmed under bad (camera, lightning etc) conditions, so if anyone wants to do a better recording, please do so )

[alberthrocks]

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...

[Lionel Debroux]

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

It has not yet.

There's one little thing that I'd like to see implemented before it gets off: replacing library IDs with Java-style names.

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

[alberthrocks]

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...

[DJ Omnimaga]

That is great. I love the progress on this. Hopefully converting SDL games won't be too hard in the future.

[hoffa]

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: