Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => Casio PRIZM => Topic started by: Spenceboy98 on May 03, 2013, 08:09:14 pm
-
I was disappointed when zeldaking never finished his Paint program, so I Decided to make my own!
(http://img.removedfromgame.com/imgs/Paint1.png)
(http://img.removedfromgame.com/imgs/Paint2.png)
(http://img.removedfromgame.com/imgs/Paint3.png)
(http://img.removedfromgame.com/imgs/Paint4.png)
It's got circle drawing(no ellipse), rectangle drawing, line drawing, pen, floodfill, zooming in(plus button), zooming out(minus), has a grid for larger than 3x, and a color picker(hope I didn't leave anything out). It took me a while to figure out how to make it actually draw, but then I realized that I could draw a sprite to the screen and just edit the sprite data. The problems that I'm having is, opening files(.ppf files stands for Prizm Picture Files, I already have saving working okay), rotating image(I couldn't figure out how, I asked in my topic, but no one helped), resizing properly(resize it so the new image doesn't look corrupted and just adds white pixels in those places), displaying the hex of the color in the color picker(it is only displaying the #?), scaling gets corrupted after the displayed pic gets over 115(or something like that) pixels high or wide, and I think that's it unless I forgot.
Here is the opening code(if you can help, it segfaults the calc at the end of the progress bar):
void openFile(char *PATH, color_t *data, int width, int height){
char databuf[5];
unsigned short buffer[sizeof(PATH)*2];
Bfile_StrToName_ncpy(buffer, (unsigned char*)PATH, strlen(PATH)+1);
int hFile = Bfile_OpenFile_OS(buffer, 0);
for(int i = 0; i < height; i++){
for(int j = 0; j < width; j++){
ProgressBar((i*width)+j, width*height);
Bfile_ReadFile_OS(hFile, databuf, 5, ((i*width+j)+2)*5);
data[(i*width+j)] = strtol(databuf, NULL, 10);
}
}
Bfile_CloseFile_OS(hFile);
return;
}
I don't have any code for rotating(90 degree increments), but if you could help, it would be nice.
Here is my resizing code, so if you could help make the output less corrupted:
void resizeImage(color_t *image, int w1, int h1, int w2, int h2){
int w, h;
color_t* holder = image;
color_t* temp = (color_t*)malloc(((w1*h1)*2)*sizeof(color_t));
temp = (color_t*)realloc(temp, ((w2*h2)*2)*sizeof(color_t));
if ( temp != NULL ){
image = temp;
} else {
free(temp);
return;
}
if(w1 < w2){
w = w1;
} else {
w = w2;
}
if(h1 < h2){
h = h1;
} else {
h = h2;
}
for(int i = 0; i < h; i++){
for(int j = 0; j < w; j++){
image[(i*w)+j] = holder[(i*w)+j];
}
}
}
Here is the code for changing the RGB values to Hex(based off of my TI-BASIC program):
char* RGBtoHex(int r, int g, int b, char buffer[7]){
char val[16] = "0123456789ABCDEF";
float a = (r/16);
float c = (g/16);
float d = (b/16);
int e = floor(a);
int f = floor(c);
int h = floor(d);
if(e > a)
e--;
if(f > d)
f--;
if(h > c)
h--;
a = a - e;
c = c - h;
d = d - f;
a = a * 16;
c = c * 16;
d = d * 16;
buffer[0] = '#';
buffer[1] = val[e];
buffer[2] = val[(int)a];
buffer[3] = val[f];
buffer[4] = val[(int)d];
buffer[5] = val[h];
buffer[6] = val[(int)c];
return buffer;
}
And, finally here is my nearest-neighbor scaling routine:
color_t* Scale(color_t *temp, const color_t* data,int w1,int h1,int w2,int h2) {
if((w2 <= 0) || (h2 <= 0)){
return 0;
} else {
color_t* milk = (color_t*)realloc(temp, (w2*h2*2)*sizeof(color_t));
temp = milk;
int x_ratio = ((w1<<16)/w2)+1;
int y_ratio = ((h1<<16)/h2)+1;
int x2, y2;
for(int i=0;i<h2;i++) {
for(int j=0;j<w2;j++) {
x2 = ((j*x_ratio)>>16);
y2 = ((i*y_ratio)>>16);
temp[(i*w2)+j] = data[(y2*w1)+x2];
}
}
}
return temp;
}
I really hope you can help with this. This is pretty much the farthest I've ever made on a Prizm C program from pretty much scratch.
Also, if you help, you get some credit(I'll make an About on the program that lists people who help).
Here's what I have right now:
-Rectangle
-Circle(not ellipses)
-Line
-Dropper
-Fill
-Color Picker with RGB editing(and hopefully hex code editing, but I need to get the hex displaying fixed first) and some preset colors(the same ones from Paint on Windows)
-Resizing(glitchy)
-Zooming/Scaling(glitchy, needs to be fixed; code is in first post)
-Saving(hopefully editing soon if I can get it to work; code is also in first post)
Planning for eventually:
-Eraser
-Select Tool with Copy, Paste, Crop, etc.
I'll take any suggestions if you have any.
-
Looks really good, but I hope you make it better than M$ Paint (basically, don't implement its bugs) :P
What image format will this support in the end? Can we create sprites/tiles, sprite data, images we can re-use elsewhere, etc?
-
Looks really good, but I hope you make it better than M$ Paint (basically, don't implement its bugs) :P
What image format will this support in the end? Can we create sprites/tiles, sprite data, images we can re-use elsewhere, etc?
It saves it in a .ppf file(Prizm Picture File) with numbers from 0-65535 colors for now.
-
More Screenies:
Me changing width(also changed height, but no screenie for that):
(http://img.removedfromgame.com/imgs/PaintW.png)
After drawing zoomed in:
(http://img.removedfromgame.com/imgs/PaintZ.png)
Zoomed out:
(http://img.removedfromgame.com/imgs/PaintOut.png)
Saving(I tried to save, but unfortunately the calc crashed. I'll look into it):
(http://img.removedfromgame.com/imgs/PaintSave.png)
(http://img.removedfromgame.com/imgs/PaintLineDesign.png)
(http://img.removedfromgame.com/imgs/PaintFillGlitch.png)
For saving, you don't have to add the ".ppf"; it does it for you.
Here's what's in a .ppf file(width and height followed by color codes): http://pastebin.com/Fc0qt7aT
Resizing still isn't working right(using my scale routine and resizing array with realloc). I fixed a small problem with my flood filling routine(it used to reset every time I tried to fill without a boundary/border). Saving is incredibly slow and it gets slower as the image gets larger(the larger the image, the slower it takes).
As you can see in the last sreenshot, something weird is happening(my guess is that it is from my fill routine because it starts soon after I start using the fill routine).
-
Very nice. I especially like zoomed in drawing, since it's hard to draw small stuff on such small screen.
-
Nice work! I made a similar program for the TI-89 named Kraphyko, but the 24K limit prevented me from going farther.
-
*BUMP*
Updates:
Faster image saving and loading.
I got it to load a new image. :P
More screenshots(doodles):
(http://i44.tinypic.com/347fvoz.png)
Zoomed:
(http://i44.tinypic.com/288ps4.png)
-
Looks quite nice! :)
-
*BUMP*
I'm experimenting with trying to get it to save BMP. The problem is that I try to open it and it says that it is corrupt.
Here is my saving code:
void saveBMP(char *filename, color_t *data, int width, int height){
BMPHEAD bh;
memset ((char *)&bh,0,sizeof(BMPHEAD)); /* sets everything to 0 */
memcpy (bh.id,"BM",2);
bh.reserved[0] = 0;
bh.reserved[1] = 0;
bh.headersize = 54L;
bh.infoSize = 0x28L;
bh.width = width;
bh.depth = height;
bh.biPlanes = 1;
bh.bits = 24;
bh.biCompression = 0L;
int bytesPerLine;
bytesPerLine = bh.width * 3; /* (for 24 bit images) */
/* round up to a dword boundary */
if (bytesPerLine & 0x0003)
{
bytesPerLine |= 0x0003;
++bytesPerLine;
}
bh.filesize=bh.headersize+(long)bytesPerLine*bh.depth;
int size = bh.headersize+(long)bytesPerLine*bh.depth;
char * PATH;
PATH = alloca(strlen("\\\\fls0\\")+strlen1(filename)+strlen(".bmp")+1);
strcpy(PATH, "\\\\fls0\\");
strcat(PATH, filename);
strcat(PATH, ".bmp");
unsigned short * pFile = alloca(2*(strlen(PATH)+1));
Bfile_StrToName_ncpy(pFile, (unsigned char*)PATH, strlen(PATH)+1);
Bfile_CreateEntry_OS(pFile, CREATEMODE_FILE, &size);
int hFile = Bfile_OpenFile_OS(pFile, 2);
Bfile_WriteFile_OS(hFile, &bh, sizeof(bh));
char *linebuf;
linebuf = (char *) malloc(bytesPerLine*sizeof(char));
if (linebuf == NULL){
Bfile_CloseFile_OS(hFile);
return;
}
int line;
for (line = height; line >= 0; line --){
for(int i = 0; i < width; i++){
linebuf[i] = data[line*width+i];
}
Bfile_WriteFile_OS(hFile, linebuf, sizeof(linebuf));
}
Bfile_CloseFile_OS(hFile);
free(linebuf);
}
Using this website for basis: http://www.siggraph.org/education/materials/HyperVis/asp_data/compimag/bmpfile.htm (http://www.siggraph.org/education/materials/HyperVis/asp_data/compimag/bmpfile.htm)
I don't think loading the data is going correctly. Can someone please help?
-
This isn't the right sub-forum to ask for programming help. You should use the Lua or C programming help section for that, else only people who check Casio stuff will see your request.
-
This isn't the right sub-forum to ask for programming help. You should use the Lua or C programming help section for that, else only people who check Casio stuff will see your request.
Oh. Sorry. I didn't realize. :P
UPDATE:
Now saving and loading BMP's seem to work. It still has the "moving up and out of view" problem, and I have no idea how to fix it. Plus, when loading 24-bit pics it loads backwards. :/
What it does:
(http://img.omnimaga.org//PaintOutofView.gif)
What it's supposed to look like(btw, I drew this on calc(but I converted to png to view here)):
(http://img.omnimaga.org//LINEDESIGN.png)
Hopefully, I'll be able to get it to work and get a demo out soon. :D
-
How do you support 24 bit pics editing if we can only see 65536 colors at once by the way? ???
Also I like how moving the image around seems pretty fast. :)
-
How do you support 24 bit pics editing if we can only see 65536 colors at once by the way? ???
Also I like how moving the image around seems pretty fast. :)
I just saw this post. :P
Anyways, what do you mean by supporting 24-bit pic editing? All I do is convert the image data into an array that gets displayed to the screen.
Also, what do you mean by moving the image around? What is happening in the gif is unintentional(and is caused by my scaling routine for zooming).
-
You mention 24-bit pics in your previous post, which confused me since on a PRIZM it's impossible to display a 24 bit image at all (the max is 65536 colors, not 16.7 million)
As for moving around I was refering to the screenshot. It's unintentional but it seemed fast.
-
I'm thinking about releasing a demo soon. These will probably be the bugs and downsides:
- No loading images too big or re-sizing too big(173*173 is the biggest square you can make; has to equal to or less than 30000 in all because of memory reasons)
- No filling in too large areas(it resets the calc; if you're going to do it, make a few boxes or circles and then fill them one at a time)
- 24-bit pics load backwards(negative heights not handled either)
- The "Save" function doesn't work right(just use "Save As")
- Scaling doesn't let you make it too big(Once the scaled image is over around 112 width or height, it gets glitchy)
New things since I last posted:
- Two colors(you can use the second one by using ALPHA instead of SHIFT; also when picking the color picker too)
BTW, the 24-bit loading works because it converts it to R5G6B5 and it might reduce the quality of the pic depending on what pic you use. It saves as 24-bit, and you don't have to type the file extension in the box. Also, you can't type lowercase, bu this might be fixed in a later version. If you type in the same name as another file, it will replace it.
Hopefully I'm not forgetting anything(I probably am :P)...
-
Cool to hear, I will try when I have some time (or when it comes out) :)
-
Here's a cemetech download link for the Beta.
http://www.cemetech.net/programs/index.php?mode=file&id=957
-
why dont you update the cemetech thread?
-
why dont you update the cemetech thread?
I didn't think about it. Now I have. :P