Jump to content

Photo
* * * * * 1 votes

[2.50+] Large Animated Combo Graphics


  • Please log in to reply
9 replies to this topic

#1 Moosh

Moosh

    Tiny Little Questmaker

  • ZC Developers

Posted 07 August 2019 - 10:57 AM

This is a tutorial on large combo animations, and specifically the A.SkipX and A.SkipY properties in the combo editor, which can be a little unintuitive and easily misunderstood. Even one of the ZC devs was a little confused recently, so you know this is some real nonsense. My goal here is to show both how to properly animate large FFCs / scripted draws and explain a little bit how it works the way it does. So let's get right into it.
 
A.SkipX
vfMbBPL.png
Here I have a sheet of example sprites, a four frame 4x4 and a four frame 3x3. When I set them to an animated combo and place it on an FFC...
3LVOW9s.png
8SVDKLc.gif
It doesn't animate right at all. This is because the FFC uses the tiles extending down and to the right from the combo's current animation frame. With a normal animation, that top left corner is only advancing one tile at a time and so we get this weird effect you see here. To fix this, we want it to advance four tiles at a time (since the graphic is four tiles wide) and this is where A.SkipX comes in.
lviLg3L.png
Here we set A.SkipX to 3, telling it to skip over three tiles when animating. Paired with the one tile it advances as it animates this gives us the four tile spacing we need.
xwJ1sLE.gif
And it works like a charm. So basically, any large graphic you want to animate, you set the combo to the top left tile and A.SkipX to its tile width minus one.
 
A.SkipY
n0syJUS.png
Now we're doing something a little more complicated. That four frame animation I did before is a little jumpy at the end because it's actually meant to duplicate the middle two frames for a total of 6. But now the animation fills up more than one row of tiles along the top and the results are once again...
QYU8RkB.gif
Pretty buggy.
zhJA1VG.png
It might not be entirely clear what's going on here. The above image shows the frames as we want them to display going blue, red, green, blue, red, green from left to right, top to bottom...
pEvpg1T.png
ZC does not naturally understand this and only shifts that last frame one tile down, causing the buggy effect. So this is where we use A.SkipY.
pIRWWlY.png
Like with A.SkipX, we set the A.SkipY to the sprite's tile height minus one. Unlike A.SkipX, this skip is only applied when the top left tile wraps across the right edge of the table. So the sprites will still progress left to right unless you set a large A.SkipX to tell them otherwise.
jsTSiqn.gif
And once again everything is working fine. But in this case, the tile width of the table was evenly divisible by the width of the tile block. It worked for 4x4, but what about 3x3?
WJuSi0O.png
d7ri5jE.gif
The 3x3 animations are messier looking, but you can wrap a frame around the right side of the table just fine. It just works.
K40On9T.png
Of course nothing's stopping you from just treating the 3x3 animation as a 4x4 if you prefer not to have frames getting cut off.
 
So that's basically A.SkipX and A.SkipY. Hope this helped.

Edited by Moosh, 07 August 2019 - 11:05 AM.

  • ShadowTiger, Jenny, Evan20000 and 3 others like this

#2 ywkls

ywkls

    Master

  • Members

Posted 07 August 2019 - 04:30 PM

So, if I understand this correctly; A. Skip X works all the time, but A. Skip Y only works if the value of A. Skip X is greater than zero and the animation takes more than one horizontal row of tiles? Seems very non-intuitive.



#3 Lüt

Lüt

    Germanize

  • Members
  • Real Name:Steve
  • Location:Chicago

Posted 07 August 2019 - 04:49 PM

A. Skip Y only works if the value of A. Skip X is greater than zero and the animation takes more than one horizontal row of tiles?

Second part only.

A.SkipY is applied when an animation hits the end of a tile row and progresses to the next one, unlike A.SkipX which is applied every frame of the animation.

#4 Emily

Emily

    Scripter / Dev

  • ZC Developers
  • Pronouns:She / Her

Posted 07 August 2019 - 05:06 PM

So, if I understand this correctly; A. Skip X works all the time, but A. Skip Y only works if the value of A. Skip X is greater than zero and the animation takes more than one horizontal row of tiles? Seems very non-intuitive.

ASkip Y tells it "How many extra rows do I go down, instead of just going down 1 row, when I reach the edge of the page?"



#5 ywkls

ywkls

    Master

  • Members

Posted 07 August 2019 - 06:35 PM

So, in order for A. Skip Y to work while A. Skip X is zero, the animation has to continue for that tile on the next row down?

In any case, it's no wonder this has confused so many for so long.

It's akin to rocket science.



#6 Saffith

Saffith

    IPv7 user

  • Members

Posted 07 August 2019 - 07:37 PM

An animation normally advances one tile at a time. When it reaches the end of a row, it moves on to the next row, because that's where the next tile is.
A.SkipX means when advancing to the next tile, skip this many. A.SkipY means when advancing to the next row, skip this many. That's all there is to it.
  • ShadowTiger and Timelord like this

#7 Deedee

Deedee

    Bug Frog Dragon Girl

  • Moderators
  • Real Name:Deedee
  • Pronouns:She / Her, They / Them
  • Location:Canada

Posted 08 August 2019 - 03:30 AM

If you want to animate downwards, just set A.SkipX to 19.

Also, I've noticed buggy behavior where using A.SkipY can lead to you having to set the A.Frames to double their current amount in order to animate correctly. Be aware of that.


  • ShadowTiger likes this

#8 Moosh

Moosh

    Tiny Little Questmaker

  • ZC Developers

Posted 08 August 2019 - 04:08 AM

Also, I've noticed buggy behavior where using A.SkipY can lead to you having to set the A.Frames to double their current amount in order to animate correctly. Be aware of that.

Yeah, I considered adding a mention of this but for a couple reasons. First of all, Rob was already fixing it in 2.55 as I was writing this. Secondly, nobody should ever do this. Every time someone designs around a ZC bug, 2.55 grows more convoluted. :P Let's do our part and report stuff before Rob and Zoria have to grandfather it in.


  • Timelord and Emily like this

#9 Emily

Emily

    Scripter / Dev

  • ZC Developers
  • Pronouns:She / Her

Posted 08 August 2019 - 04:57 AM

Yeah, I considered adding a mention of this but for a couple reasons. First of all, Rob was already fixing it in 2.55 as I was writing this. Secondly, nobody should ever do this. Every time someone designs around a ZC bug, 2.55 grows more convoluted. :P Let's do our part and report stuff before Rob and Zoria have to grandfather it in.

I mean, it will need to be fixed on a backwards-compatibility QR regardless, because who knows how long it's been there or who's done things with it. I found the issue; the formula which calculates "Have we finished yet?" doesn't calculate the ASkipY properly, thus prematurely resetting the animation. When we fix this, all old quests will not be fixed, unless the questmaker goes into `Quest->Rules->Backwards Compatibility` and unchecks the box for "Broken ASkipY framecount" (or something similar; name not finalized)

 

But yeah, instead of building around a bug, the proper thing to do is report it. Bug reports are accepted both on PZC via the "ZC Development -> Bug Reports" subforum, as well as in the ZC Dev Discord.

Feature requests are also accepted on the discord, and in the "ZC Development -> Feature Requests" subforum on PZC.

 

If you have something to report/request, please DO post it. Bug reports we need to have in order to know there's something to fix, and some feature requests end up being MUCH easier to add than you might think (while others much more difficult, to be fair), but you never know unless you request!


  • ShadowTiger likes this

#10 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 10 August 2019 - 08:19 PM

@Staff, please pin.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users