I googled a lot, but couldn't find anything >.< When units enter an area I like to play some sort of "warp in special effect". I tried creating an actor there (and even deleting these actors afterwards), but the game becomes unbelievably laggy after a short period of time.
Simplified version of my trigger:
Did you try this in test mode only, or did you actually upload a test version to the battlenet and tested it there? This makes a huge difference, testing usually results in way more lags, especially if you use the debug window.
Did you try this in test mode only, or did you actually upload a test version to the battlenet and tested it there? This makes a huge difference, testing usually results in way more lags, especially if you use the debug window.
I only tried it locally and with debug window enabled. My thought process was: If it lags offline, I don't wanna know what it does with latency and people's not so good computers :E
But from your postcount I infer you know what you are talking about. Thank you for your tip. I will try it later at home.
NEVER test lag with the debug window open. The debug window causes tons of lag because it has to document each trigger, event, etc.
Also, latency won't make things lag more (It'll just make certain triggers less responsive like key press events, but not actually cause FPS lag) afaik
The debug window is the major source of lag, because it displays each and every single triggered event. If you deactivate it, you should have a fairly accurate indication of your ingame FPS already, but as far as I know, the test mode still tracks all the events and stuff for debug purposes, even if the actual window is disabled. So the only reliable test would be uploading the map and testing, if it lags on bnet.
I have noticed that when I am testing my map on my work computer (it's much slower than my home rig) that I absolutely need to close the terrain editor window before test launching or performance will be total crap. I'm sure this is pretty common knowledge, but it may help a bit!
Testing with multiple people is helpful too because you will probably have more events firing and threads running at once. It's not a big deal if your triggers are relatively basic, but for complex systems it's almost a necessity to test online with multiple people.
Testing with multiple people is helpful too because you will probably have more events firing and threads running at once. It's not a big deal if your triggers are relatively basic, but for complex systems it's almost a necessity to test online with multiple people.
Such a preliminary test is already scheduled with my friends.
However, how far should I go with my performance tweaks in SC2? Most of my life I made War3-Maps where every little bit of performance tweak should be implemented in order to allow the game to run smoothly (and not f*ck up the AI etc). This went so far, as to not update leaderboards every .5 seconds but only every 4secs.
Are such frequent updates ok in Starcraft 2 times? (The update just fills in data, does not compute anything complicated and a frequent update is justified, because there is a change of these stats multiple times per second.)
The Starcraft 2 scripting language and triggers are superior to WC3s, also you don't need to worry about something like memory leaks anymore usually. Also the engine itself is designed for more units etc on the map, generally for more models, more effects, more action in the game.
On the other hand the graphics are way more demanding in SC2, you can easily drop the FPS with huge amounts or high-res models and stuff.
I would say, it is not that important to optimize every little bit of code; a 0.5 second update rate for a leaderboard would not cause any trouble, if there is nothing else correlated to it. However, this was pretty much the case for WC3 as well, if you cleaned up memory leaks etc. You just need to care about, what you do, and how you do it. For example, doing stuff like setting variables or easy calculations 16 times a second is fine. Spawning some units is fine as well. But don't spawn units 16 times a second, that will definitely affect the performance.
Rule of thumb: Don't worry about one time actions or stuff, which happens less than 1 time per second, until you notice it causing problems. For everything faster than that, try to avoid costly functions like creating units or other complex objects and calculations. If you are unsure, feel free to ask again in the forums.
If you don't do something stupid, you most likely don't need to worry all that much about your trigger performance. The other big reason for performance problems is massive effect- and model spam. Large amounts or hugely scaled particle effects, units or doodads can easily cause some FPS issues.
The Starcraft 2 scripting language and triggers are superior to WC3s, also you don't need to worry about something like memory leaks anymore usually. Also the engine itself is designed for more units etc on the map, generally for more models, more effects, more action in the game.
On the other hand the graphics are way more demanding in SC2, you can easily drop the FPS with huge amounts or high-res models and stuff.
I would say, it is not that important to optimize every little bit of code; a 0.5 second update rate for a leaderboard would not cause any trouble, if there is nothing else correlated to it. However, this was pretty much the case for WC3 as well, if you cleaned up memory leaks etc. You just need to care about, what you do, and how you do it. For example, doing stuff like setting variables or easy calculations 16 times a second is fine. Spawning some units is fine as well. But don't spawn units 16 times a second, that will definitely affect the performance.
Rule of thumb: Don't worry about one time actions or stuff, which happens less than 1 time per second, until you notice it causing problems. For everything faster than that, try to avoid costly functions like creating units or other complex objects and calculations. If you are unsure, feel free to ask again in the forums.
If you don't do something stupid, you most likely don't need to worry all that much about your trigger performance. The other big reason for performance problems is massive effect- and model spam. Large amounts or hugely scaled particle effects, units or doodads can easily cause some FPS issues.
Thank you for you quick and broad explanation. I just ran the map online with three people and it was completely lag free despite 600 units getting perma psi-stormed (test wave meets test tower :-o). Me so happy \:D/
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Hi everyone,
I googled a lot, but couldn't find anything >.< When units enter an area I like to play some sort of "warp in special effect". I tried creating an actor there (and even deleting these actors afterwards), but the game becomes unbelievably laggy after a short period of time. Simplified version of my trigger:
Is there a better way to do this?
Hey.
Did you try this in test mode only, or did you actually upload a test version to the battlenet and tested it there? This makes a huge difference, testing usually results in way more lags, especially if you use the debug window.
I only tried it locally and with debug window enabled. My thought process was: If it lags offline, I don't wanna know what it does with latency and people's not so good computers :E But from your postcount I infer you know what you are talking about. Thank you for your tip. I will try it later at home.
NEVER test lag with the debug window open. The debug window causes tons of lag because it has to document each trigger, event, etc.
Also, latency won't make things lag more (It'll just make certain triggers less responsive like key press events, but not actually cause FPS lag) afaik
The debug window is the major source of lag, because it displays each and every single triggered event. If you deactivate it, you should have a fairly accurate indication of your ingame FPS already, but as far as I know, the test mode still tracks all the events and stuff for debug purposes, even if the actual window is disabled. So the only reliable test would be uploading the map and testing, if it lags on bnet.
I have noticed that when I am testing my map on my work computer (it's much slower than my home rig) that I absolutely need to close the terrain editor window before test launching or performance will be total crap. I'm sure this is pretty common knowledge, but it may help a bit!
Testing with multiple people is helpful too because you will probably have more events firing and threads running at once. It's not a big deal if your triggers are relatively basic, but for complex systems it's almost a necessity to test online with multiple people.
Such a preliminary test is already scheduled with my friends. However, how far should I go with my performance tweaks in SC2? Most of my life I made War3-Maps where every little bit of performance tweak should be implemented in order to allow the game to run smoothly (and not f*ck up the AI etc). This went so far, as to not update leaderboards every .5 seconds but only every 4secs. Are such frequent updates ok in Starcraft 2 times? (The update just fills in data, does not compute anything complicated and a frequent update is justified, because there is a change of these stats multiple times per second.)
The Starcraft 2 scripting language and triggers are superior to WC3s, also you don't need to worry about something like memory leaks anymore usually. Also the engine itself is designed for more units etc on the map, generally for more models, more effects, more action in the game.
On the other hand the graphics are way more demanding in SC2, you can easily drop the FPS with huge amounts or high-res models and stuff.
I would say, it is not that important to optimize every little bit of code; a 0.5 second update rate for a leaderboard would not cause any trouble, if there is nothing else correlated to it. However, this was pretty much the case for WC3 as well, if you cleaned up memory leaks etc. You just need to care about, what you do, and how you do it. For example, doing stuff like setting variables or easy calculations 16 times a second is fine. Spawning some units is fine as well. But don't spawn units 16 times a second, that will definitely affect the performance.
Rule of thumb: Don't worry about one time actions or stuff, which happens less than 1 time per second, until you notice it causing problems. For everything faster than that, try to avoid costly functions like creating units or other complex objects and calculations. If you are unsure, feel free to ask again in the forums.
If you don't do something stupid, you most likely don't need to worry all that much about your trigger performance. The other big reason for performance problems is massive effect- and model spam. Large amounts or hugely scaled particle effects, units or doodads can easily cause some FPS issues.
Thank you for you quick and broad explanation. I just ran the map online with three people and it was completely lag free despite 600 units getting perma psi-stormed (test wave meets test tower :-o). Me so happy \:D/