My image compression/decompression is not working properly

So while I were writing a image player, I had to compress images so they wouldn't be so slow loading. However, the displayed image is not the same as before (well, expect from the colors changing to 8-bit). The whole image is messed up. I don't know if it's the compressing or the decompressing. So if anyone can help, then it would be appreciated! I have a public key for a project containing the compressor and the viewer. Also, there is a test image there too. Public Key: XDNY3QJ EDIT: Run the 320X240TO8-BIT first, then run 8-BITTO320X240. EDIT2: It's working now. Though if someone can optimize this it would be really appreciated! (it's slower than loading GRPs normally) Also there is a 512x512 one too. That one takes REALLY LONG. BTW, I have included precompressed images too so you don't have to experience a long wait.

^{WHY ARE YOU USING RRRGGBBB?!?!?} Integers are 16 bits...

Integers are 16 bits...

Wait what really? An edit: Err 16-bit integers can be 65535, while 32-bit integers 4294967295 (unsigned though).

So I think I figured out why it's happening: the values being read are high: for example, when the color red is being ANDed, it gets a rather big number. I don't know how to fix this without making reading slower right now, but I'll mess with some stuff to see if it helps

_pfshhhhh Integers are signed two's-compliment 32-bit (-2147483648 to 2147483647, whole numbers only, % suffix). A 32-bit color-code pulled from a GRP is in the hex format &HAARRGGBB. _{Keep in mind that the 32-bit codes are simply a level of abstraction: GRP in reality works in 16-bit &BRRRRRGGGGGBBBBBA color.}

I optimized it a fair bit. Key: 73KKXPDX Images not included. For the decompressor:

• Multiplies were replaced with left-shifts
• I%*4 was stored to a variable T% so you don't have to do it 4 times
• LOAD[I%,J%] was assigned to a variable C% because array access times are slower than variables
• The R%, G%, and B% arrays were replaced with individual variables (see above)

These were all minor changes. I didn't change the algorithm at all. For the compressor:

• Same changes as above where applicable
• Instead of using string operations, only left-shift and OR were used to concatenate the pixel values
• Instead of using the array NEW$, a single int C% was used as the intermediary

Things got very much faster on this end. Here's a math tip: for all non-negative numbers less than 1073741824, left-shifting by n bits is equivalent to multiplying by 2ⁿ. Similarly, right-shifting by n bits is equivalent to integer-dividing by 2ⁿ. In the case of right-shifting, the operation will work on all numbers (due to the sign fill), with one caveat: shifting negative numbers will never fall below -1. Bit shifts seem to be faster than multiplies, so this helps out in a pinch. EDIT: Bitwise operations (shifts, AND OR XOR) only work on integers. Reals passed to them are clamped to integers.