AGS 4: Remove "has alpha channel" sprite flag, and related parameters

[ivan-mogilko]

Resolves #1808.

In AGS sprites have a "has alpha channel" flag which tells whether the image's alpha channel should be used or not. Certain drawing operations depend on it; for instance a blending op or conversion from the sprite to texture may be performed in one or another way depending on the combination of source and destination surfaces' alpha flags.

The purpose of this change is to remove this flag and those checks altogether, and imply that 32-bit images always have a valid alpha channel. This will simplify a lot of things internally, and probably will make life easier to user who uses true color graphics by default. The only downside I see is that forcing an opaque image will become a responsibility of game author, either when preparing an image for import, or when generating a dynamic sprite in script (in which case one would have to clear the sprite with some color then blit the image on it to ensure there's no transparency).

What is done

1. Removed "has_alpha" and "opaque" parameters internally from textures (DDB) and drawing functions.
2. Removed SPF_ALPHACHANNEL flag from sprites. All 32-bit sprites now assume alpha channel.
3. In Script API removed "preserve alpha" parameter from DynamicSprite.Create and CreateFromExistingSprite functions; removed HasAlphaChannel from DialogOptionsRenderingInfo. NOTE: I don't know if we want to keep old-style functions in ags4 to ease the project migration. If yes, then I'd have to put old function variants back.

What is kept

Kept "Import alpha channel" in the Sprite Import dialog. For now it works simply: if set then do nothing, if unset then the sprite will be made fully opaque by filling alpha channel with 0xFF.
If not wanted, this setting may be removed later as well.

The "magic pink" color constant is still kept internally even in 32-bit. This is unfortunate, but may be necessary for DrawingSurfaces, because currently there's no way to set alpha for a DrawingColor, or in SetPixel/GetPixel, so people will have to use COLOR_TRANSPARENT (see #1514). Unless I'm missing or misunderstanding something here... I may look afterwards if it's okay to completely remove it and any related conversions for 32-bit.

---

TODO:

• fix Editor compilation;
• blank room template generates with RGB background, it seems, which turns into fully-transparent. Besides that, need to ensure that RGB backgrounds are converted into RGBA with opaque alpha?
• any "has alpha" options in the script API.
• double check that in the sprite import disabled "use alpha channel" should result in filling bitmap with opaque alpha;
• ensure that all special opaque sprites in the engine have proper alpha channel values when created.
• ensure that all the primitive drawing operations in the engine and script use color with opaque alpha.
  - [ ] perhaps merge all the draw_xxx_sprite functions, because they seem to do almost same thing now (may be done separately later).
• investigate what happens when upgrading older project with both "has alpha" and "no alpha" 32-bit sprites.
• investigate what happens to room backgrounds when upgrading older project (from both open rooms and closed rooms 3.6.0).
• ensure that 16-bit / 8-bit games display sprites properly (direct3d/opengl runs always in 32-bit display mode).

ensure that all special opaque sprites in the engine have proper alpha channel values when created.

This includes:

• room background (currently it must be opaque) [WORKS - but only ags4 editor keeps opaque alpha]
• fadeout surface
• fx (tint) sprite
• default dialog options

[ivan-mogilko]

Returned to this PR, rebased to resolve conflicts.

Most of the engine change is done, what's left is fixing nuances when using generated images and drawing primitives, then fix the sprite import in the Editor.

[ivan-mogilko]

Note: old editors seem to save 32-bit room backgrounds without alpha channel (so after this change these would be considered fully transparent).

After this change the Editor would keep proper alpha in backgrounds. I am not particularly certain if this is a correct behavior though. Maybe we should consider room backgrounds to be strictly opaque. OTOH if we don't - that in theory gives an opportunity to see one room viewport through another, if room background has "cuts".

[ivan-mogilko]

Note 2: in regards to drawing primitives (using Bitmap class and allegro functions), apparently the alpha channel is secure there and always set to 0xFF if color set by __my_setcolor, MakeColor or Bitmap::GetCompatibleColor (latter two call __my_setcolor).

[ivan-mogilko]

This is ready for review and testing. Updated the first post with details on what was done.

[ivan-mogilko]

Had to remake something & rebase: reverted an "opaque" flag in textures, because it's not related to the "has alpha" flag, and is used primarily for optimizing bitmap->texture conversions for images that are known to never have transparent pixels: room backgrounds, debug surfaces, built-in gui, fx effects.

This flag may be reviewed and refactored later, as a separate task.

PS. tested remaining cases, all seem to be working.