Descriptive Problem Summary:
When you blend an animated sprite with another sprite, the animation is forced into a frame delay of 1 for every frame regardless of previous configuration.
Numbered Steps to Reproduce Problem:
Testcase: https://www.dropbox.com/s/dikugws4y0ocl27/ IconAnimationEditTestcase.zip?dl=1
- Compile and run the testcase project
- Activate the client verb
- Compare the animation speed to what's configured in the dmi
Expected Results:
A slowly pulsing box with a delay of 10
Actual Results:
A quickly pulsing box with a delay of 1
Does the problem occur:
Every time? Or how often? Yes
In other games? Tested both in sample case and ss13
In other user accounts? Yes
On other computers? Yes
When does the problem NOT occur? Never
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked?
I'm unsure how far back this goes, at the very least it was an issue in 512 stable and I only now got around to making an example case for this report.
Workarounds:
Use only 1 delay frames and add a bunch of repeat frames. Though this is a very poor workaround in my particular case as it is more expensive to modify sprites with multiple frames like this.
ID:2758541
Jan 8 2022, 10:53 pm (Edited on Jun 24 2022, 4:18 pm)
|
|||||||||||||
Not a bug
| |||||||||||||
Apr 21 2022, 3:20 am
|
|
We have a greyscaling system for making multilayered sprites that get colored in during runtime and I can't use it properly for animated sprites until it's possible to blend animated sprites with frame delays other than 1.
|
I thought I had the test case for this but it seems I don't. The download link doesn't currently work. Do you still have the test case available?
|
Bump, this is still an issue and I would really like for animated sprites to work in the greyscaling system mentioned previously.
|
I've finally had a chance to look at this, and although I found some undesirable behavior on the backend to change, this isn't actually a bug.
You're blending an icon with its own delay information over one that has existing delay info. The source icon is the one that has the fast delay, whereas the one you're overlaying has the slow delay you want. In order for this to work the way you expect, you'd have to do the blending in the opposite order. There's also a bug in your test case, as you're using a blend_mode value in Blend() instead of one of the ICON_ constants. It should be ICON_OVERLAY, not BLEND_OVERLAY. |
That blending order matters for animated sprites is helpful to know and should really be in the blend documentation. There are still a couple issues here though.
The other icon with its own delay information is a single frame non animated icon that can't have its delay information modified within the editor. Additionally, there's no way to read delay information from dm so I can't write a check to make sure blends are in the right order. |