Transparency in DynamicSprites + Improved Error Handling

[TheMagician]

The thread-title sounds bigger than the issues really are 

I just want to bring up an issue again that has been discussed HERE.
If you draw a semi-transparent image onto a DynamicSprite which has a transparent background then the image is tinted with the purple transparent colour.

Also I noticed that when you call Delete on a DynamicSprite that has a ViewFrame* pointing to it then AGS (the game) crashes without giving information on what has caused the crash. Of course there is the internal error message but a small hint for the user would be nice.

[Pumaman]

Well, there are two possible scenarios when you're drawing an image onto a dynamic sprite -- you might want it to be alpha-transparent against the current sprite, or you might want it to copy the alpha channel.

I suppose adding an option to copy the alpha channel instead of actually alpha-drawing it would be the best solution to this.

Also I noticed that when you call Delete on a DynamicSprite that has a ViewFrame* pointing to it then AGS (the game) crashes without giving information on what has caused the crash. Of course there is the internal error message but a small hint for the user would be nice.

The problem is there's a potential performance issue here, if every time you deleted a dynamic sprite AGS had to go through and check whether you had assigned it to any view frames. Maybe this is something that it could do only when Debug Mode is enabled, thus preventing it from slowing the game down when you build the final version.

[TheMagician]

I'm afraid I didn't quite understand the difference between the two scenarios. Right now there is now way to draw a semi-transparent image onto a transparent DynamicSprite, correct? Well, I'm sure your suggestion will solve the problem

Don't bother about the error handling. I was just happy to find out what had caused the crash and posted it here right away. If it has an impact on performance it's really not worth the hassle. After all I learned something while figuring out the cause of the crash - I don't want to keep other people from making the same experience 

[GarageGothic]

CJ, when you say "copy the alpha channel", do you mean the same effect as DynamicSprite.CopyTransparencyMask? If so, I don't think it would help achieve the effect intended. What's really needed is some kind of additive - not sure that's the right word - alpha support where for instance two smoke particles can be drawn on top of each other with the final sprite still be semi-transparent, but more opaque than if only one smoke object had been drawn.

[monkey0506]

What appears to be happening with the "alpha drawing" is that the two alpha channels are just canceling each other out. That's why if there was nothing behind the image that it's giving the flattened pink background. If the alpha channels could in fact be merged together (additive alpha channels) instead of destroying each other then presumably this would resolve the issue altogether. IMO they shouldn't replace each other, but they shouldn't cancel each other out either. Perhaps an enum like:

Code: ags

enum DrawingSurfaceAlphaMode {
  eAlphaNone,
  eAlphaSame,
  eAlphaMerge,
  eAlphaReplace
};

Then a parameter could be added with default of eAlphaNone (or perhaps eAlphaDestroy...that sounds more fun! 8)) to copy the current behaviour, eAlphaSame would let the alpha channel stay the same as the original, eAlphaMerge would combine the two alpha channels, and eAlphaReplace would replace any existing alpha channel with the new alpha channel.

That would provide the most flexibility when drawing the sprites onto each other, but it might also be more difficult to implement something like that...

[Pumaman]

At the moment the DrawingSurface.DrawImage command will draw the sprite alpha-transparently onto the surface.

For example, if the drawing surface consisted of an opaque image such as a door, then you could use DrawImage to alpha-transparently draw an alpha-channeled door handle sprite onto the door and it would look fine.

The problem comes if the target image is not opaque, since then any partially transparent parts of the source sprite will be alpha-transparently drawn against the pink transparent colour of the background, and you end up with partially pink pixels.

Therefore the current behaviour of DrawImage is correct in the scenario where you want to construct an opaque image by alpha-transparently drawing other sprites onto it.

However, if you want to construct an alpha-transparent sprite which you then want to use as an object graphic, for example, the current transparency handling won't give the result you expect. Something like monkey_05_06's suggestion is probably the best solution since it would allow you specify which type of behaviour you want.