Parallel Processing = game lag?

[McTricky]

Question: Does parallel processed events affect whether or not the game lags. To make my Skit system work, I've utilized a switch and a variable (as the Skit identifer), which all runs through a common event that's only activated when the aformentioned switch is on. The trigger is set as Parallel Process because I want to player to be able to press a button to activate the current Skit scene (like in Tales of games). It all functions somewhat okay so far.

Screenshot

Spoiler

Now the thing is, ever since I managed implented this, I've noticed that my larger maps (like 30x30 and up) has a bit of lag to them, and I'm wondering if it's because of the fact that this Parallel Processed Common Event is virtually ALWAYS on? The lag even appears in my large yet unpopulated maps.

If it's not the Parallel Process (or the only thing) that might cause lag on larger maps, any idea what else could be the issue? Thanks.

 

[Shaz]

Yes, parallel process events WILL cause the game to lag. Add a Wait for a few frames in there, in the inner loop, and see if it relieves it a bit (lets the parallel process come up for air, and gives everything else a look-in at the processor).

 

[McTricky]

Thanks for clearing that up, Shaz. The larger maps run a little more smoother now. I added a Wait time of 180 frames just after the variable operation.

Another question before I declare this resolved. I have (and most likely WILL do) multiple common events (3 so far) that all run by Parallel Process when the switch is on (which it is most of the time). So can I assume that the more of these Common Events for each and every skit the worse the game will lag?

 

[Link]

Yes, the more of any type of event will cause more lag.

 

[Victor Sant]

In fact a few parallel process will not cause lag alone, unless it's a very resource use event.

So only heave process events or a lot of parallel process will cause lag, in any case, the solution shaz sugested works, add wait times so there's a small interval between the events.

The longer the event, the more likely to cause lag, since most events are processed at a single frame, unless it's a event that requires graphic update (like display messages)

 

[McTricky]

Right, understood. I might have to re-think how I'm going to implement this feature...

In any case, thanks again for clearing that up, you guys!

 

[Celianna]

I suggest to not use any wait commands when you are relying on a button input from the player. This will cause lag and errors, and sometimes it won't even work when the player presses the button.

For other parallel processing events that don't require to be up-to-date constantly, you can use a wait command of 1 frame. Exit event processing also helps if it's a long event.

But the one you have right now shouldn't lag at all. You really only start to notice lag if you have a lot of parallel processes running at the same time (say, around 6 of them). It also depends on how many commands you have inside of the event.

 

[McTricky]

This will cause lag and errors, and sometimes it won't even work when the player presses the button.

Putting the Wait command in the conditional branch right after the event caused it to be inoperable for 3 seconds before the play can reactivate again. Having it not work sometimes would probably only be the case if the wait command was outside the Conditional Branch.

But the one you have right now shouldn't lag at all. Your really only start to notice lag if you have a lot of parallel processes running at the same time (say, around 6 of them). It also depends on how many commands you have inside of the event.

Well, I think I found a way to avoid the use of multiple Common Events, with the use of Yanfly's Button Common Events script. I just use one Parallel Proccessed Common Event to run all the skit scenes (non-parallelled events) by using multiple conditional branches in that event.

So far it works a treat.

So far... xD

 

[Celianna]

Putting the Wait command in the conditional branch right after the event caused it to be inoperable for 3 seconds before the play can reactivate again. Having it not work sometimes would probably only be the case if the wait command was outside the Conditional Branch.

It's just the wait command itself that causes the slight lag in which the player may have pressed the button, and it didn't register that because it was 'waiting' at that exact moment. 1 frame might not seem like much, but if you press the button several times in a row, you'll see that it'll fail to register quite a lot of times. Anyway, the point is, you don't really want to add wait commands when button inputs are being used.

Well, I think I found a way to avoid the use of multiple Common Events, with the use of Yanfly's Button Common Events script. I just use one Parallel Proccessed Common Event to run all the skit scenes (non-parallelled events) by using multiple conditional branches in that event.

That's one way to do it, scripting is a better alternative in this case

This thread is being closed, due to being solved. If for some reason you would like this thread re-opened, please report this post and leave a message why. Thank you.