Trying to understand frame buffer’s “fill” being zero or one

Hi, I’m just getting started with the SDK, but wanted to directly mess with the pixels in the frame buffer (using the c api) and I’m trying to understand what constitutes a “fill” value for the frame buffer, a zero or a one.

I modified the “Hello World” project update function, which starts out with:

playdate->graphics->clear( kColorWhite )

Then I performed something like this:

uint8_t* dst = playdate->graphics->getFrame();
*dst = 0x80;

Which seems to be giving me the opposite result of what I was expecting to happen. I was expecting that after the frame buffer was cleared with white that all the values would be zero and to draw a pixel that I need to set that particular bit to one, but it seems to be the opposite.

Is a “fill” in the frame buffer zero? So in my case, a dark pixel has a value of zero?

I know that I can invert the display, but then clear( kWhiteColor ) doesn’t have the effect that I was looking because it fills the display with black.

If it is the case that a fill value is zero and a blank value is one, what was the reasoning behind this?


I always have to double check but you are correct, 0 is black and 1 is white.

The reason is that this is the specification of the screen when sending data to the screen, 0 (Low voltage) is to set a pixel as black and 1 (high voltage) is to set a pixel white.

That’s interesting.

Ok, thanks for the clarification. It just makes thinking of the drawing logic… different.