I have a hand-drawn pic on the ti-84+, and I want to know what pixels are currently on, and store that, is there a good, and efficient way to do that?
I can't do a 62x94 matrix b/c it takes up too much memory, what else can I do?

You can have a list with 5828 elements. But, it would take up the same amount of memory.

Really, it boils down to repetition. You could create an algorithm that outputs something like this:


Code:


Where element 1 statements whether the pixel is on and for how many pixels. When the script hits a different pixel value (or the end of the screen) it creates a new entry. This case the next two pixels are off, the next pixel is on, the next four are off, the next ten, etc.

Or even better: you don't need to precise each time the 0 and the 1 since if you change your number, you change the state too. There is no point doing {...,1,13,1,15,...}, you would just do {...,1,28,...}
So your list can be compressed as {13,2,1,4,10,...}
Just use a convention for the beginning, like here, it would start with 13 black pixels. And if you wanted 13 white pixels, just add a zero at the beginning to say that there are zero black then 13 white

Oh, duh. That makes sense! I still feel that you'd need to specify the starting pixel color as it could vary. So, starting with a 1 or a 0 to specify first pixel color then alternating from there.


Code:

Your method is easier to think about but mine saves some space when you start with black (and saves nothing compared to yours when starting with white).

Oh, I didn't fully understand that. Now I do though!
Clever

For what it's worth, the algorithms that you guys are describing are all in the family of Run-Length Encoding (RLE). It's used in some lossless image-compression schemes (like the one you guys are describing!), but it's on the easy/ineffective end of the spectrum for complex images. Read more about RLE on Wikipedia. Sidebar: lists take 9 bytes per element, while strings take 1 byte per character. Encoding your RLE numbers in a string instead of a list would save space at the expense of encoding/decoding speed.

1)I'm using a TI-84+ SE, not the color calc.
2)I'm trying to do this in BASIC
3)You lost me within the first reply
4)I'm asking for some real code, but thanks for making me think.

Just a quick question since my topic got deleted: Is Detached Solutions still making Apps/programs, or are they "dead"?

I wrote something that sounds extremely similar to what you're looking for a while ago (RLE-based and includes a demo of saving/restoring images): RLE2. You might find it useful.

I'm pretty new to programming, so this is probably less of an efficient solution than a framework or starting point.

This is based on comicIDIOT's original response; tracking the position in a string is tricky and I attempt it later.


Code:


Final notes:
◘I'm not sure if "," will parse the comma as a literal character or not
◘I don't know how to create a box for code; I didn't see a forum rules thread

1) that compression method would be very difficult to implement on the color calc, and would not work with 1's and 0's for on and off.
2)yes, we are talking about basic code, no one mentioned assembly.
3)lets say you have an image that looks like this:

Code:

This isn't a full image, but you get the picture (pun intended).
So first, there are 0 consecutive 1's at the current location, so you put a 0. Then you put the number of consecutive 0's, so you put 3. Then you put the number of consecutive 1's, so 2
In the end, it would look like this:

Code:

4)I don't feel like writing code for you, and I doubt anyone else here does either.
quick question: Think about this: the last post on their site was in 2009, which was four years ago. Do you think they are still together programming without posting for that long? Did they just stop posting? Did they forget to post?

We don't typically just give you code, you have to write it, and we help you fix mistakes and give you pointers on how to make your code better.

We tend to prefer to give people a push and let them think for themselves, not write all their code for them.

DBrak, your commas in quotes are valid; they'll be added to the string successfully.

Willwac, can you try and adjust DBraks code to be more streamlined after we help you understand what's going on? Where did we loose you? Elaborate as much as you can so we can add emphasis on the parts you aren't understanding.