I've left all calculator-related stuff behind for a while now, but seeing that there's consistently some amount of activity going on with nSDL I might blow off the dust of my Windows laptop and release an update and refresh some things a bit.

However porting SDL 2 would take quite some time and the benefits of it aren't massive as far as the TI-Nspire is concerned.

Anyway yeah if you have some suggestions for any additions to the next update, do tell and I'll think about it. Stuff on GitHub and not in nSDL 1.1.1 (have been fermenting there for 10 months  ) are faster text drawing and an NSDL_DISPLAY_BPP macro (that represents the calculator's display bit depth). I'll possibly add 24-bit support for nSDL_GetPixel and make nSDL_LoadImage automatically optimize the surface for the display bit depth. I should probably also go through Lepunzlag's nSDL_CustomFonts and see if and how integration would happen.

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

Would it be possible to somehow control the TI-Nspire's native cursor through Ndless? I don't know if it's because of some new changes in Ndless or not, but now I can see the animated clock desperetaly trying to draw itself on the screen, and it moves as I move my finger on the touchpad. That means there is some master thread running and taking care of the mouse, it would be much better if I could get access to that. I guess functions to read the coordinates and force the cursor to draw itself would be extremely welcome.

Quote from: Vogtinator on August 10, 2013, 12:37:28 pm

Quote

Quote from: Levak on August 10, 2013, 11:38:42 am

On another topic, talking about web hosting, what should differ from the existing if there is no PC-side client ?
I mean what will be the differences between TI-Planet hosting and the pretty concept posted earlier ?

Hmm.. the computer side is to have a unified repo-browsing and transferring experience that also makes the whole package-with-metadata thing easier (not made by hand by the user).
Concerning TI-Planet, since we'd already talked about having some API to get archive-info and whatnot (-in JSON, I believe, but that's not much the point), this would be the chance to get it done for a good/well-defined purpose.

And, the two things above are the exact same thing, just with a different layout. We would need a native client, which also handles transferring the files (libticalcs + Qt?).

I'd very much like to insist that to get as many people attracted to this project as possible, something without any external install would be better, and thus it's why I'd be thinking of a Java program which :
- if running on Linux, uses libti*
- if Mac or Windows, detect if TINC[L]S is installed, then use navnet, otherwise fallback on libti* if installed.
On both cases, if no transfer "driver" is detected (unlikely...), well, tell the user to get either one. (But the rest of the program could still work)

Most people pretty much never hook up their calculator to their computer, it's hacky, requires to download tools and has minimal benefits (compared to the work required to implement it nicely).

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.

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.