It looks like playdate.drawFPS doesn't use the color I set in playdate.graphics.setDebugDrawColor when it's called from playdate.debugDraw. When I call it, it still renders in black & white.
This is on macOS 12.2 with v1.9.1 of the SDK. Is this a bug, or expected behavior?
test-debug-draw.zip (4.0 KB)
I think this is because drawFPS most likely uses the text system, which doesn’t use system “colors” at all—Playdate fonts are just a series of images. The color APIs are mainly meant for drawing geometric primitives.
Thanks for this idea. I hadn't realized text was just images, and that images are drawn differently than shapes.
However, it still looks like there's still something either buggy or "special" about the drawFPS call. I've changed the example to show gfx.drawText properly rendering text in my debug color, while drawFPS still shows in black & white. So even if it is using text to render it, it should show in transparent pink, right?
test-debug-draw-pink-text.zip (27.6 KB)
I think I've got it. It's less that drawFPS is special, and more that fonts are special.
In your code, you never load a font. drawText() uses the default font, which probably respects setColor() somehow. I'm not entirely sure how, since it's still only a sequence of images; but I assume something about its drawMode lets the color come through.
If you switch to loading a font, you'll get the same behavior as drawFPS:
Since Playdate fonts can in fact contain two colors (black AND white, in addition to transparency) setting their "color" would be a little strange, so I wouldn't expect it to work. Since the system font is known to be single-color, it's probably not a problem that its color can be set.
This might reveal some deep-down issue in how the system font is drawn, so I'll file it. In the meantime, can you get away with a non-tinted fps counter? I've never had a problem with it myself 
