HomeUser Control Panel (unavailable in archive)ForumsTutorialsArt GalleryResourcesMaps

Need advide 'b. lag reducement.

01-29-2004, 08:22 AM#1
Remy
First read this:

Quote:
Sage the Mage wrote on 25-01-2004 17:55 PM:
Quote:
Remy wrote on 23-01-2004 16:35 PM:
Are you a triggere or a modeler or..?
Cause I need help with a question about JASS..

I'm building this map... (who's not..)
But though I've got a beast of a computer it runs kind of slow..:(
I've got some big loops and a lot of triggers/units and wel.. you get the point.
Now I was wondering if I could reduce the lag (enough to make it really matter) by triggering through JASS.. could you tell me?

To my knowledge, jass shouldn't significantly reduce lag for a map unless the computer itself is really slow. If the map is lagging because of the triggers only, you can probably improve how they are done in the gui.

Well, trying to reduce lag by rebuilding my triggers I have to make some choices. Difficult choices;)
What gives a lot of lag and what doesn't? Shall I replace this by that or not?

I need to know how trigger processing works: if a trigger runs say until the second line and then stops because of an 'if' or something similiar, will the length of the rest of the trigger effect lag?; It is slower to direct to a variable then directly to the thing you want to direct to?; how much slowness do variable arrays bring?; what should I avoid using?; and so on...

Oke for people with a somewhat similiar problem: I have noticed that using pick random [variable thing] from [another v.t.] gives a lot of lag, relatively speaking (within loop and all..).

Another thing: for anyone interrested in seeying what I am doing.
I am building a sort of AOS, but it is quite different from other AOSes, you might to see, though triggers are pretty complicated, you probably won't understand the heck of it:P

Thanks for all eventual help, remy.
01-29-2004, 10:15 AM#2
Cubasis
The source of lag is most very-likely your unit-spawning. I did not check out your map, but that's the only thing that comes to mind.

Maps don't often "lag" becouse of it's triggers. One can run 1000's of statements in a row without slowing the computer (well, the computer will hiccup at first). It depends on what you're doing. F.ex. stupid stuff like a periodic trigger that runs every 0.001 second of gameplay time doing some big stuff will ofcourse create lag.

Also, stuff you can do to improve it is to destroy triggers that you don't need anymore (after running them perhaps).

But again, generally what i think is causing your lag is your unit-spawning system. Most of the time, your triggers only create some memory leak, and they don't do anything untill you exit your map (it will take you a long while to do so, as it needs to unload everything). That's memory-leak, and happens with bad triggers. In-game lag happens becouse of doodads, units and such.

If you're creating a AOS you might wanna check out the Hive-Spawn system in Triggers-repistory forum, that's quite efficient.

Hope this helped

Cubasis
01-29-2004, 10:25 AM#3
matzzzz
theres a jazz command called something with bj_clearram or so

it reduces lag, but when were talking about it, i dont know how often to use it?
01-29-2004, 10:54 AM#4
Zarniwoop
use less units :ggani:
01-29-2004, 10:57 AM#5
Cubasis
heh matzzzz

Sorry, but there is no such function, it's not that simple, you clear leaks by building leak-less code.

What you are likely thinking about is a function/variable where, if set to true, then it will clean up the next use of For-each-unit-in-group statement. That's pretty cool. So whenever you are picking each unit in a group, set that to true, and you will avoid leaking the group.

Cubasis
01-29-2004, 11:31 AM#6
Grater
I notice actions like this run often:
Set
LivingUnitsInCurrentWAG = (Number of units in (Units in (Playable map area) matching ((((Matching unit) is alive) Equal to True) and (((Matching unit) is in AnotherAG) Equal to True))))

Altough the count looks innocent enough it leaks the unit group "Units in (Playable map area) matching..."
Because that action runs very often, on many "unit begins/trains a unit" events and inside loops it will result in much memory leaking and lagging. You should put the custom script action:
Custom Script: set bj_wantDestroyGroup = true
before every one of those count actions. Trust me it's a huge mutha memory leak.

Otherwise the use of "real" unit group variables and unit arrays seems to have avoided other unit group leaks, but I cannot fully asses that due to the size and complexity of the triggers.

In the "OrderLoop" trigger there are a couple of location leaks, set the location in the action to a global variable then destroy it with the custom script action:
Custom Script: call RemoveLocation(udg_TempLoc)
Where TempLoc is the variable name.

I dont really feel game enough to delve deeply into the logic of the triggers, but the two leaks I mentioned are serious and fixing them should result in noticable improvements.
01-29-2004, 01:07 PM#7
Remy
Oke so.. I can't fix in game lag (without changing anything within the game) but I can reduce exiting .. and loading time?
One last clear it all up:

Less triggers = less loading time?
Less usage of variables and functions reduces exiting time?
Less triggers which do not make use of variables or functions whatsoever does not reduce exiting time?
I can reduce exiting time by 'clearing' my variables and functions ingame, does this not, even if it isn't much, create lag?

Thanks for your time and effort trying to help me:)
01-29-2004, 01:32 PM#8
Narwanza
Let me try to explain how most in-game lag works. Say you create a unit at the center of a region. Well, the game needs to know where that point is, so it stores it into memory. This is all fine and good, until you have 30000 points in memory. You see, if your RAM is taken up by storing locations and groups that you are never going to use again, then what is going to process the game? Your harddrive? Most people don't have a harddrive fast enough to process WC3 without showing considerable lag. So if you remove the things you aren't even going to use again, then it frees up your ram to process the game instead of storing meaningless data. Now everytime you tell the game to create or pick something that is not really a defined point yet, like center of region, or playable map area, the game will define a point. Every time you tell it to do that it will create a point, so center of region does not act like a variable because it gets a new point every time. A better thing to do is set a variable equal to the center of a region and then tell it to create a unit at such a variable.

The reason it takes so long to get out of the game is because blizzard cleans up the trash before you exit. So if a map had a ton of memory leaks in it, well blizzard has to clean up the bad map makers mess. This causes the slow exiting times. So if you keep your RAM clean then exiting time will not be long either.

In most cases less triggers really doesn't decrease lag time. Now if you have 450 triggers in you map... well if you do you have serious problems. But just a lot of triggers shouldn't be too bad. Avoid lots of triggers that are like every .01 secs of the game, because they will cause lag eventually.

Properly used variables = less exiting time, and less in-game lag
Poorly used variable = longer exiting time, but not as long as if you didn't use variables.