Premultiplied Alpha support

[AdamsLair]

• Evaluate whether Premultiplied Alpha could easily be integrated into the existing rendering pipeline. Assumption: This is no big deal.
• Add "Premultiplied" option to Textures as a preprocessing step which can be activated on a per-Texture basis.
• Add "AlphaPremultiplied" DrawTechnique
• Update automated SpriteRenderer creation to honor their Textures Premultiplied option.

[BraveSirAndrew]

I've just committed some code to my fork of Duality to add premulitplied alpha support. You can check it out here - https://github.com/BraveSirAndrew/duality/commit/c9833ed4314e34301bcfe0f18af84111f29a9cab. If this approach works for you, I can submit a pull request, or if you had a better way in mind to do it, I'd be happy to change this.

[AdamsLair]

Huh.. introducing a second Pixmap Layer is actually pretty clever. A nice thought indeed. Not sure about adopting it into the main branch though, I'd like to spend some more thought on the topic in general.

[BraveSirAndrew]

Cool, thanks:) This is working well for us now, but I'm interested to see how it can be improved upon. Incidentally, this also optimizes the loading of textures, as colouring transparent pixels or premultiplying only needs to happen once, and then it's stored in the pixmap, at the expense of double the storage, but that seems like a good trade off, especially as the load time of our levels increases. When we package for a platform, we can strip out the first layer from pixmaps automatically or per specific texture, so it doesn't increase the download size.

[AdamsLair]

• Ideally, Texture's shouldn't preprocess pixel data, since it increases loading times a lot.
• BraveSirAndrew has a great workaround by simply adding auto-generated Pixmap Layers and using them as the Textures source data.
• However, this approach is prone to errors and may result in conflicts when extended due to its index-based nature. Pixmap layers should be refactored to counter this.
  • Use a dictionary approach where a single or a collection of layer(s) is accessible via string key.
  • The dictionary mapping allows storing arbitrary pixel data within a Pixmap with a much lower likelihood to cause conflicts.
  • Storing a collection of layers for each key allows storing mipmap layers as well, in case they're precalculated or modified specifically. Re-evaluate whether this is really necessary though.
• Pixmaps could preprocess source data (color transparent pixels, scale, premultiplied alpha, ...) and store the result in a separate layer, which is used by the Texture.
  • This would also mean to move some of a Textures settings to the Pixmap (SizeMode)
  • There could be a hardcoded accessor for processed data, similar to the "MainLayer" property right now. New accessor names could be something like "SourceData" and "TargetData".
  • When deploying the project without editor support, all SourceData layers could be stripped to reduce download size.
  • Alternatively, all TargetData layers could be stripped and be re-generated and saved on the players machine on first startup. That would still allow him access to the full editing functionality.

[ilexp]

Note: This has to be revisited and re-conceptualized now that a lot of import functionality has been shifted out of Resource classes and into importers using the new AssetManagement API. Also, in the develop-3.0 branch, automatic atlas generation for Pixmaps has been moved into the import step, leading the way to potentially adding options for pre-multiplied alpha preprocessing.