Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - hoffa

Pages: 1 [2] 3 4 ... 22
Well, I think we should start small (installing/removing/listing packages, autostart support, shortcuts, everything in a central folder outside of /documents/ hidden from the user -> no .tns extension needed) and then decice what to do next?
This so much, I'd be happy to contribute.

Let's first make a simple, lightweight package manager for calculators. We'll take over the world later.

Oh and for the central repository I'm not entirely against it; I guess a website made exclusively for TI-Nspire PCS packages could (could) be pretty nice.

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?

Alrighty guys got some free time on my hands right now, will probably release an update within the month. Just wondering if you have any suggestions or things you'd like to see being added in the next release. Don't be shy, hit me with your best shots; I'll take care of the filtering. I have already done some minor changes, and mouse support is in the works (I'm trying to figure out the most sane and elegant way to implement it in a single thread).

TI-Nspire / Re: nTileWorld (a Chips Challenge port)
« on: July 01, 2013, 06:20:30 am »
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.

TI-Nspire / Re: [Ndless C] nRayC, a raycasting library for TI-Nspire
« on: June 15, 2013, 07:20:50 am »
Here's the code used in nSDL to use relative paths:

Code: [Select]
int nSDL_EnableRelativePaths(char **argv) {
    char buf[256], *p;
    strcpy(buf, argv[0]);
    p = strrchr(buf, '/');
    if (!p)
        return -1;
    *p = '\0';
    return NU_Set_Current_Dir(buf) ? -1 : 0;

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.

TI-Nspire / Re: [C] F-Zero : trackSpire
« on: February 02, 2013, 12:59:34 pm »
I'd actually suggest you use t0xic_kitt3n's mode7 engine that I modified for 8-bit nSDL. It's been optimized to hell, uses tiles and is easily configurable and uses the native rendering resolution.

TI-Nspire / Re: Mode 7 engine
« on: February 02, 2013, 10:22:06 am »

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

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

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.

TI-Nspire / Re: Mode 7 engine
« on: January 31, 2013, 03:41:35 pm »
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!

TI-Nspire / Re: Mode 7 engine
« on: January 31, 2013, 05:05:17 am »
When using 8 bpp (when initializing SDL with 8 bpp) it's palettized (every color mapped to a certain RGB value; palette is located in screen->format->palette and can be changed using SDL_SetColors()). It generates some default palette which is the one I used.
When using 16 bpp, colors are just encoded as 16-bit high color.

TI-Nspire / Re: Mode 7 engine
« on: January 30, 2013, 03:54:08 pm »
Good news, I managed to push to a constant 40 FPS on CX, and over 70 FPS (!!) on Touchpad.

Can't remember to be honest, it was some key combination to display two pages at once.

TI-Nspire / Re: Dodgin' Diamond 2X
« on: January 30, 2013, 01:25:12 pm »
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):


TI-Nspire / Re: Mode 7 engine
« on: January 30, 2013, 06:51:30 am »
Thanks a lot! That's some pretty damn clean code, it's a pleasure to read/mess with. :ninja:

Purely for viewing pleasure, a CX color version:

And some on-calc footage to see how it runs:

(I edited a few lines to get it working with nSDL and got about 6 FPS extra at the same time)

It runs at a rather constant 28-31 FPS on CX (could certainly be pushed further if it was optimized for 16 bpp) and 45-47 FPS on Touchpad when the whole lower half of the screen is filled.

EDIT2: I added the TNS if somebody wants to play with it.

Pages: 1 [2] 3 4 ... 22