I was noticing that a lot of my icon animations, in comparison to the results of the animate() proc are much choppier and with far less quality, which is to be expected.
At the same time, I noticed that running multiple, complicated, animations can get a bit stressful to a server.
I suggest that there be a procedure that will allow you to output the animation created by the animate() procedure into an icon.
It will work in the exact same fashion as the animate() procedure, however instead of displaying each updated frame, they are collectively stored then added into an icon which would be the returned result of said procedure.
The procedure could output the entire animated atom as well as it's overlays, underlays, attached images, etc. Anything on an atom that is affected by the animation, essentially. If this is too much, then it's understandable that just the atom itself and it's icon/state are included in the output.
Why: This would make it much easier to create very complicated animations without them running over one another and causing glitchy behavior, would make creating animations for animated icon_states much easier. It will also reduce load on the CPU if there are multiple animations as they would be preprocessed and only have to be displayed as a final result.
It would also allow manual editing of frames created by an animation at a later time.
Ultimately this would further improve the animation and visual quality possible in BYOND as it would allow for much simpler construction of complicated visual events.
ID:1414189
 Nov 5 2013, 8:40 am (Edited on Nov 5 2013, 8:46 am)
|
|||||||
| |||||||
Well to put it simply: Could we have a way to save the results of an animation into an icon? Basically creating states to save into an icon based on the animation steps that are generated by animate()?
| |
Animation works on atoms (and images), not on individual icons. All it does is change a number of vars over time instead of instantly. Only a handful of these could conceivably be applied to an icon: basically just color, alpha, and trasnform. The /icon datum does not support affine transformations, and handles scaling and rotation via special code that frankly needs improvement.
| |
What I'm trying to explain is something like: If I were to take snapshots or printscreens, once per frame during an animation, of how an atom looks, then put the resulting images into an icon state.
I understand the icon itself isn't changing, however, to the player, things look different. I'm really hoping I don't have to get a third party program that will take pictures frame by frame of a portion of my screen, then extract the atom displayed form those and put them one by one into an icon_state just to give an example of what I mean. I would like a feature that takes frame by frame snapshots of how an atom looks during an animation so that it can be turned into an icon state. I' not sure how else to explain it, I'm not using the terms icon or image specifically pertaining to the datums, but instead as how an atom looks or what is finally displayed to the user. | |
In short; he wants a way to "record" an animation and save it into an icon file (as the frames of an animated icon_state).
| |
SuperSaiyanGokuX wrote:
In short; he wants a way to "record" an animation and save it into an icon file (as the frames of an animated icon_state). Yes. I'm terrible with explanations -_-; | |
Without the /icon datum supporting affine transforms, all you'd have control over for this process would be color and alpha.
But I still really don't see the purpose of doing in an icon state what you can do with animation. Animation is going to be much kinder to the network in 99% of cases. | |
I think that the general idea is that it could be used to "cache" an often-called animation so you can avoid too many calls to animate() (which many have noticed to be a bit taxing when piled up; say, for particle systems and such).
And another benefit would be the ability to generate an icon that can be edited manually later. (and then used, instead of calling animate() at all, to get the effect in subsequent versions of the game.) I.E. You draw an icon, animate() it in-game to rotate it some number of degrees, it outputs each degree of the rotation as a new frame in an exported icon, which you then use in subsequent versions of the game for the rotation instead of the animate() you previously used to generate it. But as you've pointed out, it seems as if there isn't a way to "capture" the frames created by animate() in such a manner. | |
That wouldn't work if he needs to be able to use alpha transparency as opposed to index transparency.
| |
Topkasa wrote:
That wouldn't work if he needs to be able to use alpha transparency as opposed to index transparency. Basically this. I could use LICEcap or another screen capture program and use a programmer pink background while recording an animation, the issue with this is that any anti-aliasing will blend with the alpha adjustments made and you'll get partially pink pixels which should be transparent. You could then use a color replacer in photoshop or another program to try and swap that pink with the null color but.. eh, that'd take a while to get it just right. All in all, it could be done, but it would require a lot of work on each and every frame, of which there could be dozens. | |
There is one way you could do it, however.
If you can arrange so that the animation is exactly the same each time (either no use of the RNG, or a consistent seed value each time), you could run it twice. One with the particles at full alpha against black, and a second time with the particles at whatever their correct alpha is, but made completely white. This would give you two gifs; one would be an RGB gif with neither index nor alpha transparency, and the other would be a greyscale alpha map corresponding to the first gif. | |
Couldn't you leave the icon with no alpha transparency and add it after-the-fact with atom.alpha?
| |
..Yeah, for some reason I somehow derped and was thinking of something like compiling a particle system to an icon.
Good going, me. | |
Nadrew wrote:
Couldn't you leave the icon with no alpha transparency and add it after-the-fact with atom.alpha? Not if there are different alpha values within the same icon. I think that's what they are referring to anyway - I rarely do this but I can see why it would be desirable | |
It's basically because when using hardware mode, animating a matrix usually gives it anti-aliasing along the edges which includes multiple different alpha levels.
Mainly the issue is that screen capture, through any means, will cause everything to become a single layer image, which makes those pixels blend with the background color, losing their transparency. You could just go without hardware mode and get aliased animations that look fairly nice, then find some way to apply AA on each of the results separately. I think Photoshop has a feature for that, not sure. | |
What you're asking for sounds like more of a server-driven feature, whereas animation is largely based on the client. The server is only keeping track of the Appearance changes and timing (and other such values) for each stage of the animation.
You're also confusing icon animation frames with animation steps. Frames in an icon's animation are merely simple images arranged in a sequence, and the appropriate frame is displayed during each map draw based on the timing of the icon's "movie". Animations are multi-stage operations where you're just transitioning a series of values from point A to B to C, etc.; the intermediate values are calculated at the time they are displayed.