Could the game compiler that converts the image files to the playdate 1-bit format also automatically add transparency to the images?

It would make things really easy, for me at least, if I could just draw bitmaps in black and white, with another colour, such as green, where I want transparency, and just have the compiler convert the green to transparent.

I know this would conflict with the compiler's basic function of converting colors to black and white based on a darkness threshold. But for the way I work, this would be a handy feature.

perhaps there could be a flag for pdc.exe that tells it to convert anything not damn close to black or white into transparent.


I'm interested to know why your green can't be transparent?

Anyway, you can implement this stort of thing yourself in a pre-process stage. Run it either as a single command, in a shell script before pdc, or as part of a make file.

I prefer to use ImageMagick for this sort of thing, it's a cross platform command line tool:

magick input.png -fuzz 10% -transparent "rgb(0,255,0)" output.png

fuzz is how close to the specified colour to operate on. I use it because the colour picker in some apps report different values due to monitor calibration.


I can make green transparent, it's not a problem.

My request was just something that would be nice to have.

It's just because I'm doing some prototyping on my work pc, and I'm using ms Paint, because I don't really want to install too many programs for personal use.

It's really not a biggie. Just something I would like.

Thanks for the suggestions.

1 Like

Ah, I see.

I do know there are some planned changes and improvements to pdc that are still to come.

That's cool.

I won't be upset if this doesn't get implemented.

Just one of those "if you don't ask, you don't get" situations.

Thanks for chatting.

1 Like

That's a brilliant idea, I love it! It's so perfect and simple I thought maybe we'd tried it before and there was a reason we don't do it now but I can't find anything in the slack logs. I'll add that and give it a bit of wiggle room like Matt does. I've been bitten in the butt by color spaces too many times now. :stuck_out_tongue:

1 Like

Wow, I'm glad you think it's such a good idea.


Congrats on getting started on shipping out consumer units. Very exciting.

Added that, seems to work well. It considers "green" to be r < 0x10 && b < 0x10 && g >= 0xf0, and will only turn that transparent if the image doesn't already have transparency. Also, if the image is a GIF (which uses a color table instead of per-pixel rgb values) it requires that the image have no more than 4 colors, and only one matching the green test above.

Thanks again for the great idea, I think this will be really useful for a lot of people!


Very nice.

I'll be looking out for the next SDK version release.

Hi Dave,

I've just been checking out the new version of the SDK.

It seems like this new feature wasn't included.

Is that the case?

No, it didn't make it in. :frowning: We have a huge backlog of merge requests because the support load is crazy so today's update only had the urgent fixes. Me, I would have named it 1.10.1 to make it more clear it's a bugfix release vs feature release but it wasn't my call..

Sounds like there will probably be a 1.11.1 soon, so fingers crossed for 1.12? Hopefully we can catch up soon. I hate having features ready but stuck waiting for release.

1 Like

Probably smart not to rush everything out. Take your time, and make sure everybody is happy that everything is in tip-top condition, so nothing goes tits-up.

Thanks for the reply. I'll keep my eyes on the release notes for future versions.

Just wanted to thank you for this suggestion as it comes quite in handy

1 Like