Jump to content
Leopard20

Using "sleep" - How to account for low FPS?

Recommended Posts

1 hour ago, Leopard20 said:

@Dedmen

Thank you very much for your help!

 

I rewrote my mod codes and ditched all while and waitUntil for stacked "onEachFrame" event handlers. Now the code runs fluently, even at extremely low FPS! What's really strange is that I don't notice much difference in CPU consumption! Why didn't I do this before?! ;)

 

Just one thing: I assume it's OK to remove and add stacked EHs multiple times, right? (Based on our previous discussion:

)

BTW, if I add a new stacked EH having the same ID as the previous one, does the old one get replaced with the new one? (right now I'm assuming yes!)

 

Not sure what you mean by adding an EH with the same ID as a previous one, since you have no control over which ID an EH receives.

 

Best practice would be to have one single type of eventhandler that does everything,

stuff that needs to be done on every frame can be put inside one single eachFrame EH, it's preferred and should execute faster:

 

//bad:
{
	addMissionEventHandler ["EachFrame",{
		//do something
	}];
} forEach allUnits;

//preferred:
addMissionEventHandler ["EachFrame",{
	{
		//do something
	} forEach allUnits;
}];

Cheers

Share this post


Link to post
Share on other sites
4 minutes ago, Grumpy Old Man said:

 

Not sure what you mean by adding an EH with the same ID as a previous one, since you have no control over which ID an EH receives.

 

Best practice would be to have one single type of eventhandler that does everything,

stuff that needs to be done on every frame can be put inside one single eachFrame EH, it's preferred and should execute faster:

 


//bad:
{
	addMissionEventHandler ["EachFrame",{
		//do something
	}];
} forEach allUnits;

//preferred:
addMissionEventHandler ["EachFrame",{
	{
		//do something
	} forEach allUnits;
}];

Cheers

More on that here:

https://community.bistudio.com/wiki/BIS_fnc_addStackedEventHandler

Share this post


Link to post
Share on other sites
24 minutes ago, Grumpy Old Man said:

Don't use the BIS function, use addEventHandler/addMissionEventHandler instead.

 

Cheers

If you don't mind me asking, why?!

 

I'm using it in every part of my mod now (have used it before too). Nothing seems wrong with it.

 

Besides I once noticed a weird slow down (more like "hiccups") when I deleted and added the event handlers the way you suggested.

Share this post


Link to post
Share on other sites
29 minutes ago, Leopard20 said:

If you don't mind me asking, why?!

 

I'm using it in every part of my mod now (have used it before too). Nothing seems wrong with it.

 

Besides I once noticed a weird slow down (more like "hiccups") when I deleted and added the event handlers the way you suggested.

Engine based script commands will always be faster than calling a function.

 

Chees

Share this post


Link to post
Share on other sites
3 hours ago, Leopard20 said:

difference in CPU consumption

Arma is basically always on 100% load anyway.. sooo...

You'd probably only feel it in your fps being lower.

 

3 hours ago, Leopard20 said:

I assume it's OK to remove and add stacked EHs multiple times, right?

It's just adding a piece of code to an array and removing it again. Basically the same as with "normal" EH's.
Btw stacked EHs is a bit unclear. The Engine addEventHandler/addMissionEventHandler are also stacked. But I assume you mean the BIS_fnc

 

 

2 hours ago, Grumpy Old Man said:

//preferred: addMissionEventHandler ["EachFrame",{ { //do something } forEach allUnits; }];

Still bad. Because of Eventhandlers being recompiled.

Depending on how much code you have in the eventhandler. This is most likely better

addMissionEventHandler ["EachFrame",{ call LEO_fnc_EachFrameCode; }];

 

1 hour ago, Grumpy Old Man said:

Don't use the BIS function, use addEventHandler/addMissionEventHandler instead.

The BIS function is more performance friendly and can also pass arguments to the handler.

 

1 hour ago, Grumpy Old Man said:

Engine based script commands will always be faster than calling a function.

No. Totally not true. Depends on the command and depends on what exactly you are talking about.

a nearestTerrainObjects over the whole map is not faster than a simple

call {hint "hi";}

 

And as we are talking about Eventhandlers. The actual execution of the Eventhandlers is most likely slower as they have to recompile their entire script which BIS_fnc_addStackedEH only does once for all the stacked EH's.

  • Like 4

Share this post


Link to post
Share on other sites
4 hours ago, Leopard20 said:

BTW, if I add a new stacked EH having the same ID as the previous one, does the old one get replaced with the new one? (right now I'm assuming yes!)

Yes

 

2 hours ago, Grumpy Old Man said:

Engine based script commands will always be faster than calling a function.

Makes little difference in this instance as the function itself adds mission events.

 

It even prevents this behaviour...

...by automatically stacking equivalent event types together eachFrame, playerConnected, mapSingleClick etc. e.g

Would actually result in just one mission OEF event.

EDIT: Thought I had better go and check what I wrote, remembering that stacked events had a rewrite a few patches ago. Events of the same type are no longer stacked into one event of said type.

 

The only extra is the function evaluating passed arguments (which is all done in a isNil {} check, so within a frame) . Using the function just provides an easy way of tracking, overwriting of added mission events via a STRING id.

All in all for a lot of people I would say using the BI stacked event handlers is a better solution.

 

  • Like 4
  • Thanks 1

Share this post


Link to post
Share on other sites
8 hours ago, Dedmen said:

As I said no priority. Every unscheduled script is executed. What you could mean by "priority" here is that if ACE's scripts are slow, they lower your FPS instead of just "scheduling" till the next frame. But to prevent that we make extensive use of my Profiler.

And it's also intended like this. No one wants to wait a minute after a button press for something to happen.

 

I meant that your resource are not infinite and every time you run unscheduled, you don't run any other code (by definition). So, ACE3 policy seems a little bit "me first, then the others", banning all waitUntil and sleep (like Leopard20 asked). Just saying, pushing this method at its uttermost, I think you can have FPS drop on heavy scripts. And sometimes, you don't need at all a so quick response. It's something to have no delay when you push a button, it's some other thing to "wait" for a scenario sequence based on condition true (or a trigger: 0.5 sec and it's fine most of the time).

As Leopard20 wrote: Now the code runs fluently, even at extremely low FPS!  So? no FPS gain? ...

 

I don't understand: "But to prevent that we make extensive use of my Profiler."

 

I don't want to argue about your considerations. You're right about the usage of EHs anytime you can. The onEachFrame one can be a false friend if the code is very heavy and (that happens) not optimized on its own.

 

@Leopard20 stacked EHs means that you can run several instances of the same one. (only with this BI function). If you have the same id (handle), you will refer to the last one (like for deletion). You could find a way to distinguish them.

EDIT: sorry, I didn't see @Larrow's answer.

 

  • Thanks 1

Share this post


Link to post
Share on other sites
3 hours ago, Dedmen said:

The BIS function is more performance friendly and can also pass arguments to the handler.

Exactly another reason why I prefer the BIS_fnc one!

 

3 hours ago, Dedmen said:

Arma is basically always on 100% load anyway.. sooo...

You'd probably only feel it in your fps being lower.

Really? My CPU usage barely goes over 70%! Weird...

Share this post


Link to post
Share on other sites
16 hours ago, Leopard20 said:

Really? My CPU usage barely goes over 70%! Weird...

Arma is 95% single threaded. Windows Task Manager cannot show that correctly.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×