Topic: DynamicSprite::CreateFromScreenShot Regression Advice

[Gurok]

Over the past few weeks, I've been looking through a rather large AGS project being migrated from 3.3.3 to 3.4.0. One of the bugs reported was an apparent failure of DynamicSprite::CreateFromScreenShot. I managed to reduce this down to a pretty simple test case:

Code: [Select]

// Ensure alpha blending is set to "Proper Alpha Blending" under settings

DynamicSprite *sprite;

function room_AfterFadeIn()
{
sprite = DynamicSprite.CreateFromScreenShot(); // This should be a screenshot of the room
Button1.NormalGraphic = sprite.Graphic; // Button1 is a button on gGui1
gGui1.Visible = true;
}
Under 3.3.3, the code above shows a screenshot of the room.
Under 3.4.0, the code above shows the background of the GUI (grey by default).

For convenience, I've made test projects for 3.3.3 and 3.4.0 you can download here: http://goo.gl/qOaDFp?gdriveurl
(It's the same code in both projects, just a slightly updated project file for 3.4.0.)

At first, I suspected problems in either of two areas that were changed fairly recently: the alpha blending code or the DirectX back buffer code. A little more poking around revealed that the blending code was fine. I mangled the code a bit, incorporating the stuff that was there before CW's recent changes and the outcome was the same. The reason why screenshots weren't being drawn was a transparent alpha channel (0x00) on screenshots.

I also found the alpha channel was 0x00 in both DirectX 5 and DirectX 9 mode, so I'm tentatively ruling out the back buffer changes. I'm at a loss for the cause or even probable causes of the regression. I also tried to build the head at "3.4.0.1 alpha 2" and while I could build AGS, compiling and running a project crashed the engine :/.

I have a commit I've made here: https://github.com/gurok/ags/commit/fde355548f58c0099573628488afe5207ddeddf3

As I tend to be a bit hasty making pull requests, I thought I'd try asking for opinions here first. The commit fixes the problem, but I'm not sure if it's the right way to fix the problem.

Maybe someone here will have a suspicion of what's causing it and suggest I look at a particular area.
Maybe someone knows why I couldn't build a project with the head from that long ago.
Maybe I'm making a too big a deal of this and I should just make a pull request (it does after all fix the problem).
Maybe someone (CW?) will make a pull request based on this that's a lot smarter.

I just need some assistance here, guys .

[Crimson Wizard]

First of all, the engine must properly resolve situations when the drawn image does not have alpha channel -- regardless of what values are in alpha channel (0, or 0xff). This channel should just be ignored and all image pixels treated as fully opaque.
So, it is not the image (screenshot) that should be corrected, but the selection of drawing mode.

I was planning to set up a proper blender for this situation back when I was fixing magic pink bug for abstauber, but did only part of fix (the case was composition of two mistakes -- an old and new one), because correcting CopyTransparency function appeared to be enough, so I just postponed the second part of fix; I wanted to find out if there is a case that could result in erroneous behavior first.



E: I will apply a patch tomorrow.

[Crimson Wizard]

Gurok, I pushed the fixed blenders to the branch. Now it should not matter what values are in alpha channel if the image has No-alpha flag.
Also it is now speed-optimized for the case when opaque sprite is drawn over alpha-sprite without transparency.

[Gurok]

Oh excellent. This was probably the most critical thing holding up AGD2 and certainly better than my attempt. Thank you so much, CW.