This is a request for implementing two modes of alpha blending between an atom and its overlays.
Method 1
The overlays alpha blending with the atom. Each overlay blends with its foreground and background separately from the atom which also alpha blends with its foreground and background (and blends with the overlays) [this is current behavior].
Method 2
The overlays along with the atom are considered a single image, and this entire image alpha blends with its foreground and background.
Demonstration and Inspiration for this feature request mentioned here: http://www.byond.com/forum/?post=1454727
ID:1455577
 Dec 27 2013, 7:03 pm (Edited on Dec 27 2013, 7:13 pm)
|
|||||||
Resolved
| |||||||
When using the alpha var on an atom it seems to apply to each overlay individually. Making then overlapped on each other like multiple transparencies.
I can't help but feel this is wrong and it should instead be that atoms when rendered create a kind of single image that is then effected by alpha? | |
I think this would be difficult to manage, particularly in DS.
Overlays, for one thing, are not necessarily constrained to share the layer of their parent object. Those cases would obviously not be able to combine. The way the sprites are rendered in DirectX, there would be no way to do this without an in intermediate texture. The software rendering mode would have a similar issue, though it might be moderately easier to manage there. The webclient could probably handle this best, assuming we created a display object which has the individual pieces as its children, and applied the alpha to it alone. | |
Would an alternative way to handle my current issue be a way to pull overlays back from their special format? I'm not 100% sure why overlays are their own inner-format. They operate with -=/+= but you can't really remove, edit , and reinsert an overlay unless you have a reference.
I.e. making overlays transition-able back into images or icons. I'm not familiar with the inner workings so I'm not sure what the best action would be. My current work around is to keep track of each overlay and how it's added and make appropriate icons from their references and then flatten those together. It's kind of a mess and I haven't been able to get it to work cause I've been solely using images to plug into overlays since they offer use of layers. | |
I think the easy workaround would be to use DarkCampainger's GetFlatIcon library, referred to in the link in the OP.
| |
That understandably has issues with the color var. I'm currently working a slight modification to solve my personal issue - I just feel like if color (at least appears to) apply a mask of color alpha should work the same way.
If that's not the case and the color var is effecting each overlay interdependently as well - wouldn't that be worth looking into as a cut down on visual updates? | |
The color var does work the same as alpha. Internally color and alpha are only one actual 4-byte color value, and the client applies the color and alpha at the same time when drawing (in DirectX anyway).
| |
So color is only applied at the end like a mask, or does it get applied to each overlay?
| |
It's applied to each overlay, exactly the same way alpha is. DirectX actually has a color argument in the sprite drawing routine that holds the color and alpha together. Only the software rendering mode differs, because it has to look up or calculate the colored version of the sprite first; but even then it's done on a per-icon basis.
| |
So I'm guessing there's no way avoid that short of shaders?
Would it be possible to make it so the overlays were icons? So something like "for(var/icon/i in overlays)" would work instead of overlays being "an internal format". | |
The thing is to display an icon and all its overlays as one unit, it basically has to be one whole icon. If we were to try to do this on the client end, basically we'd have to grab all icons for the same atom on the exact same layer that were meant to be treated as one unit (i.e., had the proposed setting), render them to an offscreen buffer, and render the result as a new sprite with the color+alpha mask.
| |
If that's not feasible would changing overlays be possible?
| |
I'm not sure I follow what you mean about looping through the overlays. What you have to do right now to accomplish something like this is to combine the overlays with the main icon to create a new icon.
| |
Well the issue might be exclusive to me, but I use images for overlays to make use of the layering var; on top of this to get the color var only effecting that one image exclusively I have to add it to it's own overlays.
This is where trying to keep references for the overlays becomes an issue. It would make my life much easier if I can pull the overlays out as icons and blend them together. | |
With different layers instead of relying on FLOAT_LAYER, basically combining the icon wouldn't be sensible on the client end anyway--because there'd be no telling if another object was meant to display between the layers.
| |
I don't need to do this per atom or anything, I just need a way to generate a flat icon from something using the color var.
I think making the "internal format" overlays have inter-changeable with icons would solve all my issues. At the moment the only way around my current issue is to not use images at all. | |
I updated GetFlatIcon to support the alpha and color settings. It has a couple of limitations with the dir variable, but otherwise it sounds like it does what you want (now).
| |
Thanks, this should help a lot.
| |
Lummox JR wrote:
The thing is to display an icon and all its overlays as one unit, it basically has to be one whole icon. If we were to try to do this on the client end, basically we'd have to grab all icons for the same atom on the exact same layer that were meant to be treated as one unit (i.e., had the proposed setting), render them to an offscreen buffer, and render the result as a new sprite with the color+alpha mask. Is that not doable? | |
Is it possible to add flick for an overlay too? I had to create objects on my player and loop it every tick so it'd be on the correct position, just because I needed to flick an image on certain situations. :S