Using a lower game speed greatly improves CPU-limited frame rate.
You can change the game speed without changing the rate the game happens by rescaling timings to compensate.
There are a great many laggy custom maps on bnet set to the default faster speed which would cease to be so laggy if they just switched to slow or normal game speed and rescaled timings by 1.75 or 1.4, respectively.
If you are lazy, or just want to test it out, you can set global time scale to compensate for most data timings...
I have attached a test map which demonstrates this, and has a nice routine to change the 4 unit catalog entries that I know also have to be scaled(turning rate, acceleration etc.)
Unfortunately time scale has several bugs: it doesn't play well with cliff jumpers, it seems to be applied twice to walk animations(sadly a read-only catalog field), and it results in buildings finishing construction with less than full initial health. Depending on your map, it may be best to actually go through and edit all the timings manually.
On the test map I have included, on Low Graphics(ie CPU-limited) I get a frame rate of 45 to 55 initially, until the game speed and time scale are changed at the 2 minute(REAL time) mark. At that point I get about 95 to 100 fps. This is with leaving the camera aimed at empty space, ie the default position. If I keep the camera focused on the action then I get about 15 fps initially, and then about 30. In either case, this resulted in very significant frame-rate improvement.
I believe this all works because it lowers the number of game frames(ie, each atomic moment of all the game entities) that need to be calculated each real time second. If a person's CPU can't keep up with calculating the required number of game frames per second, then they will cause everyone to have to wait for them to calculate each game frame.. resulting in the kind of brutal lag that just slows everything down.
Although the test map uses it, I do not recommend using the 'slower' speed if you can at all avoid it... I've found it can easily cause noticable issues with fast moving missiles being barely rendered, if at all. I think that using normal speed would be fine for most modestly laggy maps, or if lag is a particularly bad problem for your map then I would suggest using slow.
Of course none of this will fix lag caused by triggers... this is generally most helpful for lag caused by having large numbers of units simply pathing and fighting.
Anyways, I am unsure about all the fields that will still need to be changed and issues that can arise after rescaling game speed and time scale. There will be lots of other random things, like creep growth rate, and particle effects animating slower(can this be changed without remaking the particle effect textures to skip frames?). It'd be nice to make some kind of comprehensive list....
This method is great, does allot for my map but one thing that bothers me is thatf the units gain 40% movement speed, like marine. 2.25+0.9. Its the global scale that make the unit faster, not sure how to solve that in the proper way.
I could sett all speeds to be "current speed * (1/1.4)" but this is not a very good way because when i hover the unit armor then it says something like 1.61+0.64 and that look just bad. And in aditon to tahtd oes the unit move 0.9 slower then in faster mode.
Is there some way to fix the global timing so it does not affect unit movement speed like its a buff?
Sherlia, if you are dead set on using the timescale method(rather than manually editing all timing numbers) you could perhaps simply apply a compensating movespeed debuff(apply a hidden behavior with a 1/1.4 snare) to all units and then scale their base movement up 1.4x via trigger or data editor? Of course this doesn't change that the units still have larger movespeed numbers than a player would expect given how fast they move across the screen(Sadly, I do not think there is a way to fix this other problem), but at least it should suppress it being reported as a buff.
As a warning, I could not get the global timescale method to work with preplaced cliff jumper units... they would launch themselves into space the moment they jumped a cliff. However it is easy enough to patch this by applying a local timescale to just cliff jumper units counteracting the global timescale, and then editing all the timing numbers manually. I would guess something similar can be done to ensure buildings that are built finish with full health. Still, even tho these bugs can be worked around it seems safer in the long run to me to avoid using timescale altogether given its bugginess. In particular, if when you start a map from scratch, you immediately build things around using normal gamespeed you will never have anything to worry about.
SupaCats, you suggest that animation speeds need to be adjusted when using the global timescale method. I do not think this is accurate except in the case of unit walk animation speeds (though maybe you have done more thorough testing). Also, interestingly enough you have to scale the walk animation speed in the OPPOSITE direction, ie slow them down... since it appears that walk animations end up receiving double the timescale scaling due to what I guess is a BlizzBug.
The MeatGrinderLagTest map I included in the first post included a nice (disabled) example trigger which set the gamespeed/global timescale and automatically went through the unit catalog and changed the 4 (changable) catalog fields for each unit that I found need to be changed(there may be others).
They are:
Acceleration, Deceleration, LateralAcceleration, and TurningRate.
Walk Animation Movement Speed also has to be increased manually in the unit actor but only if using the timescale trick, since this is evidently just the result of a general timescale bug and has nothing to do with gamespeed.
The gamespeed multipliers are 0.6, 0.8, 1.0, 1.2, and 1.4. So on slower gamespeed only 0.6 game time seconds pass for each real time second. If you want to go from one speed to another, just divide the first by the second to get the multiplier you should multiply by or divide by (depending on the circumstance). So to go from Faster to Slower you use a multiplier of 1.4/0.6=2.3333333.
Here is a partial list for some things that need to be changed for a typical unit if NOT using the timescale trick.
Some parameters might not need to be scaled because they start already at maximum values(ie acceleration for any ground unit starts at the maximum allowed: 1000)
Unit:
Acceleration/Deceleration/Lateral Acceleration
Movement Speed
Turning Rate/Stationary Turning Rate
Energy/Health/Shield regeneration rate and delays
Repair Time
Revive Time/Delay
Death Time
Unit Actor:
Normally nothing.
Unit Models(including all models associated with unit, ie death or weapon impact models):
We actually used this method for marine arena 2, the lag reduced a considerable amount, some people reported going from 0 - 1 fps up to 5 - 10.
Which is great, but the issue we are having is the animations are very stuttery, and it makes microing difficult for the people that weren't lagging previously.
It seems that, even in slower, its still trying to slow down everyone to match the other peoples fps issues, so this method may not be useful for large massing games like MA, but we are currently redoing it all without the global time scale, hopefully with sc2 patch 1.5.3, this stutter might be fixed, but if not, we may have to revert the changes back to faster mode.
Romexiom, I would recommend not slowing things all the way down to slower; it is just too extreme. Slower was presumably designed as the absolutely slowest speed Blizz felt offered an acceptable game experience. I found slower to be unacceptable for Heaven Besieged. I ended up using slow with compensating timescale and no one has complained of stutteriness(and a lot less people now complain of lag). Anyways, I suppose Faster was also presumably optimized to be the fastest speed Blizz found which still offered meaningful responsiveness/smoothness improvement. As such it is also a fairly extreme value. If you are going to go through a lot of work to rescale all the timings in your map by hand, I would recommend trying for normal gamespeed first, as it is unlikely to cause significant responsiveness/smoothness issues.
Also there is a trigger that locks the gamespeed midgame... I would guess that means it prevents B.net from allowing players to slow down the game? You might see if that helps some.
To me it was a given to always use normal speed, just because I want a second to be a second.
Unless you're making a melee-centric map though, you're pretty much throwing Blizzard's fine-tuned balance out the window anyway. So I don't understand the fervor behind getting the units' attacks to sync as closely as possible to melee style. What's the point?
EDIT: I guess it's a different story for already-existing maps that have established some semblance of balance.
Normal does have that nice attraction, but the default speed is faster, so most maps will just end up as that. Most map makers have probably thought game speed to be totally unimportant... that there was no reason to go through the effort of changing. I certainly thought that way until intractable lag issues prompted me to do some experimentation.
If you change the game speed. Everything should adjust with it....
If you notice when set to fastest .... everything is faster such as
movespeed
attackspeed
animation speed
trigger processing speed
more events will fire in a smaller amount of time because things are happening faster
keep in mind it just increases the games "clock" speed. Even though the speed increased the game can only handle so much happening in a short period of time.
Everything is based on the game speed.
When you change it everything should scale with it with out the need to adjust anything.
Blizzard has everything based on the normal speed. but if you change it everything should scale.
You seem to have misinterpreted the whole point of the discussion. We want to lower game speed because it can reduce CPU load due to less game frames happening per real second. However we do not want to change the rate that the game plays out. ie, We do not want units to move or attack any faster or slower. Thus we must compensate for all the timing changes that lowering the game speed will bring about.
I find it hard to believe that simply using a different gamespeed causes disconnects and desyncs.
My published map, Heaven Besieged, has long used a trigger to set game speed to slow and add a compensating timescale and has never had any desync or disconnect problems.
How did you implement the changed gamespeed?
Could you upload the map here so I can test this as well?
Using a lower game speed greatly improves CPU-limited frame rate. You can change the game speed without changing the rate the game happens by rescaling timings to compensate. There are a great many laggy custom maps on bnet set to the default faster speed which would cease to be so laggy if they just switched to slow or normal game speed and rescaled timings by 1.75 or 1.4, respectively.
If you are lazy, or just want to test it out, you can set global time scale to compensate for most data timings... I have attached a test map which demonstrates this, and has a nice routine to change the 4 unit catalog entries that I know also have to be scaled(turning rate, acceleration etc.)
Unfortunately time scale has several bugs: it doesn't play well with cliff jumpers, it seems to be applied twice to walk animations(sadly a read-only catalog field), and it results in buildings finishing construction with less than full initial health. Depending on your map, it may be best to actually go through and edit all the timings manually.
On the test map I have included, on Low Graphics(ie CPU-limited) I get a frame rate of 45 to 55 initially, until the game speed and time scale are changed at the 2 minute(REAL time) mark. At that point I get about 95 to 100 fps. This is with leaving the camera aimed at empty space, ie the default position. If I keep the camera focused on the action then I get about 15 fps initially, and then about 30. In either case, this resulted in very significant frame-rate improvement.
I believe this all works because it lowers the number of game frames(ie, each atomic moment of all the game entities) that need to be calculated each real time second. If a person's CPU can't keep up with calculating the required number of game frames per second, then they will cause everyone to have to wait for them to calculate each game frame.. resulting in the kind of brutal lag that just slows everything down.
Although the test map uses it, I do not recommend using the 'slower' speed if you can at all avoid it... I've found it can easily cause noticable issues with fast moving missiles being barely rendered, if at all. I think that using normal speed would be fine for most modestly laggy maps, or if lag is a particularly bad problem for your map then I would suggest using slow.
Of course none of this will fix lag caused by triggers... this is generally most helpful for lag caused by having large numbers of units simply pathing and fighting.
Anyways, I am unsure about all the fields that will still need to be changed and issues that can arise after rescaling game speed and time scale. There will be lots of other random things, like creep growth rate, and particle effects animating slower(can this be changed without remaking the particle effect textures to skip frames?). It'd be nice to make some kind of comprehensive list....
Cool good to know. This could certainly help a lot of maps.
If I was to do this to my map. (Marine Arena 2 US)
What is the list of items I would need to go through and adjust timings on?
What am I missing:
-unit spawn times
-trigger events and timings
-unit hp/energy regeneration
-unit move speed and acceleration
-weapon attack speed
-animations? (hopefully not)
Check my reply on mChat, Josin.
Sorry for double post.
So converting faster game speed to normal, would mean that I have to increase speed by a factor of 1.4? (or decrease, depending on the situation)
And with that, converting faster to slower, I would increase to 1.75?
Thanks.
This method is great, does allot for my map but one thing that bothers me is thatf the units gain 40% movement speed, like marine. 2.25+0.9. Its the global scale that make the unit faster, not sure how to solve that in the proper way.
I could sett all speeds to be "current speed * (1/1.4)" but this is not a very good way because when i hover the unit armor then it says something like 1.61+0.64 and that look just bad. And in aditon to tahtd oes the unit move 0.9 slower then in faster mode.
Is there some way to fix the global timing so it does not affect unit movement speed like its a buff?
I will have to try this.
Just a update on what needs to be updated while using the timescale trick.
Sherlia, if you are dead set on using the timescale method(rather than manually editing all timing numbers) you could perhaps simply apply a compensating movespeed debuff(apply a hidden behavior with a 1/1.4 snare) to all units and then scale their base movement up 1.4x via trigger or data editor? Of course this doesn't change that the units still have larger movespeed numbers than a player would expect given how fast they move across the screen(Sadly, I do not think there is a way to fix this other problem), but at least it should suppress it being reported as a buff.
As a warning, I could not get the global timescale method to work with preplaced cliff jumper units... they would launch themselves into space the moment they jumped a cliff. However it is easy enough to patch this by applying a local timescale to just cliff jumper units counteracting the global timescale, and then editing all the timing numbers manually. I would guess something similar can be done to ensure buildings that are built finish with full health. Still, even tho these bugs can be worked around it seems safer in the long run to me to avoid using timescale altogether given its bugginess. In particular, if when you start a map from scratch, you immediately build things around using normal gamespeed you will never have anything to worry about.
SupaCats, you suggest that animation speeds need to be adjusted when using the global timescale method. I do not think this is accurate except in the case of unit walk animation speeds (though maybe you have done more thorough testing). Also, interestingly enough you have to scale the walk animation speed in the OPPOSITE direction, ie slow them down... since it appears that walk animations end up receiving double the timescale scaling due to what I guess is a BlizzBug.
The MeatGrinderLagTest map I included in the first post included a nice (disabled) example trigger which set the gamespeed/global timescale and automatically went through the unit catalog and changed the 4 (changable) catalog fields for each unit that I found need to be changed(there may be others). They are: Acceleration, Deceleration, LateralAcceleration, and TurningRate.
Walk Animation Movement Speed also has to be increased manually in the unit actor but only if using the timescale trick, since this is evidently just the result of a general timescale bug and has nothing to do with gamespeed.
The gamespeed multipliers are 0.6, 0.8, 1.0, 1.2, and 1.4. So on slower gamespeed only 0.6 game time seconds pass for each real time second. If you want to go from one speed to another, just divide the first by the second to get the multiplier you should multiply by or divide by (depending on the circumstance). So to go from Faster to Slower you use a multiplier of 1.4/0.6=2.3333333.
JosinJJ, dealing with animations isn't so bad.
Here is a partial list for some things that need to be changed for a typical unit if NOT using the timescale trick. Some parameters might not need to be scaled because they start already at maximum values(ie acceleration for any ground unit starts at the maximum allowed: 1000)
Unit:
Unit Actor:
Unit Models(including all models associated with unit, ie death or weapon impact models):
Weapons:
Abilities:
Behaviors:
Persistent Effects:
Create Healer Effects:
Turrets:
We actually used this method for marine arena 2, the lag reduced a considerable amount, some people reported going from 0 - 1 fps up to 5 - 10.
Which is great, but the issue we are having is the animations are very stuttery, and it makes microing difficult for the people that weren't lagging previously.
It seems that, even in slower, its still trying to slow down everyone to match the other peoples fps issues, so this method may not be useful for large massing games like MA, but we are currently redoing it all without the global time scale, hopefully with sc2 patch 1.5.3, this stutter might be fixed, but if not, we may have to revert the changes back to faster mode.
Rome.
@romexiom: Go
Romexiom, I would recommend not slowing things all the way down to slower; it is just too extreme. Slower was presumably designed as the absolutely slowest speed Blizz felt offered an acceptable game experience. I found slower to be unacceptable for Heaven Besieged. I ended up using slow with compensating timescale and no one has complained of stutteriness(and a lot less people now complain of lag). Anyways, I suppose Faster was also presumably optimized to be the fastest speed Blizz found which still offered meaningful responsiveness/smoothness improvement. As such it is also a fairly extreme value. If you are going to go through a lot of work to rescale all the timings in your map by hand, I would recommend trying for normal gamespeed first, as it is unlikely to cause significant responsiveness/smoothness issues.
Also there is a trigger that locks the gamespeed midgame... I would guess that means it prevents B.net from allowing players to slow down the game? You might see if that helps some.
To me it was a given to always use normal speed, just because I want a second to be a second.
Unless you're making a melee-centric map though, you're pretty much throwing Blizzard's fine-tuned balance out the window anyway. So I don't understand the fervor behind getting the units' attacks to sync as closely as possible to melee style. What's the point?
EDIT: I guess it's a different story for already-existing maps that have established some semblance of balance.
@TheZizz: Go
Normal does have that nice attraction, but the default speed is faster, so most maps will just end up as that. Most map makers have probably thought game speed to be totally unimportant... that there was no reason to go through the effort of changing. I certainly thought that way until intractable lag issues prompted me to do some experimentation.
@intanjir: Go
If you change the game speed. Everything should adjust with it....
If you notice when set to fastest .... everything is faster such as
keep in mind it just increases the games "clock" speed. Even though the speed increased the game can only handle so much happening in a short period of time.
Everything is based on the game speed.
When you change it everything should scale with it with out the need to adjust anything.
Blizzard has everything based on the normal speed. but if you change it everything should scale.
@SouLCarveRR: Go
You seem to have misinterpreted the whole point of the discussion. We want to lower game speed because it can reduce CPU load due to less game frames happening per real second. However we do not want to change the rate that the game plays out. ie, We do not want units to move or attack any faster or slower. Thus we must compensate for all the timing changes that lowering the game speed will bring about.
@intanjir: Go
i personnaly did some test with gamespeed, my result was bad on BNET.
Changing the gamespeed do a lot of disconnect and error synh with players
use default!
egod
@intanjir: Go
i personnaly did some test with gamespeed, my result was bad on BNET.
Changing the gamespeed do a lot of disconnect and error synh with players
use default!
egod
@egodbout: Go
I find it hard to believe that simply using a different gamespeed causes disconnects and desyncs. My published map, Heaven Besieged, has long used a trigger to set game speed to slow and add a compensating timescale and has never had any desync or disconnect problems.
How did you implement the changed gamespeed? Could you upload the map here so I can test this as well?
@egodbout: Go
U done this wrong, MA2 currently has the speed change inplace... we get no desyncs.
Rome.