That was the same issue I had I thought it was working until I realised my string was still 64 long as well

Also, I edited my post above if you are interested in using a list or number for your sprite. It would also be pretty easy to create a tool to give you value for the sprite, too. An example list or number is:
{2172731964,1010991489
or
2172731964+i1010991489

This means you could store a bunch of 8x8 sprites to a complex list and each element is its own sprite.

Complex numbers are of the form a+bi, where i is located at [2nd][.]. If you aren't familiar with complex numbers, here is a quick rundown:

i^2=-1
So if you do (3+2i)(2+i)=6+3i+4i+2i*i=6+7i+2(i^2)=6+7i-2=4+7i. On the calculators, complex numbers can be used and they use 9 more bytes than a real number. Likewise, complex lists use about twice the memory as a real list. However, the advantage is that you can store multiple pieces of data in one var. real(4+7i) will return 4 and imag(4+7i) will return 7.

Well, it isn't hex. Basically, the code is converting the decimal number to binary, but it is being copied to the graph screen where 1 is pixel on and 0 is pixel off.

Oh, I am not going digit by digit, I am using the whole number. For example:
2172731964=10000001100000010100001000111100

Yes, except it is done in 8 digit chunks. Also, the routine I gave copies the binary backwards, just as a heads up.

The code is smaller and a little faster, plus it has the advantage that you can store all of your sprites in a list (or as some other kind of number).

Yes, that is probably the best way to do those.

Now for an update I made a few editors to help me speed up map making and I made a few other miscellaneous adjustments Now you get to see all the shtuff in action >.>