"@" vs. "delayed if-loop"

[Spitfire 0]

I'm afraid we'll really need Suma or someone other from BIS to answer my question but feel free to speculate...

I've been doing a huge mission for some time now and recently I realized the mission getting a bit CPU hungry. I decided it's time to optimize before I have too much scripts to scroll through.

I have a lot of pending @ -commands running in various scripts just waiting to be triggered. I think that @ being a hardcoded function it could be very well optimized not to use up too much processor time. However, I'd like to know which consumes more CPU cycles:

@(player in vehicle)

or

#waitToEnterVehicle

~0.5

?!(player in vehicle) : goto "waitToEnterVehicle";

What I really wish to know is that is @ polled every single cycle or does it have a delay of it's own? And if I'd like to lessen the CPU load considerably how long of a delay I should use in the if-example? I might not need to poll the condition any more often than twice a second or so.

This will be more of an issue when there are like 5 or more conditions in the same line waiting to be fulfilled, which is the case in my mission. I know this is starting to sound like nitpicking but every frame counts

Thank you

Edited February 26, 2011 by Rellikki
Fixed the code mess

[Prospero 1]

It's a very good question. I have always assumed that they are identical - synonyms for conditions. I try to avoid such statements wherever possible (where a long-hand approach can be achieved), as conditions seem to be executed relatively slowly in OFP.

I read with interest that v1.85 has a "preprocess file" widget. Of course, I'm hoping that this means we can compile scripts - if so... awesome.

Edit: I doubt very much whether it is polled every cycle (sim rate rather than screen rate?). There seems to be very little difference between ~0.01 and ~0.0000001.

Prospero

[bn880 5]

I am going to guess here (although I have done some work on compilers):

~0.5

condition

jump

is probably more efficient than

@condition

it is likely that the ~0.5 is easy on the CPU for every game cycle, it may be stored in a stack for game cycles and only interpreted once the time has come, so close to 0 load? Or the interpreter might create a time out of ~0.5 + mission time, and at every game cycle compare that to the current mission time.

The point is, comparing 2 time values, or waiting for some stack to run down, is less intensive that doing the @condition check every cycle, which may be long ie: this || (this && this) || that

but

~0.0000001

I'm not sure, it depends on how the ~ is designed.

To know for sure the most efficient and still reliable wait for a condition we will have to see what an OFP developer says.

[Spitfire 0]

I am going to guess here (although I have done some work on compilers):

~0.5

condition

jump

is probably more efficient than

@condition

I thought as much also. I'm afraid there's no ultimate answer for this problem since it really depends on the amount of conditions used and the delay. My mission has dozens of @'s which all look pretty much like this:

@((passenger distance car < 15) && (player in car) && (speed car <= 0) || !(alive passenger) || !(player in car)) || !(canmove car)

Having all those ands & ors will most certainly stress the CPU when they are executed every game cycle All those conditions would probably be much easier on the CPU if all the tests were a done by looping if-clauses.

But it really depends on how the command interpreter has been designed.

Edited February 26, 2011 by Rellikki
Fixed the code mess

[Chris Death 0]

May i add a question in here two?

If there really would get someone to read this thread

(i mean someone who knows ) could we maybe also

get compared, what eats more cpu power:?

Triggers (e.g: waiting for boolean, numeric variable, unit-status, syncronized with anything, checking an area,

placeholder triggers (to use their trigger_list by trigger-name,

etc.)

to

@conditions_in_scripts

AND

#loops

in_scripts

~000001

goto "loops"

I've neaver seen written black on white, that script conditions/loops are faster/slower than triggers,

only rumours, and even those move into different

directions. Some say trigger's, others are saying scripts

are faster.

Or could at least somebody keep this thread alive, until

a developer says: "enough is enough, now you will get your

information"

~S~ CD

[suma 8]

I am going to guess here (although I have done some work on compilers):

~0.5

condition

jump

is probably more efficient than

@condition

it is likely that the ~0.5 is easy on the CPU for every game cycle, it may be stored in a stack for game cycles and only interpreted once the time has come, so close to 0 load?

I confirm this.

Edited February 26, 2011 by Rellikki
Fixed the code mess

[suma 8]

@conditions_in_scripts

AND

#loops

in_scripts

~0.00001 // <- quote fixed added decimal point

goto "loops"

Those two are almost identical. ~0.0001 will get executed once per frame (unless your fps is higher than 10000).

Edited February 26, 2011 by Rellikki
Fixed the code mess

[suma 8]

Triggers (e.g: waiting for boolean, numeric variable, unit-status, syncronized with anything, checking an area,

placeholder triggers (to use their trigger_list by trigger-name,

etc.)

to

@conditions_in_scripts

Trigger are evaluated approximatelly twice per second, therefore they are less CPU intensive than script conditions. Trigger with condition condition used almost the same CPU power as script

~0.5

@condition

Triggers associated with area may require more a little bit more CPU power, as vehicles need to be checked to see if they are entering/leaving the are. The perfomance hit should not be significant though. If you want to know exact numbers, some measurements would be necessary.

Edited February 26, 2011 by Rellikki
Fixed the code mess

[suma 8]

I read with interest that v1.85 has a "preprocess file" widget. Of course, I'm hoping that this means we can compile scripts - if so... awesome.

No, it means file can be preprocessed with C-like preprocessor when loaded into variable. You will find more about this in command reference once 1.85 is out.

Edited February 26, 2011 by Rellikki
Fixed the code mess

[Prospero 1]

Interesting stuff.

Any chance of implementing interrupts in scripts?

(OK... I'm joking... well... maybe not...).

Regarding the loop delay (~0.00001): surely it is largely inconsequential (ok, up to a point), because commands executed within a timed loop have varying priorities? Or... perhaps they all have relatively low priority?

I've partcularly noticed this when attempting to implement objects with my own scripted physics models. It would be lovely to get visually "smooth" results, but unless I could perhaps sync to the frame rate via an interrupt, things always jitter a bit. I fully realise that OFP wasn't designed to support this, but hey, I like playing with this stuff.

Prospero

[Prospero 1]

----------

#loop

_timestep = Time - _oldtime

_oldtime = Time

goto "loop"

----------

Can the middle two lines be reduced to one? And can the interpretation of one single line be interrupted?

Edit: I better add why I'm asking this. OK, imagine the following scenario:

----------

#loop

_timestep = Time - _oldtime

<The OFP game engine now goes off and does something really time consuming>

_oldtime = Time

goto "loop"

----------

Result is buggered timing for one's scripted physics.

Prospero

Further edit: Yes, some people may ask, "But since you can't guarantee that a setPos will be carried out directly after the time interval is calculated, what's the point?"

Well the point is that although you'll get an "inaccurate" update of your physics setPos due to this unavoidable fact (in terms of timing/velocity), the error will be taken into account next cycle. I.e. the error is not cumulative if this problem can be solved.

[Chris Death 0]

wow that was fast

Suma, thanx for the time and for your answers

~S~ CD

[Spitfire 0]

wow that was fast

My sentiments exactly.

Now that BIS has finally finished working with the 1.85 patch they have time to take part in the forum again

Edited February 26, 2011 by Rellikki
Fixed the code mess

[RED 0]

Thanks suma I have been woundering about this for a while.

RED

[Prospero 1]

----------

_clock = Time

_oldtime = _clock

#loop

_nowtime = Time

_timestep = _nowtime - _oldtime

; Do physics calculation here, based on the time step.

(Edit: There is really nothing very much you can do to adjust for the time it will take for this calculation, but at least the "error" isn't cumulative over multiple loop cycles, and is likely to be pretty "constant").

_clock = _clock + _timestep

hint format ["Clock %1\nTime %2\n", _clock, Time]

_oldtime = _nowtime

~0.001

goto "loop"

----------

I think this answers my own question. Hehehe I'm so dumb!

Prospero