I have the following problem. My artist gave me some objects (with Alpha Channel) to import into AGS. Take these scissors for example:
(http://www.alkis.org/External/scissors.png)
They look fine, but when I tried to import them into AGS I got the following weird result:
(http://www.alkis.org/External/scissors3.jpg)
Instead of importing the image, I then decided to try copying & pasting it as a new sprite. The result was better, but not perfect as you can see:
(http://www.alkis.org/External/scissors2.jpg)
My artist told me that this outline is caused by "half transparent areas" in the image, which AGS doesn't seem to support. He said "Half transparency is for better fitting of overlay to every backround without sharp edges".
Does anyone know if there's anyway around this problem, other than the obvious of not using half transparent areas?
My game is 800x600, 32bit.
Thanks in advance.
(http://www.alkis.org/External/scissors3.jpg) is actually correct, AGS doesn't show the transparencies in the editor itself but it does at run time. Try test-running the game with the sprite on show and it should display as intended.
I did test it. It's displayed in the game exactly as it is in the Editor.
Are you sure you tested the first case (the import rather than the cut and paste)?
How are you displaying the object? (RawDraw? as an object?)
simple solution :
if you are using photoshop :
have the scissors on a seperate layer and turn off all your other layers so you see transparency...
and save as a GIF!
png dosent do a good job with saving transparecys on anti-alias patterns of any kind. (curves / angles)
~ college degree, a.a.s in digital media communications
Don't, GIF only supports indexed colour images (i.e. up to 256 colours), and doesn't support Alpha transparency (unless you only want to have full transparent/opaque pixels), if you want alpha channel in your sprite, you should use PNG.
alkis, where are you using the sprite for? I think transparency might not work if you use it for some specific purposes, like setting it's opacity in-game, etc. (I'm not sure)
Steve: Yes, I'm sure. I tested both cases in the game, and they looked exactly like they did in the editor.
Deftonesrule: I'm in my office at the moment, I'll try it when I get back home but as Gilbot says I don't think a GIF will do.
I'm using the sprite as an inventory item image.
Can one of you perhaps take the first image I included in my first post and try to import it to see what the problem is?
What the manual doesn't say, but seems to be the case, is that you can't use sprites with an alpha channel for GUI Buttons, or inventory items and have them show properly. The exception to this seems to be if the GUI background image has alpha transparency, Inventory Items and Buttons look right over parts of the background that are fully transparent.
If this is the case, then: as a slightly hack-y workaround, you could give your Inventory GUI an alpha transparent BG under the actual items, and have a second GUI that appears behind it, to make it look how you want.
EDIT:
(http://www.geocities.com/ashenags/alpha.jpg)
A is your sprite as an Object - alpha channel works fine.
B is the Inventory GUI, with a mostly alpha-transparent image as BG. I've used your sprite for the OK button.
C is an opaque strip of the BG - notice how the alpha-blending stops as soon as the BG isn't transparent?
D is your sprite as an inventory item, on the transparent BG - alpha channel works fine.
Excuse jpg-ification.
Thanks for going through all this trouble. I'll let you know how it went tonight.
Quote from: Gilbot V7000a on Fri 02/06/2006 03:34:54
Don't, GIF only supports indexed colour images (i.e. up to 256 colours), and doesn't support Alpha transparency (unless you only want to have full transparent/opaque pixels), if you want alpha channel in your sprite, you should use PNG.
alkis, where are you using the sprite for? I think transparency might not work if you use it for some specific purposes, like setting it's opacity in-game, etc. (I'm not sure)
The problem he's having is the white matte outline from saving it as a png. solution = use a gif.
And so what if i only supports indexed colors ? Its a spite for crying out load. you wont notice and color degredation. Gifs are the best way to go imho
I don't think the problem is the white outline itself, exactly. That's just a of the alpha channel not working properly (the actual problem). As Gilbot said, gifs don't support alpha-channels at all and Alkis specifically asked for a solution "other than the obvious of not using half transparent areas" (i.e. alpha tranparency) - so in this case gifs are definitely NOT the best way to go.
However I could be wrong, we'll have to wait and see when Alkis has had a chance to play with it himself.
Quote from: deftonesrule on Fri 02/06/2006 01:46:10
png dosent do a good job with saving transparecys on anti-alias patterns of any kind. (curves / angles)
Yes, yes it does.
Quote
~ college degree, a.a.s in digital media communications
I'd ask for my money back. :=
Ok Ashen I tried your suggestion and it worked. My scissors are now displayed beautifully over a completely transparent GUI. Thank you.
However, this solution created a number of new interesting problems.
1) All the PCX images in this GUI (including the buttons) disappeared! They are not drawn over the invisible background. I suppose I can make some PNG ones instead, but I'm very curious to know why this happens. This is evern before I go to step 2:
2) As you suggested, I created a second GUI that opens simultaneously with the first one. The second GUI uses the initial image as a background. However, it seems to be drawn over the first GUI, making every other image disappear (inclusing the PNGs)! This can be solved if I make the image semi-transparent, which makes my inventory actually look very pretty, but I have another GUI and I want it be opaque, not semi-transparent. Any idea how I can solve this?
1)
Weird. The buttons on the non-transparent parts should be OK (as in the image I posted), provided they're totally opaque. Semi-transparent background make the buttons disappear, though. I've no idea why this happens, sorry - maybe Chris / someone who understands alpha-cannels better than me can explain it better.
2)
Have you tried altering the GUIs Z Order property? If the 'Background' GUI has a higher Z Order than the first one, it will appear on top of it.
For a possible solution to both problems, what if you make one GUI just the inventory window - make it exactly the right size, position it to appear over the Background GUI at the right point, and give it an alpha-transparent BG image. Then have the visible background image and all the buttons, etc, on a second GUI (with a lower Z Order).
Quote from: Ashen on Fri 02/06/2006 20:04:55maybe Chris / someone who understands alpha-cannels better than me can explain it better.
It doesn't matter, creating new buttons only took me a minute (and they look a lot better), and I know that future objects will all have Alphas so no need to worry the big man.
QuoteHave you tried altering the GUIs Z Order property? If the 'Background' GUI has a higher Z Order than the first one, it will appear on top of it.
Thanks, that did the trick.
QuoteFor a possible solution to both problems, what if you make one GUI just the inventory window - make it exactly the right size, position it to appear over the Background GUI at the right point, and give it an alpha-transparent BG image. Then have the visible background image and all the buttons, etc, on a second GUI (with a lower Z Order).
That would probably solve it, but like I said doing some new buttons was much easier. The PCX files were just some random objects I imported from my old game when testing the inventory GUI, so I don't need them.
Speaking of the inventory... remember when you helped me with the mouse clicks in this thread (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=26208.0)?
You said:
QuoteYou could also try adding an if (button == eMouseRight) mouse.SelectNextMode(); condition to the Inventory GUI's control function (in the editor, double click on any part of the GUI that's not a control to open the Script Editor the the right place) - but that only works for right-clicks on blank parts of the GUI (i.e. if you click a part of the InvWindow object that's not an item, it won't work). I'm sure there's a fairly easy way to get it to work wherever you click, it's just that I can't think of it right now as I'm about to fall asleep.
I never gave that much thought, because as I was testing it I had filled it with inventory items and right mouse clicks worked everywhere. But now that I only left two objects, as you said right clicking on the main inventory area does not move on to the next mouse mode. Can you think of a way to fix this?
Ooh, I though you'd fixed / given up on that, since you didn't post again...
I did come up with a possible solution, which was to use rep_ex_always, e.g.:
bool down;
function repeatedly_execute_always() {
if (mouse.IsButtonDown(eMouseRight)) down = true; // While Right button is down
else if (down == true) { // When Right button is released
if (gInventory.Visible == true) mouse.SelectNextMode();
// Because otherwise, 'normal' Right-clicks will jump forward 2 modes
down = false;
}
}
You'll probably need to change (or even remove) some of the things you added in that other thread (the eMouseRightInv conditon in on_mouse_click and the if (button == eMouseRight) condition in the GUIs function, for example) and do a bit of general tinkering (like adding condition so it doesn't interfere with the GUI buttons) to get it to work exactly as you want, but that SHOULD be a more universally working solution.
I think I've used the on_event function to do that. I'm not at home right now so I'm not sure.
After some tinkering in other parts of the script, it worked perfectly. Thanks again!
Quote from: strazer on Sat 03/06/2006 13:03:02
I think I've used the on_event function to do that. I'm not at home right now so I'm not sure.
Huh. I'm sure there was some problem with
on_event not working when I tried it for that other thread, which is why I went for
rep_ex_always. But apparently not though, as it now works just fine using
eEventGUIMouseDown/Up, like this:
function on_event(EventType event, int data) {
if (event == eEventGUIMouseDown) {
if (mouse.IsButtonDown(eMouseRight)) down = true;
}
if (event == eEventGUIMouseUp) {
if (down == true) {
mouse.SelectNextMode();
down = false;
}
}
}
(Is this what you meant?)
Which I'm certain I've tried before and got nothing. I wonder what I was doing wrong?
Still, the main thing is: It works. Now let us never speak of it again.
(Unless, you know, it stops working, obviously.)
Don't like double posting, but I think it's justified.
Deleted a few posts. If anyone wants to continue that discussion, do it by PM not in this thread, Thank you.