Ok. I get it. How do bitwise operations enter this?
I want to set one of these bits to 1.
So:
(1 << k) | n
where k is the bit, and n is the number
So it is the bitwise OR?
Maybe we could use base 10, where having a 0 means no pixel, and any other number means the pixel is filled?
Well then we run into the property limkit. Properties can only store numbers up to 9,999,999,999 or something around there.
We could use a smaller base like 6.
32 bits is right on the limit though… and if I made the display smaller to account for base 6 or something, the display wouldn’t be high enough quality.
We could use like more properties? Like 2 or 3 properties per row?
Now the property limit becomes a problem. This display is a color display, so it uses four properties per row. 4x32 is already at the limit, so I’m gonna have to optimize it as well.
Maybe we’ll get too many properties.
So a row of text requires the following data right now for it to work:
1792387926
642554162
439642321
How would you get colors? RGB? Hexidecimal?
Ok.
So 3 bits per pixel now.
Three bits across three numbers, yeah. Also, here is some code that translates emojis into the binary.
(translator - Replit)
Wait, the numbers are:
1011100101010100000111010000011001100111011110111101111100101000000110000011101110011010001
However, black is the first one, and both ends aren’t 000.
I didn’t send you three rows, I sent one. So look at the first bit in each 32 bit number. The first bit in all three is 0.
It’s split into R, G and B.
I do not understand a single word you all are saying.