Blend Mode Fail

RaiSoleil · 2009-10-29 23:18:00

Just upgraded to Windows 7 and, inexplicably, Game Maker's blend modes aren't working. None of my blending-dependent scripts are acting as normal. I reinstalled GM7, yes. I can't tell if the problem is with Windows, GM, or Dx11 (my hardware only supports 10, but that shouldn't matter, afaik), but something's failed somewhere in the pipeline. I can't describe exactly how they're not working, but it seems to be limited to blend modes and alpha channels, which points the finger at DirectX. Google has nothing to say.

Any ideas how to get it working again?

Just as a test, please try this: Canvas Test. Sorry it's not a gmk, but it's the last known working version I think (decompile it if you want). RMB to squirt, MMB to spray, then LMB to push paint around. It looks like this for you, right? Well, it looks like this for me. Awful.

xot · 2009-10-30 02:07:28

When I looked at the pictures, the first thing I thought was that leftover texture data is corrupting the surface. When I tried the demo, I had some similar looking problems.

Test 1:
[Image deleted by the ImageShack gods]

I replaced every occurrence of surface_create(w,h) with a script surface_create_clear(w,h,color,alpha) which simply clears the surface using draw_clear_alpha(argument2,argument3) after it is created. That seemed to solve the problems I was seeing.

Expand//  surface_create_clear(w,h,color,alpha)
{
    var s;
    s = surface_create(argument0,argument1);
    if (s != -1) 
    {
        surface_set_target(s);
        draw_clear_alpha(argument2,argument3);
        surface_reset_target();
    }
    return s;
}

Test 2:
[Image deleted by the ImageShack gods]

That's a really nice looking effect, by the way.

IamCalle · 2009-10-30 10:02:46

I got the same artifacts until I tried what xot suggested, I guess that is all you need to make things work.:)
Edit: Very good looking effect, indeed.

Last edited by IamCalle (2009-10-30 10:03:25)

xot · 2009-10-30 11:47:11

I probably should have mentioned that I'm using Windows XP and DirectX 9.

RaiSoleil · 2009-10-30 15:38:55

Interesting. I've actually never encountered the problem in your Test 1 or, for that matter, ever had any problems with leftover data on my surfaces. Maybe Vista/Dx10 fixed the problem?

At any rate, I'm afraid the script doesn't help. It's a problem that appeared specifically when I moved from Vista to 7. But thanks for the attempt, xot - I think I have a better idea what the problem is now. You know how drawing to a surface with bm_normal sometimes overwrites the alpha channel of the area underneath? Now it's as if, when I use draw_set_blend_mode_ext(1,1), it fails just like bm_normal does. However, it seems like draw_set_blend_mode_ext(1,5) is working just fine, which makes me think it's something like the surface's alpha level is being overwritten regardless of what blend mode is used. [Edit:] I'm using (1,5) in a variation of GearGOD's metaball effect, which multiplies a surface by itself 3 or 4 times . . . now that I think about it, it seems the alpha channel is also being ignored for this mode too, but it's harder to tell because the surface's alpha channel is just getting replaced by the alpha of a copy of itself - in other words, the alpha isn't changed at all, which in itself supports the hypothesis below. If it were working properly, the new alpha would be A1*A1/255.

Essentially, the blend mode is applied as normal to the RGB of the surface but not the A, and the blend mode for the alpha channel is always (bm_one,bm_zero), or something close.

Probably the standard bm_normal+surface bug and my bug are related.

Last edited by RaiSoleil (2009-10-30 17:11:54)

IamCalle · 2009-10-30 16:54:59

(Gosh, I completely forgot the fact that Win. 7 and Dx 11/10 is far away from Win. XP and Dx 9. cool oh excuses... smile )

That is some interesting stuff RaiSoleil, is Mark O. aware of this (potential?) ...bug?

xot · 2009-11-03 10:01:59

the standard bm_normal+surface bug

You've been talking to th15, haven't you? It's not a bug, it's a feature.

At least I don't think it's a bug. The way alpha changes on the destination when drawn to with bm_normal is logical and predictable. When he talks about NVIDIA bugs, I'm thinking it works as expected. I admit I don't have blending experience using other APIs. And whatever bugs he's seeing, maybe I'm not getting them. But I am using NVIDIA hardware and I haven't seen anything happen on this machine that couldn't be corrected logically. That's not to say that there aren't bugs in your DX10/11 drivers, I'd be surprised it there weren't.

Now it's as if, when I use draw_set_blend_mode_ext(1,1), it fails just like bm_normal does.

Shouldn't that blend mode (bm_zero,bm_zero) set all channels to 0 (transparent black) in the destination?

I'm using (1,5) in a variation of GearGOD's metaball effect, which multiplies a surface by itself 3 or 4 times . . . now that I think about it, it seems the alpha channel is also being ignored for this mode too, but it's harder to tell because the surface's alpha channel is just getting replaced by the alpha of a copy of itself - in other words, the alpha isn't changed at all, which in itself supports the hypothesis below. If it were working properly, the new alpha would be A1*A1/255.

Hmmm. Blend mode (bm_zero,bm_src_alpha) should do this:

Source Destination Resulting Pixels Pixels Pixels R = [0.97] * [0.00] + [0.97] * [0.75] = 0.73 G = [0.25] * [0.00] + [0.25] * [0.75] = 0.19 (#BA3054) B = [0.44] * [0.00] + [0.44] * [0.75] = 0.33 A = [0.75] * [0.00] + [0.75] * [0.75] = 0.56

If alpha isn't changing, something definitely isn't working right. Unfortunately, there is no way to get the alpha of a pixel directly from the surface using something like surface_getpixel(), so it's hard to precisely verify these predictions.

RaiSoleil · 2009-11-03 15:26:59

xot wrote:

the standard bm_normal+surface bug
You've been talking to th15, haven't you? It's not a bug, it's a feature.
At least I don't think it's a bug. The way alpha changes on the destination when drawn to with bm_normal is logical and predictable. When he talks about NVIDIA bugs, I'm thinking it works as expected. I admit I don't have blending experience using other APIs. And whatever bugs he's seeing, maybe I'm not getting them. But I am using NVIDIA hardware and I haven't seen anything happen on this machine that couldn't be corrected logically. That's not to say that there aren't bugs in your DX10/11 drivers, I'd be surprised it there weren't.

Mmm, I disagree, but the effect is hard to pin down exactly. If a sprite has an alpha channel, and it gets drawn onto a surface that already has an image on it, the result should be a mix, right? But I've had problems in the past with the image underneath the sprite getting erased completely and replaced by the sprite, as if the blend mode was (bm_one,bm_zero) instead of bm_normal. Can't test the problem anymore, though, because everything's borked no matter what mode I use. I'd like to think it was my DX drivers, but in that case it should affect everything, unless GM uses an outdated blend mode method (GM6/7 is based on DX8, I recall) that no other programs use and has been corrupted in DX11, which I find unlikely.

xot wrote:

Now it's as if, when I use draw_set_blend_mode_ext(1,1), it fails just like bm_normal does.
Shouldn't that blend mode (bm_zero,bm_zero) set all channels to 0 (transparent black) in the destination?

My bad. I meant (bm_one,bm_one), and forgot that blend modes start at index 1, not 0.

xot wrote:

Hmmm. Blend mode (bm_zero,bm_src_alpha) should do this:
Source Destination Resulting Pixels Pixels Pixels [u] R = [0.97] * [0.00] + [0.97] * [0.75] = 0.73 G = [0.25] * [0.00] + [0.25] * [0.75] = 0.19 (#BA3054) B = [0.44] * [0.00] + [0.44] * [0.75] = 0.33 A = [0.75] * [0.00] + [0.75] * [0.75] = 0.56
If alpha isn't changing, something definitely isn't working right. Unfortunately, there is no way to get the alpha of a pixel directly from the surface using something like surface_getpixel(), so it's hard to precisely verify these predictions.

That's correct. It's the idea from here: http://www.messy-mind.net/2007/2d-metaballs/

No, the alpha isn't changing . The colors themselves get multiplied by the alpha value (where alpha != 1), though, which is what makes the image I posted a funky mix of black and red.

icuurd12b42 · 2009-11-03 17:36:10

All I have is a blank near white (egg shell) screen.

RaiSoleil · 2009-11-03 18:44:26

Um ... ?

I presume you refer to the paint demo? But no part of it involves the color of eggshells, I'm afraid. Did you try RMB or MMB?

icuurd12b42 · 2009-11-04 00:30:52

I feel rather dumb. I hit every key on the keyboard and left click and nothing happend. I never thought of trying RMB or MMB...

It works for me... Vista 64, ATI Mobility Radeon HD 3870

xot · 2009-11-05 17:48:40

I was wondering a couple things.

First, have you tried any of these surface related demos and do they work correctly for you?
http://www.gmlscripts.com/forums/viewtopic.php?id=1674
http://www.gmlscripts.com/forums/viewtopic.php?id=1688
http://www.gmlscripts.com/forums/viewtopic.php?id=1657
http://www.gmlscripts.com/forums/viewto … 1959#p1959

Second, since alpha seems to be the thing not working right, can you work around it? I think it is possible to do this effect a little differently without the need for alpha. Render/generate your blood (it's blood isn't it?) white on black with the entire surface completely opaque. Use ext(bm_dest_color,bm_src_color) for your contrast passes. Then to draw it on the screen, first knock out the background by drawing the surface to it with ext(bm_zero,bm_inv_src_color), and then draw it again with ext(bm_one,bm_one) and a red color blending. Something like that, I haven't tried it.

RaiSoleil · 2009-11-05 20:09:19

Good idea. Report:

UV hijinks: everything ... works fine. I think. Love the tiling example.

Gradient transition: Doesn't work at all. Higher contrast does nothing, higher % just makes the thing darker.
http://i307.photobucket.com/albums/nn29 … t103-1.png

Raster transform lighting: it seems to have trouble with the smearing.
http://i307.photobucket.com/albums/nn29 … t101-2.png
http://i307.photobucket.com/albums/nn29 … t102-1.png

The other light engine thing: the shadows get tinted funky colors.

This canvas/fingerpaint/bloody murder thing is actually something I'd forgotten about long before my move to Win7, so I'm not going to worry too much about fixing it, but the problem shows up in a lot of places where there's no easy substitute. It has, however, made me give more thought to some of my other ideas that don't use surfaces and stuff.

xot · 2009-11-05 20:25:36

You seem to be having a lot of problems with surfaces. I hope it's just a temporary driver problem and not a look at the future of GM's special effects ability. sad

XNA, Unity, and now UDK are all looking mighty appealing lately.

RaiSoleil · 2009-11-05 21:11:55

I recently ran into the FlatRedBall and Ice Cream XNA engines. And then there's Aziel. I'm kinda tempted to just jump ship on GM and move to an XNA engine if I want to do anything more graphically intensive than a Mario clone. Or possibly Torque2D/TorqueX.

GMLscripts.com

#1 2009-10-29 23:18:00

Blend Mode Fail

#2 2009-10-30 02:07:28

Re: Blend Mode Fail

#3 2009-10-30 10:02:46

Re: Blend Mode Fail

#4 2009-10-30 11:47:11

Re: Blend Mode Fail

#5 2009-10-30 15:38:55

Re: Blend Mode Fail

#6 2009-10-30 16:54:59

Re: Blend Mode Fail

#7 2009-11-03 10:01:59

Re: Blend Mode Fail

#8 2009-11-03 15:26:59

Re: Blend Mode Fail

#9 2009-11-03 17:36:10

Re: Blend Mode Fail

#10 2009-11-03 18:44:26

Re: Blend Mode Fail

#11 2009-11-04 00:30:52

Re: Blend Mode Fail

#12 2009-11-05 17:48:40

Re: Blend Mode Fail

#13 2009-11-05 20:09:19

Re: Blend Mode Fail

#14 2009-11-05 20:25:36

Re: Blend Mode Fail

#15 2009-11-05 21:11:55

Re: Blend Mode Fail

Board footer