Very good idea, I had never thought of a package manager before.

My attention span is too short to read the whole thread, but here are my two cents:

A package manager is a great idea, especially with projects that have tons of files. I find it crucial that such a program should focus on being:
- extremely simple to use: a whole bunch of settings and commands might be cool for some but it's a turn off for most
- extremely lightweight: it's still a calculator we're talking about, and as such I think a "TI-Nspire AppStore" is overkill and any computer-to-calculator package installing and such is way too hacky and too big of a maintenance mess, plus my user experience instinct tells me it's fun and technically nice but nobody is going to use it
I'm not using the word "extremely" lightly here, by the way.

The whole installing/uninstalling process should be well-defined and elegant. There should only be the bare minimum of metadata (name, version, maybe a short description). All installed files (except from the main executable) could also be placed in some hidden directory somehow (no .tns extension or something?) or everything could be nicely organized in a single main folder. Uninstall scripts (shouldn't be visible directly) could be just a text file with every line being a path to the file to delete. I have to stress on how important "elegant simplicity" is (and by simplicity I don't mean that it should be simple to install nTileWorld from your Android phone connected by serial cable to your fax machine using a single click, but it should be tiny yet in every single level simple while keeping in mind it's still a calculator) unless you (I'm not pointing anyone here) want to blow it and turn it into a dead toy for nerds. This is the kind of stuff that could play a central role with ndless and could be somewhat adopted by those using Nspires.

Of course a central repository would be nice, but is it feasible and worth the effort?

lolno

I'm trying to work on drawing the text, because nSDL_DrawString doesn't support multiline text
And I'm using ifdefs for it, because the font engine built in to Tile World makes it crash for some reason.

EDIT: No need to use NSPIRE_BUILD, _TINSPIRE is built in to nspire-gcc
Also, my version gives an error message if you don't have a certain file (using show_msgbox in libndls)

Actually you can just use the '\n' character in your string for a new line. There was a nSDL_DrawStringInRect() function before but it was just unnecessarily complexifying the code with minimal benefits.

First of all in the engine there are a few hardcoded values that you have to live with, that's what allows good optimization. Look at the macros in the header and see if you have to change them (you should only need to change M7_NUM_TEX IIRC). A texture in the engine is a 16x16 bitmap, aka a tile. m7_LoadTex() adds M7_NUM_TEX 16x16 SDL_Surfaces to the main texture array that contains all of the tiles. Look at the demo I wrote, start from there and modify it bit by bit so you understand what you and the code are doing.

Also this line's wrong: tex[k][j] = nSDL_GetPixel(src, j, i * M7_TEX_SIZE + k); nSDL_GetPixel() takes x- and y-coordinates as input. But you shouldn't even have to write such a function, as m7_LoadTex() does just that (look at how it was done in the demo).

Greetings from a public library in Canberra.

This'll be my final update (plane leaving for Australia tomorrow).

Changes:
- Performance (oncalc): 100 FPS on Touchpad, most probably ~50 FPS on CX (can't test it, lil' brother lost his calc)
- Separated the mode7 part more and renamed stuff for more consistency (resembles much more like an engine)
- Fixed some issue with positions on the map being wrong
- Added a simple function to load textures (only works with 8-bit surfaces, i.e. surface has to be converted first if necessary)
- Cleaned up stuff

Code & binary attached.

EDIT:
One thing I've noticed is that accessing global variables is much slower than accessing any other type of variable. Just using the global screen SDL_Surface in the rendering function decreased the framerate by nearly 10 FPS! It might be good to know if speed is of your concern. IIRC it also applied to accessing structure items.

Good news!

I've now added real color support and with "real" textures! I removed the plain color/texture division and used the whole byte as a palette index (i.e., 8-bit, 256 colors). It was the best method speed/simplicity/size-wise.

After some nitpicky optimization, I managed to push the framerate to 90+ FPS on Touchpad/Clickpad, and to a constant 45 FPS on CX! I believe it's soon pretty much the theoretical maximum performance you can expect.

Aaaand a screenshot because everyone loves 'em:



Source code and binary attached!

Good news, I managed to push to a constant 40 FPS on CX, and over 70 FPS (!!) on Touchpad.

ALRIGHTY. I've tracked down one major bottleneck in nSDL. It was quite obvious but I never thought it would be such a slow-down. Calling any function that pumps the events (SDL_PollEvent(), SDL_GetKeyState(), whatever) seriously hurts performance in speed-critical code. Nothing can really be done about it, just don't use those functions where you need speed, instead stick to keyIsPressed() and whatnot (as most people have done so far in fact).

I changed all the in-game SDL event handling code to normal ndless-style key handling, and now the game jumped to nearly 60 FPS! It's a massive improvement. I was myself already quite impressed with what we had before, updating the whole screen and having multiple layers and everything, but I never expected that I could nearly double the framerate!

Here's a video so you can see, it's much more of a shoot em up now (you can see the framerate in the last part of the video):



DOWNLOAD ATTACHED.