3
\$\begingroup\$

SDL (and other toolkits) can use color keying to make a certain color in an image transparent. Alternatively, you could load a PNG image that supports transparency.

When should I use which?

\$\endgroup\$
5
\$\begingroup\$

JPG is lossy. Don't use that for sprites -- you will end up with nasty artifacts that will look bad. There's a couple reasons you might want to use colur-keying, but they're a bit lost in todays hardware. Taking a quick look at color key advantages:

Pros

  • They use up less disk space -- there is no alpha channel to store
  • By consequence, their memory foot print is lower because of this
  • Can work for older technologies that do not support alpha channels

Cons

  • Transparency cannot be spotted easily in more subtle spots of images
  • You lose a color you can use from your palette
  • This can be computationally expensive in some cases.

A note about CPU complexity

When you use a color key mapped image, you are still converting this to an image with alpha channels when it reaches the video RAM in all cases. You will need an additional channel to record these pixels as an alpha of 0. Due to this, a pass must be made on the image at load time to account for this. Unfortunately, the consequence for this is a higher overhead during loading. The time may be of no consequence for few images, but it is worth taking note.

In the end, PNG transparency is used mostly in todays standards game as it easy to use and widely decodable for the most part (such as with SDL). Most popular game engines no longer support color keying, this method was mostly used in older engines and systems.

Off the top of my head, libGDX and XNA both do not support color keying. However, the latter does support it on its content pipeline. Which leads into another interesting option...

You can process it at build time

If you really wanted to use color keying to save disk space because you were working on a tight budget disk space wise, you can always choose to store the assets in a color key format and then have them changed and built at build time to the format that is most appropriate.

Concluding

However, in the end do not use JPG for something like a sprite. If you want to use JPGs, use them on something that lossy behavior is acceptable, like 3D textures or photographs of real objects where picture blur is more or less unnoticed.

\$\endgroup\$
  • \$\begingroup\$ "The time may be of no consequence for few images, but it is worth taking note." - I'd be surprised if it takes any significant time at all. The I/O overhead of loading a spritesheet off disk is likely to outweigh a color->alpha pass, based on performance tests I've seen loading PNGs vs DDS files; the overhead of decoding the PNG was made up for by the smaller file size. Generating high-quality GPU-friendly compressed image data and all the mipmaps pushed things back in DDS' favor quite a bit, of course, but those are significantly more complicated than color->alpha conversion. \$\endgroup\$ – Sean Middleditch Apr 8 '14 at 18:59
  • \$\begingroup\$ @SeanMiddleditch Hm, I'll have to take a look at some benchmarks then! I must admit, I'm not well versed in the I/O timings. At any rate, my assumption is the time is probably negligible either way. If you can provide more insight, I highly encourage you to edit this or write your own answer. \$\endgroup\$ – Vaughan Hilts Apr 8 '14 at 19:11
  • \$\begingroup\$ I'd have to do timings on this specifically to say anything more specific than I already did. The majority of your answer is spot on. :) \$\endgroup\$ – Sean Middleditch Apr 8 '14 at 19:20
  • \$\begingroup\$ With more complex formats like PNG the file size shouldn't be much different, since it compresses large surfaces of a single color very well. Color keying is more of artifact from the past for when inefficient file formats and paletted images were the norm. \$\endgroup\$ – API-Beast Apr 8 '14 at 21:53
  • \$\begingroup\$ @Mr.Beast: Sure, I'm just saying that the file I/O time is going to dwarf any minor processing time. If you're streaming the files properly the time to convert the image data from RGB to RGBA is probably to be negligable. Especially if you use a GPU shader for it. \$\endgroup\$ – Sean Middleditch Apr 8 '14 at 22:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.