Good Anti-Lag for parellel processes?

[Seriel]

I'm looking for a good anti-lag to stop  the lag caused by a Parallel Process that is always active.

Like this event:

Spoiler

It seems to be causing lag on my PC, so I can't debug the game very well.

Thanks for any help!

 

[Tsukihime]

How have you determined it causes lag?


You can start by turning those one script call, which runs much faster than executing a bunch of separate commands.

 

[Andar]

There is no antilag-script to help in these cases, because the antilag scripts usually work by disabling unneccessary events.


The only way to remove lag from parallel processes is by making sure that they are correctly designed and that they are only used when needed.


In this specific case I think a simple wait(10) at the end of the process should be able to solve everything.


The reason why parallel processes can cause lag is because they're called sixty times per second. I don't think you need to update those variables sixty times per seconds, because no one can move that fast in the game.


The wait command tells a parallel process to skip the next X frames, so a wait(10) results in the process being executed only six times per second.


If the player can move faster than six steps per second you might have to reduce the wait, if he is slowed and there is still lag then you might experiment with higher waits - but that needs experimenting because it depends on your game settings.

 

[Seriel]

In this specific case I think a simple wait(10) at the end of the process should be able to solve everything.

Thank you! That worked, the FPS has gone up by about 20 now.

 

[_Shadow_]

Jaw dropping. And makes sense.

 

[Zeriab]

You were tricked by the bad naming. "anti-lag" scripts work by optimizing certain parts of the standard scripts so they are processed in less time. Yes, anti-lag scripts are not really anti-lag scripts, but it's the convention -_-

Be mindful of the way you structure your events. Eventing is a form of programming. There are almost always different ways of making things happen. The way you choose make them happen matters, sometimes very significantly.

Spoiler

I would argue that you can create an anti-lag script. Not that it would be what you want. # A game that is not running does not lagexit

*hugs*

 - Zeriab

 

[Shaz]

Think about what you're doing in that event. You're checking the player's position, along with a lot of other stuff that is not going to change very often. At least compared with the 60 frames per second that you're aiming for. You don't need to do all those checks and set all those variables 60 times a second. A wait of 10 frames is still making it check them 6 times a second. You could probably change the wait time to 15 or 20 frames - although just adding ANY wait would have given you back a lot of your CPU.


If you're still only running at 20FPS, I'd start looking at other parallel process events you have running and see if you've made the same mistake in those.


Just ask "how many times a second do these checks need to be done?" If only once, add a wait of 60 frames. If twice, a wait of 30 frames will do. Play the game and see how many tiles you can move (how many steps you can take) in 10 seconds and then work out how long it takes you to move one tile, or if you can move two or three tiles in a second. That'll help you decide how many times it needs to run, and how many frames you can wait after each iteration.

 

[Galenmereth]

How often do you check these variables, as in read them to do something with them? Because depending on that, it could also be better to not call this at all until needed. Have it be a common event that you call before checking the variables, so you know they're up to date there and then when you need them.

If you were to do that, I'd also consider splitting it up into two common events to call; one with the map's position data and terrain and region data, and one with the statistics, as these two have very little to do with each other logically speaking, at least from my outside point of view. Should you need to refresh both in one go, calling two common events is still not an excessive amount of extra event calls, in terms of readability of your events

 

[Bex]

The Code in the Picture does not cost Frames.

I supose that youre System Eventcode is somewhere else allready overloaded and nearly collapse, that would explain why this 1Event less brought you more Frames.

I can recoment Mog Hunters Anti Animation Lag, because the normal Animation Tool function is buggy and can cause lag.

His normal Antilag i dont use right now, because Events outside of map behave differently and i dont like that at the moment.

Edit: Like others said, it can be that you dont even need that code in that Event.

 

[TheoAllen]

Everytime the variables / switches changed, it checked the entire map events. If you have 100 events it will also check all of the events even if it just a cosmetic event. Also, if you have a lot of event pages, it will also being checked. If you changed one variable in each frame, you also adds extra event as much as the total events on map. If you have 100 map events, then 600 extra check will be added in every second.

 

[Bex]

Theo Allen what you say isnt True i supose. Iam no Scripter only a Eventer which knows a few rgss3 commands.

But what i read and expirienced is different, what you are saying is wrong in my opinion.

 

[Galenmereth]

In this particular common event it won't run for every event on the map. But the problem with it was primarily that there was no wait command added to it; the engine tried to run it as many times as possible per frame update, which is not good. Just inserting a wait(1) would've made this one be a non-issue in the short run. However, it is simply good practice to avoid running things every frame unless absolutely necessary.

 

[TheoAllen]

Theo Allen what you say isnt True i supose. Iam no Scripter only a Eventer which knows a few rgss3 commands.

But what i read and expirienced is different, what you are saying is wrong in my opinion.

Then do not asume that you know everything. I'm not saying it's the main cause of lag. Because checking page might be fast and you wont notice. You can say I'm wrong in terms of the cause of lag. But you can not say I'm wrong in terms of the way how default script handle the variables and switches. Because they really handle it in that way. Unless you provide the proof that I'm wrong (technically by script).

Afterall, the cause of lag can be anything.

 

[Bex]

Switches are not asked every Frame. They are just Values that exist in the Engine.

Conditions are asked every Frame.

Clean Code just has Conditions and runs them when necesarry.

If you execute too much Conditions it can also cause lag in the Eventeditor (not sure with pur ruby script in scripteditor)

But its allowed to have some dirty code , it makes programming easier sometimes and as long the Game doesnt lag who cares if it does what it should)

But others say its good practice to practice and make clean code. (They are right but sometimes iam just lazy and on this Map i just use one Time  i make 5 instead of 2 paralell Events ) ok this goes off topic.

Ok so people often do the mistake and instead of using conditional branches in a correct way, they execute commandsa like set player movespeed, change grafic and stuff

like that every frame or with wait every 4 frames, insteed of just one time when needed. Such command cost several dozens more Performance than a simple conditional branch that got executet every frame or every 4.

You are correct about the number of Events and Eventpages , they get checked every frame and the code loops every felt 4frames.

(This is why some people use antilag script to reduce eventupdate on events that are just used for mapping or far out of range of view.

Sorry my english aint the best.

Edit: Mog Hunter Anti animation Lag  i can recoment to Fix some Bugs and make Movement smoother.

 

[TheoAllen]

They are just Values that exist in the Engine.

And whenever their value is changed, it also check the entire map. I just want to say that (I can provide the proof in default script if you ask me)

Not only switches, but also variables. Putting parallel process that change the variable value and being executed every frame will make them check all the events on the map every frame too. Hence why the recent posts suggest you to put additional wait to reduce the process.

I wont argue about the conditions since I'm not discussing that (and I agree with you).

 

[Sixth]

#-------------------------------------------------------------------------- # * Processing When Setting Variables #-------------------------------------------------------------------------- def on_change $game_map.need_refresh = true endIt WILL refresh the whole map upon switch/variable operations without any external/custom scripts.With an anti-lag script, it will only refresh events within the range specified in the script, but regardless, it WILL refresh all of the events as well as the map within that range, and that will most probably cause a big performance loss with the above parallel event.

And like the others wrote, that parallel event is an insult to FPS for sure.

It is not necessary to update all of that constantly, unless your eventing skills lack finesse.

Also you can ditch the variable operations in most of those stuff you stored in a variable.

I recommend you to take a look on this topic:

http://forums.rpgmakerweb.com/index.php?/topic/25759-script-call-collection-for-vxace/?hl=%2Bscript+%2Bequivalent

With the knowledge from that script, you can spare yourself from the annoyance of updating all these variables (meaning player's/event's position, battle count, actor's level, etc).

 

[Bex]

Ok intersting you 2.

I thought the Interpreter irretates through all the Events Every Frame in any case?

If that is true an extra update while switch change would be strange, because it would be checked in the next frame anyways!(?).

If you are absolute correct with what you say, thanks for this Information and it would back up the statement, Code should realy only performed once when needed or

as clean condition when it needs to be every frame.

(In my Eventing Performance testing i could not rebuild what you stated, can maybe some advanced Scripters give us some Technical Chineese about this ? )

Edit: Events on Paralell that do nothing are also using much much more performance than one that is not paralell.

So the Engine doesnt like much of them at the same Time. So its good to have less. Would not recoment more than 10.

Normally u just need 1 to3.

 

[Sixth]

Events are updated all the time, but updating them is not the same as refreshing them.


Take a look at the 'def update' method and 'def refresh' method in Game_Map and you will see the difference.


The refreshing takes place only when the @need_refresh variable is true and that very same variable will be set to false at the end of the refresh method and there is a good reason for that.


Refreshing anything without a stop (meaning ~60 times in 1 second) will kill the FPS, even if it is just a one line text refresh method.


That is why in every good script the refresh method comes with a condition attached.


This assumes that the refresh method actually does something, of course, and the name 'refresh' is just to simplify the discussion at hand.


Also if you want to test performance issues, get a low end PC with crappy specs. That way you will see every little performance issue easily. On a high specs PC you might not see every issue.


I know, I have a crappy laptop, after all.

 

[Galenmereth]

Not to push this too off-topic, but another good idea is to install a virtual machine; adjust the specs and see how your game does at various settings. Since RM is all 2d drawing and not utilizing the GPU, this is particularly compatible with virtual machine rendering.

 

[Bex]

Ok iam no Scripter that means i would not understand the logic how exactly the update works.

I have no Problems with having 100 Events on Screen and 200 to 300(Limit better 200 because i need Performance for other stuff too) on the Map.

Thanks for explaining and sharing.