Difference between revisions of "Talk:Every-time-argument"

From FreeSpace Wiki
Jump to: navigation, search
(New page: Need to clear something up: Isn't it that they are evaluated every frame rather than executed every frame? While the conditions are not met they should not add a greater load than a standa...)
 
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
 
Need to clear something up: Isn't it that they are evaluated every frame rather than executed every frame? While the conditions are not met they should not add a greater load than a standard when or when-argument (which are also evaluated every frame, at least until they've triggered once). I see no problem with having the warning there, they definitely should only be used with care and by those who know what they're doing, just want to make sure it doesn't give out wrong info. [[User:Shade|Shade]] 07:22, 8 August 2007 (CDT)
 
Need to clear something up: Isn't it that they are evaluated every frame rather than executed every frame? While the conditions are not met they should not add a greater load than a standard when or when-argument (which are also evaluated every frame, at least until they've triggered once). I see no problem with having the warning there, they definitely should only be used with care and by those who know what they're doing, just want to make sure it doesn't give out wrong info. [[User:Shade|Shade]] 07:22, 8 August 2007 (CDT)
 +
 +
*Yeah, it's "evaluate" rather than "execute".  I corrected it accordingly.  The reason I put that bit about the framerate is because <tt>[[when]]</tt> uses optimizations to skip those parts of the sexp which have already become known.  <tt>[[Every-time]]</tt> clears those optimizations in each frame, so it will always evaluate the whole thing.  Now, you're on the right track; this is far from the most processor-intensive part of the code.  That honor probably belongs to something with the models or graphics -- probably the collision detection.  The more important issue is understanding the logic behind the concept. [[User:Goober5000|Goober5000]] 22:52, 9 August 2007 (CDT)
 +
 +
Yeah, shield collisions probably take that prize. But, even if it's a relatively small difference in load, it's still useful for people to know that there ''is'' an impact on performance, so it should definitely be here. Stuff like this is exactly why I insist on still keeping the seperate SEXP pages even when we have the big list. I also went and put a similar warning on the FRED example page that uses them most heavily so people won't think they can just throw 50 of those events into a mission and get away with it. - [[User:Shade|Shade]] 07:11, 10 August 2007 (CDT)

Latest revision as of 12:11, 10 August 2007

Need to clear something up: Isn't it that they are evaluated every frame rather than executed every frame? While the conditions are not met they should not add a greater load than a standard when or when-argument (which are also evaluated every frame, at least until they've triggered once). I see no problem with having the warning there, they definitely should only be used with care and by those who know what they're doing, just want to make sure it doesn't give out wrong info. Shade 07:22, 8 August 2007 (CDT)

  • Yeah, it's "evaluate" rather than "execute". I corrected it accordingly. The reason I put that bit about the framerate is because when uses optimizations to skip those parts of the sexp which have already become known. Every-time clears those optimizations in each frame, so it will always evaluate the whole thing. Now, you're on the right track; this is far from the most processor-intensive part of the code. That honor probably belongs to something with the models or graphics -- probably the collision detection. The more important issue is understanding the logic behind the concept. Goober5000 22:52, 9 August 2007 (CDT)

Yeah, shield collisions probably take that prize. But, even if it's a relatively small difference in load, it's still useful for people to know that there is an impact on performance, so it should definitely be here. Stuff like this is exactly why I insist on still keeping the seperate SEXP pages even when we have the big list. I also went and put a similar warning on the FRED example page that uses them most heavily so people won't think they can just throw 50 of those events into a mission and get away with it. - Shade 07:11, 10 August 2007 (CDT)