Fixing Animation Lag- or better way to do animations?

[CallMeKerrigan]

In my game there is a common event that checks for 2 things. One common event checks for Low HP and is running at a parallel process. It is a conditional branch and is always running. When the low HP triggers the conditional branch, the character flashes. I don't see any notable problems with it.

The second method is the same, and it does it for the MP. Instead of flashing the character, however, a simple animation loops. (It is z's, like the character is sleepy). It seems like when that event is triggered, however, there is a slight drop in FPS. And if this animation is playing during a complex event, there is noticeable lag.

I'm pretty certain that the animation is the culprit of this. I was wondering if there was a solution to this? It's no big deal, but I don't feel comfortable releasing a game with a problem I'm aware of. =]

 

[AceOfAces_Mod]

Parallel Process may be the culprit since it executes the code again and again while the game. I found a possible fix for that issue:

http://forums.rpgmakersource.com/topic-parallel-process-events-execution-bug-fix?pid=251#pid251

 

[CallMeKerrigan]

Hmm. I think it worked, it still seems a little choppy, if that makes sense. If there's no other solution, though, I think it will do. :]

Edit: Actually, I'd rather just find a way to display the 'zzz' effect without using animations. It stops any other animations from happening on screen, and it seems to be making all of my parallel processes wonky. It really seems like it's the animation that's the sole cause of all this. I didn't have any problems until I used it.

 

[Andar]

For correct operations, you'll need the correct number of waits in both common events.

If you have no waits or a wrong number of frames as waits in the first case, then it will only cause lag (a lot of lag in case of no waits). When that lag will become visible depends on how powerfull the computer is, but it will be there.

In the case of the animation, that parallel process should have a wait number that is one higher than the time needed to play the animation, because the animation is also played parallel. If the PP loops faster, then the additional play animation commands will be ignored (only one animation at a time) but will cause a lot of timing problems and even more lag than the lag from the first PP.

 

[CallMeKerrigan]

Well, so I tried what you said. 

The only 2 common PP's I have are check for low HP and check for low MP.

The MP animation is just 3 frames. So, I did this.



That just made it a lot worse than the wait not being there. D= 

I also added a wait with 10 frames to the effect that caused the sprite to flash. 

 

[Andar]

how do you define "worse"?

The main problem with animations here is that you can only play one animation at a time. If a new animation is commanded before the older animation is completed, that command is ignored.

If you give an animation command before the animation is completed, that will cause lag without giving a result. The entire game will slow down.

If you give an animation several frames after the animation ended, that will cause a gap when the animation isn't played - the player will be able to do something, but the animation effect itself will look as if it has a slowdown or a delay, but that delay is not cause by lag (not slowing down everything)

Depending on when and where the wait is placed, it might need to be one frame more than the animation, the same number of frames or one frame less.

That is something you'll have to test yourself because it might differe depending on the event structure.

If the animation is longer, then the waits will also cause a delay on activating the animation the first time - for a 60-frame-animation that could cause a delay of up to one second for example. If you want to reduce the delay for those cases, you'll need to experiment with wait numbers that are divisors of the needed number - if you need a wait of 60, then a wait of 15 would still enable you to hit the correct frame for restarting the animation, it would just cause three failed commands in the time between (but reduce the maximum delay to 15 due to those tries).

As you can read above the effects of having too few or too many waits are very similiar, and if you can't see which is the case you'll have to experiment with the number used.

 

[CallMeKerrigan]

Thanks for the information. =]

I just found out about the 'balloon' command, though. Heh. Didn't know it existed. Does what my animation does with no lag. =]

But I'll keep in mind what you said for the future. Thanks!