• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

[Trigger] Quick question about periodic events and the "quickness" of GUI

Status
Not open for further replies.
Level 5
Joined
May 20, 2008
Messages
138
Hello!
In my map I got a lot of periodic events running simultaneously. How many can I have before I seriously have to worry about them bogging down (slowing down) a full house 10 player map?

Also, I read JASS is faster blablabla but how much faster is it? Does that mean that a GUI triggered spell will have a 0.1 second delay in comparison to a JASS spell? I got a 10 player map where all spells and stuff are triggered in GUI and I am worried that this means that it will be running very slowly, since everyone says JASS is faster. But how much slower? Will 10 players casting a GUI triggered spell delay everything with a second or more? Or how noticeable is it?
 
Level 15
Joined
Sep 3, 2006
Messages
1,738
It depends on the content of your code. JASS is indeed faster, but unless you're creating a huge amount of leaks in your GUI I don't see it creating many problems.

You might want to cut down on your periodic timing though. (This is where timers come in handy lol)
 
Level 5
Joined
May 20, 2008
Messages
138
Thanks for your reply! Will timers consume less memory?

This is the trigger I am worried the most about:

  • Cam
    • Events
      • Time - Every 0.01 seconds of game time
    • Conditions
    • Actions
      • Player Group - Pick every player in P_CAMERAPLAYERS and do (Actions)
        • Loop - Actions
          • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
            • If - Conditions
              • P_CAMERA_CURRENT[(Player number of (Picked player))] Equal to 1
            • Then - Actions
              • Camera - Apply HERO CAM 1 normal view <gen> for (Picked player) over 0.00 seconds
              • Camera - Set (Picked player)'s camera Rotation to (Facing of P_HERO[(Player number of (Picked player))]) over 0.00 seconds
              • Camera - Lock camera target for (Picked player) to P_HERO[(Player number of (Picked player))], offset by (0.00, 0.00) using The unit's rotation
            • Else - Actions
          • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
            • If - Conditions
              • P_CAMERA_CURRENT[(Player number of (Picked player))] Equal to 2
            • Then - Actions
              • Camera - Apply HERO CAM 2 top <gen> for (Picked player) over 0.00 seconds
              • Camera - Set (Picked player)'s camera Rotation to (Facing of P_HERO[(Player number of (Picked player))]) over 0.00 seconds
              • Camera - Lock camera target for (Picked player) to P_HERO[(Player number of (Picked player))], offset by (0.00, 0.00) using The unit's rotation
            • Else - Actions
          • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
            • If - Conditions
              • P_CAMERA_CURRENT[(Player number of (Picked player))] Equal to 3
            • Then - Actions
              • Camera - Apply HERO CAM 3 <gen> for (Picked player) over 0.00 seconds
              • Camera - Set (Picked player)'s camera Rotation to (Facing of P_HERO[(Player number of (Picked player))]) over 0.00 seconds
              • Camera - Lock camera target for (Picked player) to P_HERO[(Player number of (Picked player))], offset by (0.00, 0.00) using The unit's rotation
            • Else - Actions
          • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
            • If - Conditions
              • P_CAMERA_CURRENT[(Player number of (Picked player))] Equal to 4
            • Then - Actions
              • Camera - Apply HERO CAM 4 <gen> for (Picked player) over 0.00 seconds
              • Camera - Set (Picked player)'s camera Rotation to (Facing of P_HERO[(Player number of (Picked player))]) over 0.00 seconds
              • Camera - Lock camera target for (Picked player) to P_HERO[(Player number of (Picked player))], offset by (0.00, 0.00) using The unit's rotation
            • Else - Actions
          • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
            • If - Conditions
              • P_CAMERA_CURRENT[(Player number of (Picked player))] Equal to 5
            • Then - Actions
              • Camera - Apply HERO CAM 5 low <gen> for (Picked player) over 0.00 seconds
              • Camera - Set (Picked player)'s camera Rotation to (Facing of P_HERO[(Player number of (Picked player))]) over 0.00 seconds
              • Camera - Lock camera target for (Picked player) to P_HERO[(Player number of (Picked player))], offset by (0.00, 0.00) using The unit's rotation
            • Else - Actions
I am worried that this trigger in combination with many 1 sec+ periodic events for damage over time and healing over time spells will bog down the map. If I launched a lot of timers running infinitely in the initialization trigger, would that be better?
 
Level 8
Joined
Feb 15, 2009
Messages
463
the fact is the nearly every GUI function is a BJ( i think u heard about ) which calls a Jassfunction afterwards e.g. CosBJ( real angle ) calls Cos( real angle * bj_DEGTORAD)
so if you make nearly everything to a native u will nearly get just the half of your function calls
also leaks can be cleaned much better in Jass ( even better u go with JNGP and veryJass[vJass] )
for sure some BJ's are helpful i like the GroupPickRandomUnit for example
 
Level 29
Joined
Jul 29, 2007
Messages
5,174
Periodic events are less good then timers, don't ask me why because I don't know. I once heard Poot saying that and I believe Poot.

In any case, you should stick as many things you can into one timer/periodic event in order to reduce the running threads (not sure if they're even threads, but you get what I mean).
This of course will look MEEEEEEGA ugly in GUI, but GUI looks already so ugly that it doesn't matter too much.

On a second note - why for all the gods do you run the iteration every 0.01 seconds?
Our eyes barely see beyond 16-18 frames per second, why the hell would you need 100 of them.
Tradition goes between 0.035 and 0.05 usually, so for speed-important things such as physics, you'd probably go with 0.035 or something close to it, and for other things you'd go with 0.05.
 
Status
Not open for further replies.
Top