Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: Eniripsa96 on February 04, 2010, 04:42:14 pm
-
Well, the formula method cannot work, because i found one that actually worked to an extent, created an image that resembles it but it wasnt perfect, or close to perfect so I will just have to start from scratch again and hope to find a new method
-
Sounds cool. You'll have to put a cap on it somewhere, as huge lists of matricies take up a ton of RAM. I'd use a matrix, with a max-cap of 50*50 (22511 bytes). Good luck!
-
Yeah, your going to need to find some sort of compression technique, as a list can only hold 999 elements, and there are 5795 pixels on the screen.
If you wanted to use an assembly lib, I'm sure xLib would be very helpful for this program, with its handy sprite manipulation, although i can understand if you want to code it yourself :)
-
Builderboy, you mean 999 elements, right?
-
I think he does. Builderboy, are you in a hurry?
-
I tried doing that but fitting an entire picture doesnt work, ive resorted to making a list of each spot that is shaded in, giving a value for each pixel, like the top right pixel (0,62) would be 1 and such, however i think ill have to make some formulas for making the movements of the picture much more complicated though >_>
At least it will give me something to do during math class lol
-
I think he does. Builderboy, are you in a hurry?
Haha, no i was using my iTouch in class. :P
* fixes all my horrible mistakes *
* Goes off in search of more iTouch posts *
-
I made something like this a while ago, but it did a bit more than moving/cropping. I choose to use a Matrix as my preferred storage method. The problem is as the other said though, size. I'll be interested in see what solution you come up with. =)
-
haha! i think i came up with a way that takes very little memory to store the picture. I'm going to store a row as a large number, in 1s and 0s like binary, 1s being the pixel is shaded, 0 being it not. Extracting could be like setting A to the X value you want to get, then doing iPart(L2(y)^(x-1 to get it to the x digit and beyond, then iPart(L2(y)^x)/10 to get the spot right above it, then subtracting the second one from the first one to get it, this is a possibility and hopefully it works.
Memory-wise, it stores an entire row for a mesley 9 bytes, so the list in whole would be 579 bytes, and thats less than a picture's normal storage value o.O
I hope this works :)
Note: the y is the column # and the L2 is the list
-
It would work, but only if numbers were store with huge amounts of precision. Unfortunatly the best compression like that yields only 12-14 digits (depending on how you do it; I think 14 is impossible to decompress) because of the way variables are stored. Thus: 63*95=5985 /13=460.385 So to compress a whole picture, it would take 461 list elements and with those at 9 bytes each is 4149 bytes total. I'm sorry that this dosn't do much for you other than smashing your hopes, but it could still be useful-It's a lot easier to manipulate than a picture variable. If you decide to move pictures around this way, it's still a great idea. Good luck! :)
-
oh, i changed it a little, typed it in, and it did extract the single number :D
instead, its iPart(L2(Y)/10^(x))-iPart(L2(Y)/10^(x-1))/10
maybe this will work after all :)
quite the annoying formula though >_<
EDIT: Fixed Formula ._.
EDIT: dang...found a glitch....back to editing it
-
If you where to use xlib/celticIII you could just use the sprite command to do it. But this is interesting. I would suggest hex, but that would be really slow x.x how about converting tw binary lines to integers? Like 0010=2 and 1001=9, kind of like binary, but this would be faster due to the fact that no strings would be involved.
-
Formula was proven faulty
-
so I found a way to compress the data of three pixels down to 1 byte...000=0 100=1 010=2 110=3 001=4 101=5 011=6 111=7
you can then use your method of saving to store that instead of 0=off 1=on
-
That's pretty cool Eeems, but wouldn't it be pretty slow?
-
yeah it is a little slow, but not that much slower at storing then 0 and 1, all you do is have a loop like this:
Delvar F
For(A,X,X+3)
F+(1+(A=X+3))pxl-test(Y,X+A
Endand then F has the value in it (although I can't remember if my logic on the F+... line is right x.x I'd have to look later...
-
I was thinking in compressing by making numbers like:
Compress 8 pixels with the fake binary numbers 1, 10, 11, 100... to 11111111.
And what about compress 24 bits into one number?
-
That could work. Also another way to "compress" the list is to use imaginary numbers (eg: 10+i5) and you would use the real() to grab the first part and the other one, for the second part.
-
Hmm, maybe doing that vertically would work since 63 is divisible by 3, making a few loops and such, that is a possibility. I'm going to fool around a little more and see if i can discover anything else. If not, I'll try that.
However, i do not know if my method can extract anything besides a 1 or 0 because its based on rounding, which 2 rounded is the same as 1 rounded, so i would have to change it for that.
Hmm....if i check for each spot along a small line, then make each one multiply a preset value of 1 in a list spot by a prime lie the first pixel multiplies it by 2, second does it by 3, third by 5, etc, then use a factor checking section to tell what pixels to shade...that could possibly work as well.
-
Hmm....if i check for each spot along a small line, then make each one multiply a preset value of 1 in a list spot by a prime lie the first pixel multiplies it by 2, second does it by 3, third by 5, etc, then use a factor checking section to tell what pixels to shade...that could possibly work as well.
I love doing this; I think you can compress any combination of 13 1 or 0 numbers like this, but I'm unsure.
Note: Eeems, a compressed list is twice the size of a reagular list.
-
True (that's why it was in quotes :p) but it allows you to get around the only 999 items issue :p