Post your Nspire routines here!

[bwang]

I have seen more than one post talking about writing some basic libraries for the Nspire, so I felt that it would be a good idea to start a thread to post any headers we have.
I will start with a modified utils.h/c that supports drawing pixels to a screen buffer. This should be useful for people doing graphics functions.
Right now we need:
-Program Loader
-Graphics: Triangles, dithering, filled circles, etc.
-Better Text I/O (I wrote some, but they are a bit weak)
-More OS symbols
-An implementation of the standard library (stdlib.h, stdio.h, etc) for easier porting.

EDIT 1: Attached a file skeleton.zip. Edit your Nspire code in this folder, and then type 'make' to build. It provides the minimal portion of Ndless required to write programs.
EDIT 2: Attached willrandship's modified common.h, with all the keycodes in it.
EDIT 3: Found a small bug in common.h.
EDIT 4: Latest skeleton.zip
EDIT 5: Realized that MakeTNS is platform-dependent. skeleton is split into Linux and Windows versions.
EDIT 6: Attached a graphics.h/c, which is a not quite finished, but still useful, collection of graphics routines. Right now it contains fast circle and line routines, and some functional but slow rectangle and sprite routines.

EDIT 7: common-fixed.h and utils.zip are now unnecessary. They have been integrated into the skeleton.zip files, so don't bother downloading them. graphics.h/c are still separate for now, and will be until they are finished.

EDIT 8: Updated graphics.c/h to graphics2.c/h. This one contains a much better sprite routine that uses proper memory-copying methods to draw the sprite. The sprite data format has changed, so if you have any old sprite data pass them to

Code: Select All | Copy To Clipboard

1 2	convsprite(char* sprite, char* result, int w, int h)

Here, result is a buffer that is of size w * h / 2 used to hold the new data.
EDIT 9: apcalc found a small bug in common.h. Fixed!
EDIT 10: Fixed a nasty sprite() bug.
EDIT 11: skeleton-windows.zip and skeleton.zip merged. I added a few text and string routines to it (string.h, screen.h) as well as dirlist.h, which lets you list the files in a given directory. Yes, I know this violates EDIT 1, which states that skeleton.zip is minimal, but being able to draw text is too useful. Also, common-fixed.h and utils.zip have disappeared.
EDIT 12: added a function filesize(char* path) to utils.h. Pass it the path to a file and it returns its size.

[yoshi13]

Here is the current state of the routines I have, I will continue to update these:



Ok... The alphabet routines are set up except I haven't had a chance to write the code for actually drawing the letters
(I know that A has code in it but it draws an incomplete hourglass as I was just testing if I could get it to work)

The Drawing routines only contain a square, rectangle and 4 directional line drawer, I will add the triangle and circle later
(The circle is throwing up a bunch of weird errors right now)

Note: The length of strings is currently set to 1 (ie only 1 letter, this can be changed in alphabet.c line 56) as I can't use strlen() without it causing problems with malloc (more precisely sizeof) and spaces as I am temporarily using them to terminate the for loop.

I also attacked my common.h header as it has an extra 15 or so controls already put in



This will help those wanting to add new keys (thanks for the link bwang):

http://hackspire.unsads.com/wiki/index.php/Memory-mapped_I/O_ports#900E0000_-_Keypad
bit 0 to 10 =  1, 2, 4, 8, 10, 20, 40, 80, 100 , 200 , 400 if you are a bit confused on that part

[willrandship]

Interesting...the nspire has an 8-directional Dpad, so up to 16 directions. Not too shabby!

I was thinking about making a non-specific keypad library, that would detect what keypad you have (anyone know the bit that determines this? It's a hardware thing running to one of the keypads, I'll bet) and then substitute keypad commands and such, so touch, 84+ and regular nspire could all be run with the same header.

[DJ Omnimaga]

Also, this forum needs to be updated to support .c and .h attachments.

fixed

[bwang]

yoshi13: Why are you allocating your integers with malloc()? You can just declare them as, for example, int i.
malloc() is for arrays and such.
Also, you probably want to draw your characters the same way you'd draw sprites. Make an array of pointers to int, with each element being a pointer to the first element of an array containing data for the character. Then to draw a character ch, simply call sprite_routine(char_data[ch]).

[yoshi13]

I know that you don't need to call malloc() for integers but for certain ones it used to crash the calc if I didn't declare them so I have just declared them all until I have a chance to sort through them a fix the bug.

And by the sprite_routine() are you referring to the way you drew the imps in your Ray Caster program.

Thanks for the help, I haven't ever used C before and I haven't done any normal programming since last year.. (just been messing around with command prompt, getting it to crash my brother's computer)

I will go over some tutorials and source code after school and to change up the code a bit and possibly try and use vertices so it's easier to make shapes.

[bwang]

sprite_routine() is a non-existent routine for drawing sprites. Someone needs to write it (not very hard, just loop over the elements of the array and draw pixels).
malloc() will not work the way you are doing it. Integers should not crash the calc; can you post your original code?

[yoshi13]

I changed the program so the integers no longer use malloc. I am going to take a break from text routines and the paint program I am working to relearn C since I have spent so much time using Java and C++ and find it hard to go back to a lower-level language.

Thanks for the help, I hope to be more useful in the future,

[DJ Omnimaga]

I hope you don't give up on calc stuff

[yoshi13]

Nah.... I have atleast 2 and a half years left using the calc to I will try and keep going to then... :]

[DJ Omnimaga]

Aaah ok good to hear, hoping you continue a bit afterward too (like some of us) even if not as often (I release new stuff like once a year)

[willrandship]

Here's my common+.h The only difference for now is the keymappings, but I plan on adding touch support later, and maybe keypad detection.

Suggestions/Comments are appreciated, and I will likely change it for reasonable suggestions, especially bugs and key names.

To use as your common.h, just rename it to be so, removing the plus. Everything should work fine, just keep your regular common.h as a standby.

EDIT: Updated, removing + from 84 keymapping. now it's KEY_84_ENTER instead of KEY_84+_ENTER

[DJ Omnimaga]

Basically, is it to make the Nspire keypad have a key layout similar to the 84+ one? I would like this so I don't have to constantly switch when Calc84maniac releases his emulators

[bwang]

I don't think its good style to use '+' in the key names. You should change them to just KEY_84_*.

[willrandship]

Not quite what I was thinking, more that programs can support either without having to be reassembled. I'm thinking you'd have a few generic keys, like KEY_ENTER and KEY_UP, while if you need more controls you switch over to KEY_NSPIRE_THETA and so on. This would be the most helpful with the touchpad, since many keys are labeled the same. Using KEY_NSPIRE would require the Nspire Keypad, but it could support both the touch and the original, sans sin, cos, tan, and any other changes.

Can the touch's keypad support more than 16-directional input? I'm curious if it's really an upgrade, since the original keypad can only support that much.

I updated the Common+.h in my last post.