Wait for... seconds?

Hello everybody,

I realised while coding events to start after some set time that the Wait for x frames is doing its job too well...

I mean, on a fast computer, 60 frames per second is easily obtained. But on a slow computer, a Wait for 240 frames can take longer that 4 seconds and break the synchronicity with other programmed events/animations.

Is there a way to tell RMVXA to wait for seconds instead of frames?

I think on slower computers, the game would lag if there was a lot of events on one map.

So to solve your problem, I think you could try using either of the two anti-lag script (which are on the master script list):

Victor's Anti-lag script

Yami's Simple Anti-lag Event

You also could use variables to calculate time based on the game clock.

Like starting a timer and using it as a time reference?

That could work, yes. I didn't think about that, thanks.

no, I mean using the game variable that is the Game Timer, the one that counts from the second you start the game, it will always be in seconds.

The Ace engine uses fixed timestepping, which means that if it lags (15fps, for example), it won't let any wait timers increase more than 15 frames. What this means is that you will never have events with wait commands go "out of sync". For every frame there's a "tick" where the engine updates every function and event; there's no multithreading that can let two events go out of sync, as everything's performed in order within that frame tick. I hope this explanation makes sense.

To go off on a tangent (and slightly off topic): This could become a problem if you use the engine for a platforming game, because a lower framerate at a fixed timestep can cause unwanted results for the player. If your physics are dependent on how long the player holds down the jump button (ala Mario games) and tied to a certain velocity / drag / gravity per frame, if the rendering lags to half optimal (30 fps), the player will not inately know this, and may let go of the button earlier than he should due to muscle memory, if your physics expect 60 fps. Thus in this case you'd want to implement physics bound to miliseconds since last frame update happened.

I'm trying to get a music fadeout and an event to synchronize, but they don't speak the same language.

RPG::BGM.fade() waits for milliseconds while the Wait command accepts frames per second.

My prototype is like this.

text "Start fading out the music"script RPG::BGM.fade(4000)Wait: 240 framestext "Event starts"On 60fps, it's synced.At 5fps, it's way too late.

Yeah, then you can get into some trouble... But you can do something like this:



It's a bit quick and dirty, but here's how it works:

• This works together with a BGM set on the map through the normal menus
• You need to define that BGM in a variable; @bgm_file in example
• You need to define the current (starting) volume; @bgm_volume in example
• Each frame we subtract (100.0 / (4.0*60.0) from the current volume variable. 4.0 is the amount of seconds you wish to fade it over; 100.0 is just max possible volume, and 60.0 is the optimal FPS
• If the volume variable is equal to or lower than zero, we stop the Audio playback, and break the loop
• The event that performs this must be parallell process, or else we freeze everything
• Since this event in my example is triggered using self switch A, I turn that off

Hope this helps; this should keep it in sync regardless of framerate, since the fade is now tied to each frame tick. I might make a script that lets you fade through frame ticks without all this workaround stuff, but right now the IGMC must be prioritized I'm afraid :)

I think I get the idea.
Although I'll have to add a Set variable (number 3 in this example) inside the loop as well, right?

$game_variables[3] = @bgm_volumeor better:
I can make a conditional branch checking the @bgm_volume directly.

Oops, yeah, that variable was a remnant of the old solution. You can use a script call in the conditional branch like you wrote, yep :) I updated the image to reflect this for visitors of the thread.