[SOLVED] Why this strange 'reset' to height when inclding a .Walk() command?

Started by bx83, Sun 09/02/2020 00:16:09

Previous topic - Next topic

TheManInBoots

Olleh bx83 mentioned before that they are.

Also when the character does not walk, the animation transition goes seemlessly as you can see in the second video.

Olleh19

Quote from: TheManInBoots on Sun 09/02/2020 13:47:28
Olleh bx83 mentioned before that they are.

Also when the character does not walk, the animation transition goes seemlessly as you can see in the second video.

Aha, but it's two different animations tho ??? a side animation when it doesn't work, and the front pickup version when it does work. Still a change it could be off in the cutting, if  it's been done manually (in the ags editor).
Would be interesting to see if it works for anybody else. If he could share the actual animations only so one can import and try. (roll)

Snarky

I think we have already found the cause of the problem (well, Arlann has), so that should not be necessary.

Crimson Wizard

Sorry, haven't read this thoroughly, but

Quote from: Arlann on Sun 09/02/2020 13:03:39
Is this not a blocking function problem?
If z is relative to scaling, you should update z in a function repeatedly_execute_always or late_repeatedly_execute_always, because the scale changes as you walk.

I believe, this must be remembered, and go into FAQ, that if you need some property, especially visual property, be to kept in sync with another built-in property at all times, then it should always be done in late_repeatedly_execute_always, because this function is called always, and called last before drawing things on screen.

repeatedly_execute is not called during blocking actions, therefore may skip a long period,
repeatedly_execute_always is called before main game update, therefore will always be 1 frame "behind" the game and object values.

bx83

SOLUTION

Put the Julius z scaling:

Code: ags
cJulius.z = 0 - ( FloatToInt( (Z_FACT / 100.0) * IntToFloat(cJulius.Scaling), eRoundDown ) );


...in repeatedly_execute_always(), and not just repeatedly_execute().

Thank you all!  :grin:

I will test this extensively, but it seems to work.

Cassiebsg

Quotethen it should always be done in late_repeatedly_execute_always, because this function is called always, and called last before drawing things on screen.
There are those who believe that life here began out there...

ManicMatt

I realised my character z code was in the game start function, so I moved it late repeatedly execute always and when the game loads, I visually see the character get moved down after fade in. Keeping it in on game start as well seems to fix that.

Although my character z code is just the basic version of the code for the z axis, not the above code that bx83 is using which I don't understand.

bx83

Cassiebsg: I know, I read this part, tried repeatedly_execute_always(), and it worked. Maybe later_ would also work, doesn't require testing.

Cassiebsg

The difference is that late run after everything else, but just before it being drawn. putting it on the other might give you a little "hickup" as in, the character is drawn in y 80, and moves to y 81 or 79 after it has been drawn. Might be noticeable, might not.

ManiacMatt, that seems to be odd, since the character should be updated to the new z, before he gets drawn in screen, not afterwards.  ??? But putting the z in game start is what I usually do. Never noticed needing all that code bx83 is using. But then again I don't think I have any game with that much scaling.
There are those who believe that life here began out there...

Khris

Quote from: ManicMatt on Sun 09/02/2020 21:16:56
I realised my character z code was in the game start function, so I moved it late repeatedly execute always and when the game loads, I visually see the character get moved down after fade in. Keeping it in on game start as well seems to fix that.

Although my character z code is just the basic version of the code for the z axis, not the above code that bx83 is using which I don't understand.
If by "basic version" you mean something like  player.z = -20;  you should keep it in game_start because there's absolutely no reason to run that line dozens of times per second. Unlike code that has to constantly update z because it takes the current scaling into account (i.e. shifts the player by 108 pixels instead of 72 if they're scaled to 150%).

You saw the jump because when AGS fades in a room the game is blocked, and a room's RepExec function only runs while the game isn't blocked (this is why repeatedly_execute_always exists).

ManicMatt

Oh right! I thought maybe I was doing it wrong by having it i. game start despite not noticing any problems. I'll revert it back to how it was. I'm not using any scaling for this game anyway. Yeah that was the code! Thanks both!

TheManInBoots

Quote from: Olleh19 on Sun 09/02/2020 14:21:02
Aha, but it's two different animations tho ??? a side animation when it doesn't work, and the front pickup version when it does work.
Lol actually he had mentioned that before that he had the exact same results for all animation directions:
Quote from: bx83 on Sun 09/02/2020 09:50:17
I have a room where he can click objects in any direction, so I've tested extensively. It's just the walk() command

Quote from: ManicMatt on Sun 09/02/2020 21:16:56
I realised my character z code was in the game start function, so I moved it late repeatedly execute always and when the game loads, I visually see the character get moved down after fade in. Keeping it in on game start as well seems to fix that.

Although my character z code is just the basic version of the code for the z axis, not the above code that bx83 is using which I don't understand.
Both the late repeatedly execute always and repeatedly execute always start running only AFTER the very first room has loaded. Nobody seemed to have noticed that.
So of course you have to write it both in game start (or room before fade in) AND repeatedly execute always, if you have the constantly changing z-factor.
Quote from: Khris on Sun 09/02/2020 23:05:42
You saw the jump because when AGS fades in a room the game is blocked, and a room's RepExec function only runs while the game isn't blocked (this is why repeatedly_execute_always exists).
.
Again, that's not correct. Even repeatedly execute always (AND late rep. always )is blocked before the very first room is loaded.
After the first room is loaded the repeatedly always function works during fade ins for other rooms but NOT before the first room is loaded.


Quote from: Crimson Wizard on Sun 09/02/2020 16:32:50
I believe, this must be remembered, and go into FAQ, that if you need some property, especially visual property, be to kept in sync with another built-in property
And if you add the FAQ it might be very useful to also explain exactly what you mean with "visual property" and "built-in property", because people who are new to AGS (which are the ones who have FAQs) won't understand it otherwise.

bx83, would you mind sharing a sprite frame of the "walk up animation" of your character? One where the leg is stretched down to the very bottom of the sprite?
Because the question came up several times and I believe not everyone understood why that space below the character was necessary in the first place. And it's just a brilliant example for efficient walk animation (by stretching limbs).

bx83

Quotebx83, would you mind sharing a sprite frame of the "walk up animation" of your character? One where the leg is stretched down to the very bottom of the sprite?
Because the question came up several times and I believe not everyone understood why that space below the character was necessary in the first place. And it's just a brilliant example for efficient walk animation (by stretching limbs).

     

All frames are the same size. All frames work seamlessly.

ps Sorry for colours, just to show where the frame begins and ends.

Khris

Quote from: TheManInBoots on Mon 10/02/2020 01:52:23
Quote from: Khris on Sun 09/02/2020 23:05:42You saw the jump because when AGS fades in a room the game is blocked, and a room's RepExec function only runs while the game isn't blocked (this is why repeatedly_execute_always exists).
.
Again, that's not correct. Even repeatedly execute always (AND late rep. always )is blocked before the very first room is loaded.
After the first room is loaded the repeatedly always function works during fade ins for other rooms but NOT before the first room is loaded.

Yeah, what I meant by that was "in general, repeatedly_execute code doesn't run while the game is blocked (this is why repeatedly_execute_always exists)". The first fade in seems to block everything though, yes.

Crimson Wizard

Quote from: Khris on Mon 10/02/2020 09:27:17
Quote from: TheManInBoots on Mon 10/02/2020 01:52:23
Quote from: Khris on Sun 09/02/2020 23:05:42You saw the jump because when AGS fades in a room the game is blocked, and a room's RepExec function only runs while the game isn't blocked (this is why repeatedly_execute_always exists).
.
Again, that's not correct. Even repeatedly execute always (AND late rep. always )is blocked before the very first room is loaded.
After the first room is loaded the repeatedly always function works during fade ins for other rooms but NOT before the first room is loaded.

Yeah, what I meant by that was "in general, repeatedly_execute code doesn't run while the game is blocked (this is why repeatedly_execute_always exists)". The first fade in seems to block everything though, yes.


Hmmm, this seems like a engine flaw. Fade-in should always be same fade-in, regardless of whether it's first time room is entered or not.
Probably it was explicitly coded to run an all-blocking fade-in at the start.

TheManInBoots

Quote from: bx83 on Mon 10/02/2020 03:43:30
     
ps Sorry for colours, just to show where the frame begins and ends.
It's nice. Thanks for sharing.

TheManInBoots

I had only experimented a little with z-axis and it seemed that only during the first room load the repeatedly_execute_always function is switched off.
After reading this post I felt like experimenting more with it in another project, and actually repeatedly_execute_always (also the late_r...) are paused during room transitions.
It makes sense coming to think about it, because the repeatedly execute functions are all blocked while the game is paused. You don't want  part of the game to continue which is defined in repeatedly_execute_always while the rest of the game pauses. So of course, while the game is paused during room transitions, so are all repeatedly executes.
So I want to correct what I said: during all room changes you need to set the proper scaled z-value in the room before load function in order to avoid the sudden little jump after fade in.

SMF spam blocked by CleanTalk