Hey sorry if this doesn't belong as it's not a question specifically for an AGS game, but I was wondering if anyone had any technical knowledge of how AGS matches animation with movement, aka the anti-glide feature.
I'm busy writing some animation code for a player in a separate engine, and I'd love to be able to replicate this little marvel - at the moment all Ive done is manually calculated how many pixels of movement each frame should be shown for, and while this works great for tying the animation to the movement speed it still doesn't quite have the charm that AGS's solution does.
Simple: the character only changes position when the animation changes frame.
Ah! It's so simple and it works brilliantly, here I was thinking there was a lot more going on there lol.
I had the complete opposite way around, change animation frame when the player changes position. Thanks Snarky.
Quote from: Phemar on Wed 09/12/2020 15:08:34
it still doesn't quite have the charm that AGS's solution does.
What charm? The anti-glide feature is nauseating in a scrolling room unless you have a lot of animation frames, which most small freeware indie games don't.
I'm not even exaggerating. :-X
Quote from: Danvzare on Thu 10/12/2020 16:13:39
What charm? The anti-glide feature is nauseating in a scrolling room unless you have a lot of animation frames, which most small freeware indie games don't.
Don't know which exactly conditions are causing nauseating effect to you, but I'd suppose that's a problem of camera scrolling, not anti-glide feature itself.
Yea it can look rather jumpy if you have a low frame count, but for the style I'm going for, jumpy animation/movement is kinda exactly what I want! Also, there will be no scrolling rooms in my game, (at least, all my movement will freeze if the camera scrolls).
I'm making a top down action shooter in the style of an old Gameboy game in case you're interested, kinda similar to the top down levels in old Contra games.
Quote from: Crimson Wizard on Thu 10/12/2020 16:35:27
Don't know which exactly conditions are causing nauseating effect to you, but I'd suppose that's a problem of camera scrolling, not anti-glide feature itself.
I thought you knew this already?
With anti-glide, if the camera/viewport follows the character in a scrolling room exactly (as in the built-in behavior), the camera position will of course also only update when the animation frame changes, leading to very jerky movement. Alternatively, if the (scripted) camera does
not follow the character exactly, you can get "judder" where the position of the character on-screen seems to shake (though this will only really be a problem if the overall walk and scroll speed are the same, and if the animation rate is high, e.g. a delay of 2 loops per frameâ€"or in some cases if the scripting doesn't use
late_repeatedly_execute to update the camera).
Quote from: Snarky on Fri 11/12/2020 12:40:47
Quote from: Crimson Wizard on Thu 10/12/2020 16:35:27
Don't know which exactly conditions are causing nauseating effect to you, but I'd suppose that's a problem of camera scrolling, not anti-glide feature itself.
I thought you knew this already?
With anti-glide, if the camera/viewport follows the character in a scrolling room exactly (as in the built-in behavior), the camera position will of course also only update when the animation frame changes, leading to very jerky movement
I tested one of our game templates before posting that, and didn't see any jerkiness, but a pretty smooth camera movement. I've seen jerkiness before in other games though (or maybe it was "judder" you mention further). Presumably there is a range of conditions under which this happens.
(Besides, "nauseating" is a subjective impression, and may relate to something different from my personal experience)
I remember the jerkiness in scrolling rooms from the past, but in my current project it looks quite smooth, so I'm not sure about the conditions either.
I think that 'following' characters can (will?) get out-of-sync with the scrolling.
Just wanted to point out that the options in Character settings in AGS are quite poorly labeled when Anti-glide is enabled, specifically "AnimationDelay" and "MovementSpeed".
From my testing, it seems "MovementSpeed" actually refers the amount of pixels per frame of animation that the character moves, ie it's actually a distance setting. "AnimationDelay" controls how often the character changes animation frame, which then causes the character to move "MovementSpeed" pixels in whichever direction.
So I guess "AnimationDelay" is technically correct, however it's actually more of a speed setting and "MovementSpeed" is actually more of a distance setting. In an analogy, if you think of Kilometers per Hour (or miles per hour if you're that way inclined), "MovementSpeed" would be the kilometers and "AnimationDelay" would the per hour.
Just an interesting little tidbit.
Quote from: Phemar on Sat 12/12/2020 07:17:19
So I guess "AnimationDelay" is technically correct, however it's actually more of a speed setting and "MovementSpeed" is actually more of a distance setting. In an analogy, if you think of Kilometers per Hour (or miles per hour if you're that way inclined), "MovementSpeed" would be the kilometers and "AnimationDelay" would the per hour.
from what I saw,
AnimationDelay - is actual delay -- number of game ticks to wait between animation frames.
MovementSpeed - is actual movement speed -- it's pixels per game tick, but if "anti-glide" mode is turned on, then it means pixels per animation frame, which on its own equals to N game ticks (defined by AnimationDelay). So it's still speed, but becomes pixels per N ticks instead of pixels per 1 tick. Only time unit changes, but idea remains.
Quote from: Crimson Wizard on Sat 12/12/2020 08:01:24
from what I saw,
AnimationDelay - is actual delay -- number of game ticks to wait between animation frames.
MovementSpeed - is actual movement speed -- it's pixels per game tick, but if "anti-glide" mode is turned on, then it means pixels per animation frame, which on its own equals to N game ticks (defined by AnimationDelay). So it's still speed, but becomes pixels per N ticks instead of pixels per 1 tick. Only time unit changes, but idea remains.
That's what I mean - if anti glide is enabled, AnimationDelay becomes a speed setting, since they character can only move when the animation frame changes. MovementSpeed then becomes the distance the character should move per animation frame, which is controlled per game tick.
Not a big deal, just thought I'd point it out.
Alright, I see, so MovementSpeed toggles between distance/time and distance/event. In the anti-glide mode the actual speed of movement is defined by MovementSpeed only so long as animation is continious and not interfered by anything.
AnimationDelay physically it's still a time setting, as it defines time, not distance per time. It affecting the movement speed is rather an effect of this mode.
I don't know how to rename these properties to better reflect their meaning while MovementSpeed is used for both modes. We could e.g. describe "MovementSpeed" is a "Distance Per Frame", where "frame" can be either game frame or animation frame depending on settings. There might be a technical solution to changing the displayed name of a property too when the mode changes.
Well, "speed" is defined as distance/time, so using the name "speed" for either just the distance or just the time is fundamentally wrong, whether the "time" unit is per game loop or per animation frame. (Of course, "per loop" is not even properly a time unit, it only becomes one after you apply the game speed in loop/second, but we'll ignore that.) Apparently Phemar's intuition is that "speed" has more to do with the time, while Crimson's is that it has more to do with distance, but really it's neither (well, both, but only both together).
I propose that for AGS 4, when we ditch backwards compatibility, the MovementSpeed property be renamed MovementDistance or MovementPerFrame or some other more accurate name. The manual should also be updated: the way it discusses "speed" is a nightmare of inconsistency and misleading or unexplained terms.
And perhaps the editor could take the MovementDistance, AnimationDelay and MovementLinkedToAnimation settings to calculate and display the actual average movement speed in pixels per game loop (though it's more complicated than that if you use individual frame delays or ScaleMoveSpeed).
Speaking of camera issue, I've been replaying "Resonance" recently, and it is a fine example of how to "loosen" camera's focus on character movement. The parallax modules found on forums may also do the same.