User Tag List

Page 1 of 2 1 2 LastLast
Results 1 to 10 of 14

Thread: When to use the always event

  1. #1
    Clicker Fusion 2.5 (Steam)

    Join Date
    Aug 2010
    Location
    Sweden
    Posts
    59
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)

    Question When to use the always event

    Hi,

    This is a somewhat awkward and embarrassing thing to ask but I never really gave much thought about the always event when building my game.
    I just recently began to think of it more as my newly implemented z-index system caused the game to crash sometimes at the start of the frame.

    The way I built my z-index system was like this:

    - - -
    • Always
    "Layer Object": Decreasing Sort by Alterable Value IZ : non-alts default to 0

    • Always
    "Player Sprite": Set Alterable Value IZ to 99
    "Player Projectile": Set Alterable Value IZ to 100

    (...and the list goes on for multiple other objects)
    - - -

    Is this way of doing things very unoptimized?

    Would it be better to change it into something like this instead?

    - - -
    • Always
    "Layer Object": Decreasing Sort by Alterable Value IZ : non-alts default to 0

    • Alterable Value IZ of "Player Sprite" = 0
    "Player Sprite": Set Alterable Value IZ to 99

    - - -

    I was wondering if perhaps the always event might be way more demanding as it might try to change/update Alt Value IZ to 99 even though the value already is 99?
    I tried to search around but couldn't find any best practice for how/when to use the always event.

  2. #2
    Clicker Fusion 2.5 DeveloperAndroid Export ModuleiOS Export ModuleSWF Export Module
    Fusion 2.5 (Steam)Fusion 2.5 Developer (Steam)Android Export Module (Steam)HTML5 Export Module (Steam)iOS Export Module (Steam)Universal Windows Platform Export Module (Steam)
    Popcorn's Avatar
    Join Date
    Jun 2006
    Location
    Norway, Bergen
    Posts
    2,344
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    I don't think this is something to worry about unless the action involves writing to disk or alot of complex calculations. Keep in mind that when you only use Always, Fusion doesn't need the extra calculation it must do if it has to check for a condition. But as far as I know, if you write to a file, it may be smart to test if what it is writing is the same of what's already there, because writing to files are slower than reading from files.

  3. #3
    Clicker Fusion 2.5 DeveloperFusion 2.5+ DLCAndroid Export ModuleHTML5 Export ModuleiOS Export ModuleSWF Export ModuleXNA Export ModuleUnicode Add-on
    mobichan's Avatar
    Join Date
    Oct 2007
    Location
    Buffalo, NY
    Posts
    3,274
    Mentioned
    26 Post(s)
    Tagged
    0 Thread(s)
    The layer objects sorting function is expensive. You should only do it when necessary. Definitely try to avoid always conditions if you can. Even something as simple as “number of object > 0 is a better way to always perform an operation on something.

    What Popcorn is saying is true but there is usually a more optimal way to handle actions than Always. For sorting, try to think of the situations in your game where you really need to run a sort action and limit it to that. Maybe it is only when a new object is created or when your player changes y position.

  4. #4
    Clicker Fusion 2.5 (Steam)Fusion 2.5 Developer (Steam)Fusion 2.5+ DLC (Steam)Android Export Module (Steam)HTML5 Export Module (Steam)iOS Export Module (Steam)Universal Windows Platform Export Module (Steam)
    Volnaiskra's Avatar
    Join Date
    Jan 2014
    Location
    www.sprykegame.com
    Posts
    2,131
    Mentioned
    76 Post(s)
    Tagged
    0 Thread(s)
    Always is probably the cheapest condition there is, since it's basically no condition at. There's nothing for Fusion to check so it can move straight onto the actions. But of course if those actions are expensive, or don't need to be performed frequently, then performing them each frame will become expensive, as mobichan pointed out.

    But there are times when always will save you performance. For example this is inefficient:

    -if player is overlapping window
    ...... Make window invisible

    -if player is not overlapping window
    ....... Make window visible.


    Testing for overlap is expensive, while changing visibility is not. So the above example is inefficient because each frame it must check overlaps twice and change visibility once. If you used always, you'd get the same result with only checking overlaps once (and changing visibility twice) :

    -always
    ...... Make window invisible

    -if player is not overlapping window
    ....... Make window visible.

  5. #5
    Clicker Fusion 2.5 DeveloperFusion 2.5+ DLCAndroid Export ModuleHTML5 Export ModuleiOS Export ModuleSWF Export ModuleXNA Export ModuleUnicode Add-on
    mobichan's Avatar
    Join Date
    Oct 2007
    Location
    Buffalo, NY
    Posts
    3,274
    Mentioned
    26 Post(s)
    Tagged
    0 Thread(s)
    I am curious the difference the limiter Only one action per loop would be in comparison to always in this case. It has become a habit to never run anything every frame unless it is absolutely necessary. But at the end of the day, the cpu hit is going to depend on the particular use case. If you are managing 100 things with these actions your going to get a different hit than 4 things.

    In the case of sorting, you might do better to manage sort updates with foreach loops if you don’t want the hit of sorting tons of actives. One way to limit the sorting scope would be to have a larger detector that scopes the sortable objects to a radius around the player. Or do that with math if there aren’t a lot of objects.

  6. #6
    Clicker Fusion 2.5 (Steam)

    Join Date
    Aug 2010
    Location
    Sweden
    Posts
    59
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Thanks for all the answers!

    So to get this clear, if my game is running at 60 fps there will be 60 "unnecessary" updates for every always event that is already set?

    For example:
    • Always
    "Object": Set Alterable Value IZ to 99

    = Updates/Changes Alt Val IZ 60 times per second even though Alt Val IZ already is 99

    whereas

    • Alterable Value IZ of "Player Sprite" = 0
    "Player Sprite": Set Alterable Value IZ to 99

    = Only updates once at the whole running session if Alt Value IZ is 0 at the start of the frame?


    Earlier when I didn't put much thought into this I somewhat carelessly assumed that there would be no updates if an event already had the condition the code asked it to update to.

  7. #7
    Clicker Fusion 2.5 DeveloperFusion 2.5+ DLCAndroid Export ModuleHTML5 Export ModuleiOS Export ModuleSWF Export ModuleXNA Export ModuleUnicode Add-on
    mobichan's Avatar
    Join Date
    Oct 2007
    Location
    Buffalo, NY
    Posts
    3,274
    Mentioned
    26 Post(s)
    Tagged
    0 Thread(s)
    You are correct. It will update every event loop. In your case, 60 times per second.

  8. #8
    Clicker Fusion 2.5Fusion 2.5 Mac
    Fusion 2.5 (Steam)Fusion 2.5 Developer (Steam)Android Export Module (Steam)HTML5 Export Module (Steam)iOS Export Module (Steam)Universal Windows Platform Export Module (Steam)
    zip2kx's Avatar
    Join Date
    Jun 2015
    Posts
    774
    Mentioned
    17 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Volnaiskra View Post
    Always is probably the cheapest condition there is, since it's basically no condition at. There's nothing for Fusion to check so it can move straight onto the actions. But of course if those actions are expensive, or don't need to be performed frequently, then performing them each frame will become expensive, as mobichan pointed out.

    But there are times when always will save you performance. For example this is inefficient:

    -if player is overlapping window
    ...... Make window invisible

    -if player is not overlapping window
    ....... Make window visible.


    Testing for overlap is expensive, while changing visibility is not. So the above example is inefficient because each frame it must check overlaps twice and change visibility once. If you used always, you'd get the same result with only checking overlaps once (and changing visibility twice) :

    -always
    ...... Make window invisible

    -if player is not overlapping window
    ....... Make window visible.
    Nice, I never thought of this. I've just avoided Always events as much as I could.

  9. #9
    Clicker Fusion 2.5 DeveloperFusion 2.5+ DLCAndroid Export ModuleHTML5 Export ModuleSWF Export Module

    Join Date
    Jul 2006
    Location
    Norway
    Posts
    325
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Speaking of the "Always" condition. Does anyone know what the purpose of the "Never" condition?
    I have never (no pun intended :-P) used the Never condition before and I don't really see the point of a condition that always turns false.
    If I want a certain event to not trigger at all for troubleshooting purposes, I just disable the event.

  10. #10
    Clicker Fusion 2.5 DeveloperFusion 2.5+ DLCAndroid Export ModuleHTML5 Export ModuleiOS Export ModuleSWF Export ModuleXNA Export ModuleUnicode Add-on
    mobichan's Avatar
    Join Date
    Oct 2007
    Location
    Buffalo, NY
    Posts
    3,274
    Mentioned
    26 Post(s)
    Tagged
    0 Thread(s)
    It was created before the disable option. It is now redundant.

Page 1 of 2 1 2 LastLast

Similar Threads

  1. Event reuse with global event workflow?
    By elvisish in forum Fusion 2.5
    Replies: 15
    Last Post: 18th April 2019, 02:15 PM
  2. Replies: 3
    Last Post: 6th May 2017, 12:03 AM
  3. Replies: 4
    Last Post: 2nd November 2016, 12:40 PM
  4. Replies: 2
    Last Post: 23rd January 2014, 08:22 PM
  5. Replies: 3
    Last Post: 14th October 2013, 12:54 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •