Designing DEFY Paint

Here are some barely useful notes to understand

"incomplete tools/functions list"

The functions prefixed with "[ ]" are functions that are not in the left toolbox.

"rough GUI design draft"

The boxes off the sides of the bottom screen are meant to slide onto the screen when corresponding face buttons are pressed, then they can be interacted with via touch. Something I couldn't decide on is whether the menu bar should be on the top screen or touch screen, but I think i'll just make that a changeable setting. Anyway, I have multiple questions to ask about how to best program and optimize for this program. I don't want to make thread after thread for questions if i can avoid it.

Do you have any ideas on how you will save the canvas data? Vectors, raw image array, compression, etc?

Do you have any ideas on how you will save the canvas data? Vectors, raw image array, compression, etc?

Yes, storing the instructions to re-create the layers in a large image array. I feel like it's likely to take up less data to store those than raw image data. There's a problem though, it will certainly take MUCH more time to re-create the image when changing layer visibility.

Yes, storing the instructions to re-create the layers in a large image array. I feel like it's likely to take up less data to store those than raw image data. There's a problem though, it will certainly take MUCH more time to re-create the image when changing layer visibility.

If the program is for drawing mostly geometrical shapes (which it looks like it is), then I'd reckon it'll work. If it's detail drawing this program will undertake, then I'd suggest some other means of data storage. And not to forget, should your drawing program perform things to the canvas such as rotations, dilations, and translations, the way by which the data is stored is essential for such operations to be executed timely. A series of drawing instructions (coordinates and vectors), like you suggest, would work best for those.

I do intend for this to be used as a bitmap detail program with layer support. Perhaps then, they should be stored as bitmaps in memory then? I would be comfortable with 8 active layers. Is it efficient to store them in an integer array, with two colors stored per element? 16 bits per pixel.

Each of the 8 layers of its own integer array? That's a ton of space to use.

You're saying to create an array of 320*240, and store it as a 16-bit bitmap. I think this would give you the perk of using GLOAD to load the image data (so long as the array is one-dimensional), which is significantly faster than any other means. Is there actually enough space to create 8 (320*240) 16-bit bitmaps?

You're saying to create an array of 320*240, and store it as a 16-bit bitmap. I think this would give you the perk of using GLOAD to load the image data (so long as the array is one-dimensional), which is significantly faster than any other means. Is there actually enough space to create 8 (320*240) 16-bit bitmaps?

There is enough space for 8 16-bit 512*512 bitmaps. I'm intending for this to support full graphics pages.

One thing I'm thinking of is storing all layers and "undo's" in arrays until the memory is too low, and it will delete "undo's" until there is enough space to store a new layer or undo. Btw i'm thinking of storing "undo's" as only the sections of the bitmaps changed before they were changed, so they may all be different sizes, stored along with their positions and dimensions. I'm also thinking of doing some background compression of the undos so they might get smaller, but it probably won't help much in practice.

Here's another idea for the top screen.

Going back on a suggestion MasterR3CORD had, perhaps semitransparent tools would be nice, as well as anti-aliasing.

When I increase an array's size continuously, I get an "Out of Memory" error around when a quarter of the "FREEMEM" is used. How do I handle that?