function DatAGS(int image)
{
int x,y;
sprite= DynamicSprite.CreateFromExistingSprite(image);//this is declared on the top of the module
DrawingSurface*dest = sprite.GetDrawingSurface();
dest.DrawImage(x, y, image, 0);//i don't mind x and y being 0,0 for now it works
dest.DrawImage(x, y, image, 90);
dest.DrawImage(x, y+10, image, 90);
dest.DrawImage(x, y-10, image, 90);
dest.Release();
object[0].Graphic=sprite.Graphic;
GG WP EASY NOOBS AGS. Basically, AGS draws this with pink sprites. God knows why. I take a goddamn sam picture and it draws it with pink sprites.
AGS 3.2.11 March.
32 bit game.
I tried a different image but where it's supposed to be empty/transparent, instead it draws pink artifacts 1x1 pixel. The image is drawn well if i don't change the transparency. And it shows okay on an object, but no, when i do DrawImage it hates me.
Well-known transparency bug. There is no real fix for 3.2.1, but the new version already addresses this.
Does it fix it? Or somehow does a more complicated thing?
Double post but the issue persists even with the new AGS Beta.
I read something about a new setting just a few days ago. Maybe ask CW directly?
(http://i.imgur.com/6WSiIp9.png)
Yeah, I did that Calin, the problem persists.
I think you are missing a "preserveAlphaChannel" parameter in the function call:
DynamicSprite.CreateFromExistingSprite(image, true); // <-- notice 'true' here
Probably will work in 3.2.1 as well.
I think AGS hates me. No, the issue persists, it occurs regardless of the importation of the image, i tried making it into a bmp. Issue persists.
You need to import it as PNG with alpha channel, and AGS should ask you whether to use said alpha channel upon import. You also have to set the game to 32bit before importing anything.
Maybe upload the sprites you are using? Personally, I am not sure what's going on there :-\.
Nope, it happens with any sprite. I give up frankly. Drawimage seems to work shitly.
I don't know how this issue may persist for you.
When I added "true" parameter to "CreateFromExistingSprite" in AGS 3.2.1 the result was already completely different: the image went completely transparent (because of the bug in 3.2.1's DrawImage).
When I opened the project in 3.3.0 and set "Sprite alpha rendering" to "Proper...", the image was drawn as expected (90% translucent "aura" surrounding a sprite).
I've used the alpha blending in AGS extensively now and I can report that there are no problems.
My suggestion to Dualnames would be to check that the surface he is drawing on is also 32bit.
It is, frankly I've never encountered this before. I'm willing to hand out the files, it's something I'm doing wrong, and I haven't noticed.
Quote from: Dualnames on Thu 23/01/2014 21:23:13
It is, frankly I've never encountered this before. I'm willing to hand out the files, it's something I'm doing wrong, and I haven't noticed.
Yes, if you may, I am quite intrigued about what's going on there.
Dualnames, I got your game via PM; the Max's sprite does not have alpha channel. The source path tells you imported from BMP.
You must import 32-bit PNG with alpha channel.
Quote from: Khris on Sun 19/01/2014 13:58:55
You need to import it as PNG with alpha channel, and AGS should ask you whether to use said alpha channel upon import.
Even as a png it had the same problems, use a png yourself. So i can't draw image with anything but pngs?
I will clarify: you must not have any magic pink on the image. Use PNG's "transparent color" (ARGB 0,0,0,0).
http://www.mediafire.com/download/pwqn7y74r69lj89/max.png
Quote from: Dualnames on Fri 24/01/2014 17:20:17
So i can't draw image with anything but pngs?
Umm... You can draw in anything you want, graphic editors usually have their own document format, just export as PNG with transparency before importing into AGS.
UPD: Why the bitmap with magic pink does not work?
This is because the magic pink is skipped (considered transparent) in the source sprite, but not in the destination sprite.
When you draw translucent sprite over another sprite, the "solid" pixels of source are blended with "pink" pixels of destination and produce different color.
If you take a screenshot and analyse pink pixels, you'll see that they are not exactly "magic pink" (255,0,255), but slightly different, so they are not considered transparent when the final image is drawn on screen.
The effect is seen better if you draw only one translucent copy of image with bigger offset: you'll see the character's image in a pinkish hue.