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

SDK Get Help
, ,
1

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?

Thanks!

2

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.

3

That’s interesting.

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