LoginLogin

GSAVE2

Root / Submissions / [.]

MZ952Created:
Download:CKXNNXLF
Version:Size:
Alternative GSAVE/GLOAD combo meant to reduce the large memory usage constraint associated with GSAVE. Instead of storing raw pixel data, an algorithm searches the graphics page for rectangles of like-color, however large or small. It then stores the end points of the rectangles along with their associated colors. For average case images, such as drawings made from a palette of colors, this can reduce array sizes from hundreds or millions of bytes down to several thousand. File also contains some fast-ish functions for drawing blocky lines with thickness. Changelog
  • v. 1.0.0 (05/06/20) initial release
  • v. 1.0.1 (05/23/20) fixed bug in GLOAD2 where copy transparent flag failed if image array was empty.

Instructions:

GSAVE2 Transfer source page, X,Y,Width,Height, Transfer destination array, Redraw image flag The saving process is destructive, meaning it overwrites the image as it compresses it. If you wish to, you can set the Redraw image flag to 1 to redraw the original image after the algorithm is finished compressing it. (Basically, asking it to call GLOAD2 on the finished product) GLOAD2 X,Y, Image array, Copy mode There is no need to specify a width and height, that information is stored in the GSAVE2ed Image array. Copy mode determines whether to redraw transparent pixels. 1=yes, 0=no.
ProgramsTools
rando#1
Cool but slow on source with multiple colors, like default sprites
MZ952#2
Replying to:rando
Cool but slow on source with multiple colors, like default sprites
Yeah, definitely. It's good for mainly drawings. While you can fit maybe 10 or 12 GSAVEs of the graphics screen into memory before it fills up, with this--compressing drawings with common colors and relatively low complexity--you can easily fit hundreds or thousands. Actually, the colors have relatively little to do with how much memory is used. Color data are stored only once as a list at the beginning of the array. It's mainly complexity that's the issue.
MZ952#3
There is an optimization that can make GSAVE2 nearly twice as fast, but negatively impacts the resultant array size.
rando#4
Replying to:rando
Cool but slow on source with multiple colors, like default sprites
Hmm
MZ952#5
Replying to:rando
Cool but slow on source with multiple colors, like default sprites
Er, you must mean in terms of saving an image. To be honest, I didn't really care how long it took to save the image (doesn't mean I didn't optimize it as best I could though), my focus was mostly on the return array size, shrinking it as much as practical while maintaining fast redraw times. But, it is complexity that kills speed.
rando#6
Replying to:rando
Cool but slow on source with multiple colors, like default sprites
Yeah Drawing an image is still slow enough to admire. It's so cool how it's drawn and how it looks. Even then it only takes a few seconds. But yes, saving is super slow.
MasterR3C0RD#7
Here's a question: What if you have a graphic full of random colors? Assuming no color repeats itself, you could be looking at 4-5x the side of original GSAVE. Just something to consider maybe
MZ952#8
Replying to:rando
Cool but slow on source with multiple colors, like default sprites
You must be using an O3DS. Here is the code running on the Switch: https://youtu.be/xItO9ZhLZPk On N3DS, you could maybe pull a 10-12 fps redraw framerate with the test image. The Switch on the other hand, ho-boy, it gets up past the 30-40 fps mark with even some terribly complex images. I'd reckon it draws the test image here easily at near 60 fps.
MZ952#9
Replying to:MasterR3C0RD
Here's a question: What if you have a graphic full of random colors? Assuming no color repeats itself, you could be looking at 4-5x the side of original GSAVE. Just something to consider maybe
Well, yeah, I mean, it would approach 3x the size of GSAVE. That would be a very unwise use of this algorithm. I mean, the best I could do is have the algorithm recognize that it's gone over the memory threshold for a regular GSAVE of that size and just GSAVE the image with a special flag to tell the loading counterpart about how it's given up lol
rando#10
Replying to:rando
Cool but slow on source with multiple colors, like default sprites
No I use a N3DS. It draws fast enough that I can see how it draws, but not incredibly slow.
Midnight#11
This is... strange. I remember envisioning something related to compressing something, based off of the same principals as this (write down the coordinates of the colors, for each color). I don't know if it was anything related to coding -- I really don't remember much at all what it was... but some file format somewhere was very open to being compressed in this way and I one day thought about that concept. ...Interesting.
MZ952#12
Replying to:Midnight
This is... strange. I remember envisioning something related to compressing something, based off of the same principals as this (write down the coordinates of the colors, for each color). I don't know if it was anything related to coding -- I really don't remember much at all what it was... but some file format somewhere was very open to being compressed in this way and I one day thought about that concept. ...Interesting.
Huh, interesting. I probably didn't have anything to do with it lol I came up with this more or less independently while searching for a solution to stowing away frames in my animation app, given the low memory cap problem with SB. (8 mb can actually store a heck of a lot when data is compressed properly, but otherwise...) I wouldn't be surprised if it's applied elsewhere for different applications though, it's a pretty simple idea