Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI-Nspire => Topic started by: Matrefeytontias on June 02, 2014, 06:07:45 pm
-
Hey guys,
So Hayleia, pierrotdu18 (from TI-Planet) and I were kinda used to nSDL, but as we encountered speed and portability difficulties (like nSDL_LoadImage returning 16-bits surfaces only) we thought of doing our own graphics lib. So far it does work pretty well ; here are the implemented, tested and working features :
- Double-buffering via a few functions, init, two kinds of update and deinit
- Some fixed-point (24.8 ) maths routines : multiply, divide, fixed to integer, integer to fixed, fixed cos, fixed sin, 2D rotation of a point by an angle
- Buffer-level routines : clear, fill
- Pixel-level routines : getPixel, two kinds of setPixel (R5G6B5 and RGB)
- Sprite-level routines : drawSprite, drawSpritePart (draws only a part of a sprite), drawSpriteRotated (rotates a sprite by an angle)
- Full compatibility with monochrome and color Nspires, with automated conversion of colors
That's it for now, but of course we will add more and more routines to make it the best lib for Nspire ! :)
Attached are the two files you need to use the lib.
-
YAY. Now I can update nVVVVVV to be more awesome!
Good work!
EDIT:
Bug report time! drawSpritePart() has some compile errors :P It should be
void drawSpritePart(unsigned short *source, int _x, int _y, Rect part)
{
int x, y = _y, w = part.w + _x, h = part.h + _y, z = part.x, t = part.y;
for(y = _y; y < h; y++, t++)
{
for(x = _x, z = part.x; x < w; x++, z++)
{
if(getPixel(source, z, t) != source[2])
setPixel(x, y, getPixel(source, z, t));
}
}
}
EDIT2:
Do you think you can give a tutorial on how this works? I'm having trouble getting this to work.
-
Wow, I don't really know how you can have trouble making it work :P
But I'll make a tutorial anyway. Just know that images must be an array of unsigned short and have the following format :
- Width in pixels
- Height in pixels
- Transparent color
- Pixel data in R5G6B5 format
Rect is a struct made by 4 components : x, y, w, h. Set them to tell which part of the sprite you want to draw.
Run initDoubleBuff() at the beginning of your program ; if it returns anything else than 0 it's not good, so quit.
Run any of the two switchBuffers() to update the screen.
Run deinitDOubleBuff() at the end of your program.
Double-buffering involves 2 buffers, of course. So you can restore the first on the other with switchBuffersRestore(). This has a use if you don't redraw the whole screen each frame.
I think that's it.
-
Seems interesting, although from the name, at first I thought this was a math graph utility. :P
-
In fact, you just have to init() at the begining of the main, and to deinit() at the end. Everething else is done by the lib. When you draw, it goes on the current drawing buffer, and you just have flip() to exchange the buffers. (two buffers are created, and we switch back to the backupBuffer at the end because we use 16bpp for monochromes, and backupBuffer is in 4bpp (2*4)).
For the moment, we haven't done many drawing functions but we are working on it. However, I rather like our images format.
-
So Hayleia agreed that I port his Jetpack Impossible to use this lib and to post the code here as an example :)
The TNS works on both color and monochrome calcs with seemless difference.
-
Seems interesting, although from the name, at first I thought this was a math graph utility. :P
Yeah, they didn't ask my opinion for the name, I find it quite ridiculous. I was thinking more about "n2DL" like "2D Lib" :P
Seriously, couldn't a poll be added for the name ? Because I say it's ugly and DJ_O says it's misleading so in any case it is not good.
Also, welcome to Omnimaga pierrotdu18. You can introduce yourself here (http://www.omnimaga.org/introduce-yourself!/).
-
Well I guess we can add a poll.
And by the way, I just attached my code, which includes some of my work and some revisited functions by pierrotdu18 and Hayleia. Overall, my versions are faster, but I encourage you guys to post your own versions so we can take what's better out of several versions.
-
Oops, I forgot to replace switchBuffers() by switchBuffersRestore() in the Jetpack Impossible code after I implemented it x.x fixed now, download again two posts above.
And Hayleia we didn't ask you because you weren't there and we wanted to post the lib anyway :P
-
My vote kinda goes to n2DL, but I'd make it n2DLib so people can see "oh look there's a 2d lib for nspire", thus gaining more attention.
-
Good point. Adding that to the poll. I'm also thinking about putting that lib on Github so everyone can push things to it.
-
But I already voted "other (please specify)"
So if a mod could remove my vote please?
-
You can remove your poll, I checked the box.
-
True. I liked n2DL because we historically created that lib because of problems with nSDL, but n2DLib is not uglier and is clearer for people who don't know the history of that lib.
-
Actually I forgot to check that box so I recreated the poll with this time the box checked.
-
Okay, I assumed that n2DLib was the name everyone wanted (it can be changed anyway), so I created a Github repo here : https://github.com/n2DLib/n2DLib/
Feel free to submit pull requests if you have interesting things lying around.
Also, Hayleia, you are invited to join both Github and the developers group :)
-
nTropy2D.
(The number of puns we can do with Crash Bandicoot bosses and nSpire are just fantastic.)
-
You do spell it Nspire or just nspire tho. Not nSpire. Do you want to kill me by abusing my OCD? You bad boy.
nTropy seems nice tho :D
-
I third the nTropy2D name.
Also lol @ocd aeTIos. :P
-
I don't dislike nTropy2D, but except the "2D" part, I don't see the link with our lib. I just see a link with thermodynamics -.-
So yeah, if there is a link, that name doesn't bother me. Otherwise, n2DL and n2DLib are good to me. But nFastGraphX isn't :P (and no one seem to disagree, seeing the poll :P)
-
I find nTropy2D very ugly (and thermodynamics-ish), so I'll go with n2DLib, as does the results of the poll say.
-
Well entropy = mess. With this lib you mess (pun intended) with the display to create more or less of a mess. :P
But yeah, not really the good name. Though some software is named weirdly (I'm looking into uWSGI and it has a "Zerg" mode :P).
-
New features are regularly added, especially for geometric drawing. Since the purpose of this library is to allow us to make the fastest possible functions, we wanted to ask you if you had any suggestions, if you wanted us to add some features that could be useful to everyone or especially to yourself, so that this lib can be as practical, diverse and wide as possible.
Some radical changes have also been made with the gestion of the buffers, but the functions are still the same and there aren't any changes user side.
But I let matref be more precise, since he's the one who modified the functions.
-
Nobody answers?... :-[
Did I say something bad? ???
:w00t:
-
Well no, what do you want them to say ? :P
Anyway, you should instead say that you added geometry functions, like lines, wireframe polygons and filled circles and ellipses ;)
-
I wanted them to propose us some features we could add to our project... But obviously, I wasn't clear... :P
And indeed, I added those functions ;D
So, could you suggest features to add to our library? (I hope I'm clear enough... :P )
-
So by the time of the last update we fixed many things making the lib faster (for example always allocating a second buffer for the screen so it can be accessed faster than this latter), and I just added a drawString() function :D
By the way, I also wrote an extensive documentation.
Code is still at the same place : https://github.com/n2DLib/n2DLib (https://github.com/n2DLib/n2DLib)
Attached is screenshot of the example program running :)
-
nice, the drawstring should come in handy for debugging and stuff :D
-
Cool to hear ! Updating now.
I'm probably gonna add the lib as a submodule. :P
-
I am answering a post that is in the Tetris topic because of offtopciness.
Seriously though x) yeah I arrived last, but hey, don't make it look like I only worked on buffer support or you're still working on it --' with pierrotdu18 we're working on many routines and we're still harassing you for you to dev with us <_<
Well I don't want to make it like it's the end, it's just that I don't know what happened next :P
Also, it's true that I kind of vanished away, but it is because of final exams, then moving back to my parents', then preparing a future move back to a flat -.-
(also, I don't like your coding style and I don't know shit about GitHub, only about git :P )
-
Coding style eh ?
/me mumbles something about having harassed aeTIos about that. :P
-
I don't know what you're talking about. ???
:trollface:
-
So since I hated that C# + GUI utility to convert sprites (yuck) which required manual intervention after the conversion, I made a very quick thingy in Python. Requires Python 3 (maybe it can work on version 2, no idea), and Pillow.
-
Well thanks for that, but I don't like asking users to have Python installed to run things - for example I don't have Python installed.
EDIT : wait I do have it, but I don't have that Pillow thing
-
I'm not forcing you to install/use it. It's just that it's more handy and is scriptable. Also I realize I forgot to tell you how to use it. :P So just call the script, passing it your sprite (can be any format as long as Pillow recognizes it). It uses the color in the top left corner for transparency.
-
I mean, I certainly want to use it, but I don't want to install extra stuff. That's why a simple .exe is better.
-
Erm, I'm not on Windows so I can't make it. :P
-
Well I'll take care of that then. A quick C + SDL program will do it (have to do things first though).
-
I could integrate support for the SDL/n2dlib format in my ConvertImg tool, I'd have to include better transparency support anyway and an option "-format=ngl" or "-format=sdl" wouldn't hurt.
-
Yeah that would be cool, moreover having a single conversion tool would be easier =] so I leave it to you ?
-
Just to be sure: The format is a uint16_t array with width, height and transparent color as the first 3 16bit values and every pixel from top left to bottom right appended?
-
Exactly.
-
For n2DL, yes.
And for nSDL support, just stick a "0x2a01" at the beginning of the array generated with the n2DL format.
-
And the now-4th byte must be 0x0000 (in place of the transparent color).
-
So 0x0000 as transparent color means no transparency?
-
No, it's just that for nSDL, there should be this before pixel data :
0x2a01, width, height, 0x0000,
-
So 0x0000 as transparent color means no transparency?
Nope, it means that nSDL will load that, then you'll have to set the transparency in your program, for each sprite, nSDL will probably put it the way we do instead of that 0x0000 and then you'll have transparency.
-
So, ConvertImg should work now, it supports all three formats (nSDL, nGL and n2DLib) and two of them are of course untested.
It fully supports every file format Qt supports, if it's a file with transparency the transparency will be replaced by a unique new color, the lowest color that isn't already somewhere in the image. Link to the windows version: https://github.com/Vogtinator/ConvertImg/releases/tag/v0.9
For other OSs you need to compile it yourself: "qmake . && make && sudo make install"
-
Okay so I tried this with --format=n2dlib, and it doesn't set the correct transparency value. Actually, it doesn't set any value at all, it keeps being 0x0. nSDL format works fine though, thanks for this =]
-
Qt ? Is it still scriptable ?
-
Of course it's not, it's a proper executable, exactly how I like them ;D
-
What I'm asking is : can I use it in my makefile ? Scriptable = usable programmatically.
-
Oh sorry. Actually it can't be used in another way.
ConvertImg --format=[n2dlib | ngl | nsdl] in [out]
-
Oh cool. I'll see how it works out in my setup. That script I made was actually designed with a specific purpose in mind. :P
-
Okay so I tried this with --format=n2dlib, and it doesn't set the correct transparency value. Actually, it doesn't set any value at all, it keeps being 0x0. nSDL format works fine though, thanks for this =]
Well, 0x0 can be the correct value. I just tried it and for a small picture with just a black pixel in the center it works and picks the next available one.
What I'm asking is : can I use it in my makefile ? Scriptable = usable programmatically.
I'm using it in my Makefiles and it works without problems: ./ConvertImg --format=ngl blockselection.png blockselection.h
-
It's not available. I use 0x0000 in my image. Also, personally I would rather want the tool to use the top-left corner pixel as transparent color, because all of my images I ever used did that.
-
Ah, but you make a .h for each sprite ? I >> all my sprites into a .c and let makeheaders work its magic, then link the .o with the tns.
-
It's not available. I use 0x0000 in my image.
Hm, could you send me your test picture then?
Also, personally I would rather want the tool to use the top-left corner pixel as transparent color, because all of my images I ever used did that.
Trust me, it's much easier to use proper transparency and not worry about it. PNG FTW!
-
I used the little image I did in 3.14 seconds to demonstrate n2DLib's drawSpriteRotated function. Attached ; it gave me this :
//Generated from example.bmp (output format: n2dlib)
static uint16_t example[] = {16,
16,
0x0,
0xf81f, 0xf81f, 0xf81f, 0xf81f, 0xf81f, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xf81f, 0xf81f, 0xf81f, 0xf81f, 0xf81f,
0xf81f, 0xf81f, 0xf81f, 0x0, 0x0, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0x0, 0x0, 0xf81f, 0xf81f, 0xf81f,
0xf81f, 0xf81f, 0x0, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0x0, 0xf81f, 0xf81f,
0xf81f, 0x0, 0xd5d5, 0xd5d5, 0x0, 0x0, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0x0, 0x0, 0xd5d5, 0xd5d5, 0x0, 0xf81f,
0xf81f, 0x0, 0xd5d5, 0xd5d5, 0x0, 0x0, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0x0, 0x0, 0xd5d5, 0xd5d5, 0x0, 0xf81f,
0x0, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0x0,
0x0, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0x0,
0x0, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0x0, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0x0,
0x0, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0x0, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0x0,
0x0, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0x0,
0x0, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0x0,
0xf81f, 0x0, 0xd5d5, 0x0, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0x0, 0xd5d5, 0xd5d5, 0xd5d5, 0x0, 0xf81f,
0xf81f, 0x0, 0xd5d5, 0xd5d5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0x0, 0xf81f,
0xf81f, 0xf81f, 0x0, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0x0, 0xf81f, 0xf81f,
0xf81f, 0xf81f, 0xf81f, 0x0, 0x0, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0xd5d5, 0x0, 0x0, 0xf81f, 0xf81f, 0xf81f,
0xf81f, 0xf81f, 0xf81f, 0xf81f, 0xf81f, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xf81f, 0xf81f, 0xf81f, 0xf81f, 0xf81f,
};
As you can see, I usually use 0xf81f as transparent color.
-
Well yes, but no PNG in n2dlib.
-
A bmp doesn't have transparency so it uses the default value, if you convert it to a png and erase the background it works.
-
Oh nice. Looks like I wasted some time. :P That was a quick script anyway, I picked up some more Python along the way so no biggie.
You should change the default to magenta though.
-
Bug fixed, for images without transparency it uses a color which doesn't appear in the image, so it's entirely opaque as you would expect.
-
Well, the point was that for example with my image the magenta 0xf81f pixels were transparent <_< for instance I don't feel like re-editing all of the 80 images nKaruga uses to convert them from magenta to alpha .-.
-
/me prods Matref with imagemagick.
-
I have no idea what you're talking about.
Alright so back on-topic, I did my best at removing every branch and well, I can't really say if speed changed because it's always insanely fast on GS calcs, someone with a color calc will have to try it.
http://www.mirari.fr/eTV6
-
convert input.bmp -transparent 'ff00ff' out.png
That should take a bitmap and convert it to a png, while considering any of the magenta pixels as transparent. Change the hex to change the background color.
This is the imagemagick convert command. It's an extremely powerful image manipulation tool.
-
Well, I already have PNGs, but they have disabled alpha channels and have magenta pixels instead. But I'll try that.
-
You should be able to use a PNG as the input for the same effect, and you can set it up for bmp out if that's what you want. It autodetects the desired type based on the filename. (There's an option if you want to specify, but for this it's not necessary)
-
Hey grate lib, but in my opinion there should be a function that loads a image from a file, so i made a function that does that. Maybe you want to include this function in to you lib.
unsigned short* imageLoadFromFile(char *path){
FILE* readFile = fopen(path, "rb" );
if(readFile == NULL){
return NULL;
}
fseek(readFile, 0L, SEEK_END);
int size = ftell(readFile);
fseek(readFile, 0L, SEEK_SET);
unsigned short *array;
array = (unsigned short *) malloc(size);
if(array == NULL) {
return NULL;
}
int i;
for(i = 0; i < size/2; i++){
array[i] = fgetc(readFile) << 8;
array[i] += fgetc(readFile);
}
fclose(readFile);
return array;
}
-
If a load-image-from-file function must be written, it will load an image from a .bmp file. Nobody puts an image into a raw file, much less decompressed R5G6B5 image data. Besides, the function will have to deal with the BMP format, what your function doesn't do.
If you think that could be a good addition in the lib, then I'll probably work on an all-BMP loading function.
-
Well i wrote a program which converts any image to the raw data and write it to a new file, but you're right a function that loads a .bmp and does the whole conversion would be much better. xD
I just thought the possibility to store the images in files and load them dynamically would be good.
-
Bump,
I implemented the first non-trivial, actually useful feature in n2DLib : interpolation of any number of points on a curve !
Basically, given arrays of X coordinates, Y coordinates and times, calling interpolatePath(Fixed || Float) generates a function that passes by every point you gave at the instants you gave. Pretty nice for predefined enemy paths for example !
I did a version that uses n2DLib's fixed-point numbers if you prefer speed over accuracy, and also a version that uses "normal" floating-point numbers if you want better accuracy - note that the latter is around 50 times slower though, even though it's the same code.
For those who forgot it, the lib is there : https://github.com/n2DLib/n2DLib
Also, I'll let you guess which one is the floating-point one :
(https://img.ourl.ca/lagrange.png)