Jibble

Author Topic: [SOLVED] Why this strange 'reset' to height when inclding a .Walk() command?  (Read 844 times)

TheManInBoots

  • Epically wrote function to declare an int
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.

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

  • Global Moderator
  • Global Moderator
  • Mittens Lord
  • Private Insultant
    • Best Innovation Award Winner 2018, for his numerous additions to the AGS open source ecosystem including the new Awards Ceremony client and modules
    • Snarky worked on one or more games that won an AGS Award!
    •  
    • Snarky worked on one or more games that was nominated for an AGS Award!
I think we have already found the cause of the problem (well, Arlann has), so that should not be necessary.

Sorry, haven't read this thoroughly, but

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.
« Last Edit: 09 Feb 2020, 16:45 by Crimson Wizard »

bx83

  • Get 'Er Doooooone
SOLUTION

Put the Julius z scaling:

Code: [Select]
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

  • Cavefish
  • Fleeing the Cylon tyrrany...
    • Cassiebsg worked on one or more games that won an AGS Award!
    •  
    • Cassiebsg worked on one or more games that was nominated for an AGS Award!
Quote
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.
There are those who believe that life here began out there...

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

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

Cassiebsg

  • Cavefish
  • Fleeing the Cylon tyrrany...
    • Cassiebsg worked on one or more games that won an AGS Award!
    •  
    • Cassiebsg worked on one or more games that was nominated for an AGS Award!
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...

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).
Fail at Floaty Rog' now!  still having to deal with what games are going through

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

  • Epically wrote function to declare an int
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:
I have a room where he can click objects in any direction, so I've tested extensively. It's just the walk() command

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.
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.


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).
« Last Edit: 10 Feb 2020, 03:00 by TheManInBoots »

bx83

  • Get 'Er Doooooone
Quote
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).

     

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

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

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.

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.
Fail at Floaty Rog' now!  still having to deal with what games are going through

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.

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.
« Last Edit: 10 Feb 2020, 11:54 by Crimson Wizard »

TheManInBoots

  • Epically wrote function to declare an int
     
ps Sorry for colours, just to show where the frame begins and ends.
It's nice. Thanks for sharing.

TheManInBoots

  • Epically wrote function to declare an int
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.
« Last Edit: 05 Mar 2020, 13:25 by TheManInBoots »