Trouble with bitmaps size 32x32 or almost anyting other than 8x8 (showing up curupted) (SOLVED)

im trying to do a full screen image as a title screen rendered with the drawScreen() function.

the image just comes out with garbage in it. same thing with a 32x32 image.

i know it’s not the bitmap encoders. i have hand made a 32x32 image and when it outputs on screen, it is garbage.

anyone else having this issue?

Moved to the development section. There are some posts covering this. pop on in the IRC channel. Basically look at your sbuffer and realize each char represents 8 y spaces. : )

I still don’t have my hardware yet but from READING the drawImage code it seems to want your image coded in bytes, X to Y. So in BYTE chunks your image (16x16 example here) would look like:

BBBBBBBBBBBBBB (0-15)
BBBBBBBBBBBBBB (16-31)

So the bytes are stored sequentially XXXXX, then +y, then more XXXX. However inside of each byte the bits are painted vertically to the screen. So the first byte might be:

0b00011000 And that would be painted as a vertical line on the first X position:

0
0
0
1
1
0
0
0

If this isn’t helpful then maybe the drawImage routine is entirely broken. I’ll test it once I have the actual hardware.

So it’s not all X or all Y… you’ll never be able to look at your image data 0s and 1s in your source code and “see” the image (not rotated or upside down or anything else)… you can only “see” your imagine one byte at a time, and those bytes are rendered vertically.

Background

The reason for this is because the SSD1306 controller paints the screen one page at a time. There are 8 pages (8 pixels high) going us 64 vertical pixels. Each page is 128 columns. To paint a page you push 128 bytes to the screen and that paints 1,024 pixels. The fastest way possible to get data to the screen is to already have it in bytes and push those bytes. If the image was stored in a format that made perfect (horizontal) sense to someone reading the code then a TON of effort would have to be made by the CPU to first convert and re-store the image before writing it to the screen. If it’s stored in bytes representing vertical sequences of bits then many times it can just be pushed to the screen as is.

Now we could change drawImage to allow you to specify all the vertical pixels at once… so then in your code you could see the image rotated 90 degrees… I’m not sure if that would be better or worse. The thing that can’t be done quickly is to store the data in bits horizontally - since the screen hardware wants the bits vertically.

Would it make more sense to people if the bytes were ordered vertically then horizontally?

EDit: I wonder if there would be some way to use C macros to write the data in horizontal bit form and then the macros converted it to vertical data as it was compiled?

Ive tried your picture with lcd assistant (Link found below) and it worked just fine on my arduboy, I first however loaded your picture up in ms paint/photoshop and saved as a mono bmp so the picture was purely black and white only.

byte orientation set to vertical, as previous guys have said.

LCD Assistant
http://en.radzio.dxp.pl/bitmap_converter/

Using

display.drawBitmap(PositionX, PositionY, ImageTitle,ImageWidth,ImageHeight,1);

Picture on Arduboy

Arduboy

2 Likes

Oh man, thanks for linking LCD Assistant, that’s exactly what I needed.

@Nickpatts thanks! this solved my problem ( and im sure many other peoples problems related to bitmaps) :blush: