I am working on a system which will remember which color a certain pixel is. I have been trying to get a matrix system to work, but I cannot get very far without running into a memory problem. I tried augmenting, archiving, loops, and nine total matrices spitting the load. Is there a way to store 43,560 (264x165) individual numbers in a way that is easily recalled which does not cause a memory problem?
I tried shrinking the nine matrices into 45x45 's, but it causes a garbage collect every 3 mins (lol)
The only thing i could think of, is making use of the archive memory. I do not think that there is enough memory for all of that data without using the archive.
If you were to use lists, you would need 43 different lists, so thats not an effective solution.
Using matricies could possibly work, if you archived them after creating them
Perhaps you could also use strings. Take the color and store it as a hex value from 0 to F. There are 15 colors, and off which is perfect for hexadecimal. Then, since you have 10 strings, store the first 4356 color values into Str1, and archive it. The next 4356, Str2; etc. This would only work if you had enough free memory for a string that was 4536 characters long however. Since the only limit in the length of a string is the amount of free memory. Since you would know the exact order the points were saved in, to recall them, you would just need to reverse the algorithm. Or to recall a specific one. Figure out which string it would be in, unarchive it, calculate which position you need, extract the value, rearchive the string, and convert the value from hexadecimal to decimal
My concern is that it would take a year to compute one point. Its an idea though!
I'm trying to imagine using the matrices in a such a way that you could obtain data for multiple pixels from a single element of the matrix. So something like a single element of the matrix contains the colors and layout of a 4x4 pixel set. The elements themselves can be an augment of numerical values of the colors, so 1, 3, 9, 3, 12, 15, etc. would look like 010309031215… I can also see it being the result of an algorithm…
I'm not too sure the difference in size between a large matrix with small elements and a small matrix with large elements is significant at all to be a viable option.
The Silver Phantom welcomes you
It does make sense, but I would probably need a set of 8x8 to get somewhere. I'll see what I can do…
I tried 4x4s, 8x8s, and 10x10s, but it still took 9 hours to get a few (correctly colored) pixels. I'm going to do black and white instead until I find something else. Thanks for the input!
Sorry, I totally forgot to respond to this! Regardless of how you do it, it will take a looong time, especially with that size screen. However, using a technique from the monochrome calcs, we can at the very least pack extra data into a float.
I don't have one of these calcs, so I'm not familiar with the pixel commands.
TI floats can hold 14 base-10 digits of accuracy, which is 1014. In this much space, we can hold 11 base-16 digits of accuracy. So you will need 3960 floats. This can fit into two 990-element complex lists. You can store a group of 22 pixels into a complex number like (returned in Ans):
0
For(A,0,20,2
Ans16
Ans+Pxl-Test(Y,X+A)+iPxl-Test(Y,X+A+1
End
To recall from a complex number in Ans:
For(A,20,0,-2
16 ֿ¹int(Ans
Pxl-On(Y,X+A,16fpart(real(Ans
Pxl-On(Y,X+A+1,16fpart(imag(Ans
End
Conveniently, 264 and 165 are divisible by 11, so you could work this algo in either direction!
Z80 Assembly>English>TI-BASIC>Python>French>C>0
And 4 lists would be able to hold the complex numbers if you wanted, correct?