A Short Conceptual Overview of Graphics Rendering

SDK Development Discussion
, ,
1

Hi all,

I've had a Playdate for a few years but am just getting around to developing for it now. I'm fairly new to game development, so I've got to pick up some basic ideas along the way. While I think the reference docs are solid, they don't currently provide conceptual overviews on various aspects of the system. While trying to better understand how the graphic rendering works, I poked around at the API and put together a brief overview. I'm sharing it here in case it's helpful to anyone else: Playdate: Core Graphic Mechanics

I suspect some of the details are wrong. Everything in the article was gleaned from running a few small experiments against the C API. If you have corrections on anything, I'd love to hear them.

Thanks!

3 Likes
2

haven’t read everything but the screen pixels are not represented by a byte in the frame buffer.
A frame buffer byte holds 8 pixels.
The LCD_ROWSIZE gives the number of bytes in a row (eg 52 for alignment reasons).

good write up - a bit verbose maybe

4 Likes
3

Ah! A pivotal correction, that makes a lot more sense. Somehow I totally misinterpreted this when reading the reference docs. I'll have to patch the post. Thanks!

4

This is great! A couple notes:

  1. In your first code snippet, I found it confusing that you used kColorBlack as a constant to define 8 black pixels (presumably 0xFF), because I thought you were referring to playdate.graphics.kColorBlack — and its value is not 0xFF. Maybe use a different name than kColorBlack?
  2. In your paragraph Even though the array contains bytes, just like the frame buffer does, these bytes don’t represent pixels. Instead, each bit within one of these bytes represents a pixel. I found this mildly confusing because it seems to be asserting that unlike the frame buffer, there are 8 pixels in a byte. But if freds72 above is correct, then that is in fact just like the frame buffer.

This is a cool post! Thank you very much for writing it.

1 Like
5

Thank you both for the feedback! It was super helpful. I've finally found some time to update this post with the provided corrections.

I'm a little unhappy with the example code regarding using bitwise operations to write pixels to the screen. In particular:

for(int i = 0; i < LCD_ROWSIZE*LCD_ROWS; i++) {
  uint8_t b = frame_buffer[i] << 7;
  frame_buffer[i] = ~b | kColorBlack;
}

while this is a slight semantic improvement over using byte values directly, it's still pretty clunky. Anyone have recommendations or insight around using bitwise ops for direct pixel modification?

6

that will fill the whole screen - usually not what you want (memset would do a much better job!).

if you want to set a single pixel, something like that will do:

void pset(uint8_t*buf,int x,int y) {
  buf += x/8 + y * LCD_ROWSIZE;
  *buf |= 1<<(x&7);
}