IeptBarakatThe most difficult name to speak ingame.Join Date: 2009-07-10Member: 68107Members, Constellation, NS2 Playtester, Squad Five Blue, NS2 Map Tester, Reinforced - Diamond, Reinforced - Shadow
<!--QuoteBegin-twitter+--><div class='quotetop'>QUOTE (twitter)</div><div class='quotemain'><!--QuoteEBegin-->Max and Simon made some big sound optimizations yesterday resulting in something like 400MB less memory usage!<!--QuoteEnd--></div><!--QuoteEEnd-->
Sweet. With this and the occlusion rework, it sounds like I can set the game back to high again!
IeptBarakatThe most difficult name to speak ingame.Join Date: 2009-07-10Member: 68107Members, Constellation, NS2 Playtester, Squad Five Blue, NS2 Map Tester, Reinforced - Diamond, Reinforced - Shadow
edited October 2011
<!--quoteo(post=1882383:date=Oct 27 2011, 05:18 PM:name=Heroman117)--><div class='quotetop'>QUOTE (Heroman117 @ Oct 27 2011, 05:18 PM) <a href="index.php?act=findpost&pid=1882383"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Maybe i'm not tech savvy but doesn't that just mean that the game now uses less memory on the hard drive? not actually make the game run smoother?
EDIT: even if its just less memory, smaller patches is always a plus<!--QuoteEnd--></div><!--QuoteEEnd-->
In that case wouldn't it use a smaller amount of memory as well? As the sound files sent to the ram wouldn't be as large.
<!--quoteo(post=1882383:date=Oct 27 2011, 10:18 PM:name=Heroman117)--><div class='quotetop'>QUOTE (Heroman117 @ Oct 27 2011, 10:18 PM) <a href="index.php?act=findpost&pid=1882383"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Maybe i'm not tech savvy but doesn't that just mean that the game now uses less memory on the hard drive? not actually make the game run smoother?
EDIT: even if its just less memory, smaller patches is always a plus<!--QuoteEnd--></div><!--QuoteEEnd-->
I think generally when programmers talk about using less memory, they mean the actual RAM. I'd be surprised if they did actually mean hard drive space, because tbh while it's good to reduce the game size, it's not really worthy of it's own announcement, especially seeing as everyone who has the beta would have already downloaded the files anyway.
I belive they mean RAM because the tweet says "less memory usage" if they meant the HDD they would have said "less storage usage" anyway good job guys what a huge diffrence that is.
update: I just checked and the game is using 1300MB of ram, I was in a 6 player server so this is indeed great news, now here is hopeing for more good things to come with the new Occlusion culling system.
The 400MB is referring to RAM (although the HD space is down considerably too). There shouldn't be any quality difference in the audio. I did some other memory optimization on top of that, so it will hopefully be down even more for build 188.
cant complain about optimisation, but don't everyone have atleast 4gig of RAM these days anyway, to which we dont use all of that for ns2 + windows anyway.
Wow that's a huge reduction - great going guys. Is there any fix planned for flickering shadows in CFX yet? It's a shame having to turn shadows off as you lose some of the atmosphere.
Constantly writing and reading from memory takes time also, so ram usage reduction can be good not only for those that have low amount of it. I think someone said once that ram overclocking was giving nice performance boost.
fsfodukJoin Date: 2004-04-09Member: 27810Members, NS2 Developer, Constellation, NS2 Playtester, Squad Five Blue, Squad Five Silver, Squad Five Gold, Subnautica Playtester, NS2 Community Developer, Pistachionauts
<!--quoteo(post=1882451:date=Oct 28 2011, 01:07 PM:name=Cygone)--><div class='quotetop'>QUOTE (Cygone @ Oct 28 2011, 01:07 PM) <a href="index.php?act=findpost&pid=1882451"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->cant complain about optimisation, but don't everyone have atleast 4gig of RAM these days anyway, to which we dont use all of that for ns2 + windows anyway.<!--QuoteEnd--></div><!--QuoteEEnd-->
A 32 bit process on a 32 bit windows can only use a maximum of 2GB of memory because the other 2GB virtual address space is reserved for the kernel. Loading up ns2_tram in a listen server makes ns2 easily hit the 2GB wall which cause it fail to creates some textures and will eventfully crash. This is still a problem on a 64 bit windows with a 32 process because for silly compatibility reasons the user virtual address space is still capped at 2GB instead of 4GB unless the exe of the process has the Large Address Aware flag set, so many games are built with this flag not set and crash because of it, ns2 happens tobe one of them maybe max will remedy this for the next build.
I'm particularly looking forward to RAM optimisations as it's the main bottleneck on my PC.
<!--quoteo(post=1882473:date=Oct 28 2011, 03:15 PM:name=fsfod)--><div class='quotetop'>QUOTE (fsfod @ Oct 28 2011, 03:15 PM) <a href="index.php?act=findpost&pid=1882473"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->A 32 bit process on a 32 bit windows can only use a maximum of 2GB of memory because the other 2GB virtual address space is reserved for the kernel. Loading up ns2_tram in a listen server makes ns2 easily hit the 2GB wall which cause it fail to creates some textures and will eventfully crash. This is still a problem on a 64 bit windows with a 32 process because for silly compatibility reasons the user virtual address space is still capped at 2GB instead of 4GB unless the exe of the process has the Large Address Aware flag set, so many games are built with this flag not set and crash because of it, ns2 happens tobe one of them maybe max will remedy this for the next build.<!--QuoteEnd--></div><!--QuoteEEnd-->
Although if you use a 64 bit OS it will shove all your non-essential crap into the other 2gb of ram while the game is using the first 2gb, so you do get a benefit out of it.
That said, I do run most games fine with 2gb ram total, although loading new areas can cause some stuttering as can extremely high texture resolutions. Oh and it can't multitask worth a damn but I don't generally try to do that anyway.
<!--quoteo(post=1882473:date=Oct 28 2011, 07:15 AM:name=fsfod)--><div class='quotetop'>QUOTE (fsfod @ Oct 28 2011, 07:15 AM) <a href="index.php?act=findpost&pid=1882473"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->A 32 bit process on a 32 bit windows can only use a maximum of 2GB of memory because the other 2GB virtual address space is reserved for the kernel. Loading up ns2_tram in a listen server makes ns2 easily hit the 2GB wall which cause it fail to creates some textures and will eventfully crash. This is still a problem on a 64 bit windows with a 32 process because for silly compatibility reasons the user virtual address space is still capped at 2GB instead of 4GB unless the exe of the process has the Large Address Aware flag set, so many games are built with this flag not set and crash because of it, ns2 happens tobe one of them maybe max will remedy this for the next build.<!--QuoteEnd--></div><!--QuoteEEnd--> This is exactly correct. We found that when we loaded our bigger maps (like tram or an unannounced map which is even bigger), the game would run out of addressable memory. Our first step was to enable the large address aware flag which solved the problem for 64-bit machines, but not for 32-bit ones. We knew we'd have to optimize this at some point, but have been delaying it since we've had other more important things to deal with. Fortunately as you can see, there's plenty of easy optimization and we've solved the out of memory problem. Using less memory is a generally good thing for performance, so we'll be doing more memory usage optimization.
<!--quoteo(post=1882473:date=Oct 28 2011, 03:15 PM:name=fsfod)--><div class='quotetop'>QUOTE (fsfod @ Oct 28 2011, 03:15 PM) <a href="index.php?act=findpost&pid=1882473"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->A 32 bit process on a 32 bit windows can only use a maximum of 2GB of memory because the other 2GB virtual address space is reserved for the kernel. Loading up ns2_tram in a listen server makes ns2 easily hit the 2GB wall which cause it fail to creates some textures and will eventfully crash. This is still a problem on a 64 bit windows with a 32 process because for silly compatibility reasons the user virtual address space is still capped at 2GB instead of 4GB unless the exe of the process has the Large Address Aware flag set, so many games are built with this flag not set and crash because of it, ns2 happens tobe one of them maybe max will remedy this for the next build.<!--QuoteEnd--></div><!--QuoteEEnd-->
Wow good to know, I thought it was 3.2GB but fair enuff.
Is this what was causing the console to be flooded with 'out of memory errors', fps to drop and game to crash?
<!--quoteo(post=1882499:date=Oct 28 2011, 10:47 AM:name=Cygone)--><div class='quotetop'>QUOTE (Cygone @ Oct 28 2011, 10:47 AM) <a href="index.php?act=findpost&pid=1882499"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Wow good to know, I thought it was 3.2GB but fair enuff.
Is this what was causing the console to be flooded with 'out of memory errors', fps to drop and game to crash?<!--QuoteEnd--></div><!--QuoteEEnd--> Yes.
<!--quoteo(post=1882511:date=Oct 28 2011, 07:16 PM:name=IeptBarakat)--><div class='quotetop'>QUOTE (IeptBarakat @ Oct 28 2011, 07:16 PM) <a href="index.php?act=findpost&pid=1882511"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Only problem is the current map layouts could have both teams starting right next to each other.<!--QuoteEnd--></div><!--QuoteEEnd-->
I think that this may not be as much of a problem as it could be.
Imagine the following scenario. Aliens get random start at Heliport, Marines have their usual start. Teams have to divide into 2 parts, one fighting a desperate turf war/attack+defend between the two start areas, the others trying to a) sneakily gather the resources to make a decisive push b) outflank the opposing team across the rest of the map. It's a whole new dynamic.
IeptBarakatThe most difficult name to speak ingame.Join Date: 2009-07-10Member: 68107Members, Constellation, NS2 Playtester, Squad Five Blue, NS2 Map Tester, Reinforced - Diamond, Reinforced - Shadow
<!--quoteo(post=1882613:date=Oct 29 2011, 12:13 PM:name=Tig)--><div class='quotetop'>QUOTE (Tig @ Oct 29 2011, 12:13 PM) <a href="index.php?act=findpost&pid=1882613"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->random start locations would really mess up my map.<!--QuoteEnd--></div><!--QuoteEEnd-->
Well that's the risk of developing maps for an unfinished game. My map I was making in the early days was ruined due to minigun sentries and powernodes.
<!--quoteo(post=1882614:date=Oct 29 2011, 11:41 AM:name=IeptBarakat)--><div class='quotetop'>QUOTE (IeptBarakat @ Oct 29 2011, 11:41 AM) <a href="index.php?act=findpost&pid=1882614"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Well that's the risk of developing maps for an unfinished game. My map I was making in the early days was ruined due to minigun sentries and powernodes.<!--QuoteEnd--></div><!--QuoteEEnd-->
mapping guidelines specified viable map layouts that would now be broken by random start locations. i'm not against it, i just want to turn it off for my map. let that be a server option.
Variation is good, but it's probably going to be a total mess to balance the game. How many maps pulled off 3 balanced hives in NS1? Now pull that off with marine start being randomized also.
I'd support a variation on the NS1 random-start quality... some maps have the Kharaa on "offense" meaning that they get a random start location as they infiltrate the area, other maps have the Marines on "offense," so while the Kharaa have a defined start point the Marines are breaching into a random location to try and retake the map. So, only one side has a random start location, but it's not always the aliens :)
IeptBarakatThe most difficult name to speak ingame.Join Date: 2009-07-10Member: 68107Members, Constellation, NS2 Playtester, Squad Five Blue, NS2 Map Tester, Reinforced - Diamond, Reinforced - Shadow
I always imagined it as the Marines are always on the offense with the same entry point. While the aliens could be infesting various parts of the level.
Comments
Sweet.
With this and the occlusion rework, it sounds like I can set the game back to high again!
EDIT: even if its just less memory, smaller patches is always a plus
EDIT: even if its just less memory, smaller patches is always a plus<!--QuoteEnd--></div><!--QuoteEEnd-->
In that case wouldn't it use a smaller amount of memory as well? As the sound files sent to the ram wouldn't be as large.
Ah well.
EDIT: even if its just less memory, smaller patches is always a plus<!--QuoteEnd--></div><!--QuoteEEnd-->
I think generally when programmers talk about using less memory, they mean the actual RAM. I'd be surprised if they did actually mean hard drive space, because tbh while it's good to reduce the game size, it's not really worthy of it's own announcement, especially seeing as everyone who has the beta would have already downloaded the files anyway.
update:
I just checked and the game is using 1300MB of ram, I was in a 6 player server so this is indeed great news, now here is hopeing for more good things to come with the new Occlusion culling system.
edit: I hope this won't bring in a lesser audio quality D:
Anyway, wouldn't this reduce loading times?
A 32 bit process on a 32 bit windows can only use a maximum of 2GB of memory because the other 2GB virtual address space is reserved for the kernel.
Loading up ns2_tram in a listen server makes ns2 easily hit the 2GB wall which cause it fail to creates some textures and will eventfully crash.
This is still a problem on a 64 bit windows with a 32 process because for silly compatibility reasons the user virtual address space is still capped at 2GB instead of 4GB unless the exe of the process has the Large Address Aware flag set, so many games are built with this flag not set and crash because of it, ns2 happens tobe one of them maybe max will remedy this for the next build.
<!--quoteo(post=1882473:date=Oct 28 2011, 03:15 PM:name=fsfod)--><div class='quotetop'>QUOTE (fsfod @ Oct 28 2011, 03:15 PM) <a href="index.php?act=findpost&pid=1882473"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->A 32 bit process on a 32 bit windows can only use a maximum of 2GB of memory because the other 2GB virtual address space is reserved for the kernel.
Loading up ns2_tram in a listen server makes ns2 easily hit the 2GB wall which cause it fail to creates some textures and will eventfully crash.
This is still a problem on a 64 bit windows with a 32 process because for silly compatibility reasons the user virtual address space is still capped at 2GB instead of 4GB unless the exe of the process has the Large Address Aware flag set, so many games are built with this flag not set and crash because of it, ns2 happens tobe one of them maybe max will remedy this for the next build.<!--QuoteEnd--></div><!--QuoteEEnd-->
Although if you use a 64 bit OS it will shove all your non-essential crap into the other 2gb of ram while the game is using the first 2gb, so you do get a benefit out of it.
That said, I do run most games fine with 2gb ram total, although loading new areas can cause some stuttering as can extremely high texture resolutions. Oh and it can't multitask worth a damn but I don't generally try to do that anyway.
Loading up ns2_tram in a listen server makes ns2 easily hit the 2GB wall which cause it fail to creates some textures and will eventfully crash.
This is still a problem on a 64 bit windows with a 32 process because for silly compatibility reasons the user virtual address space is still capped at 2GB instead of 4GB unless the exe of the process has the Large Address Aware flag set, so many games are built with this flag not set and crash because of it, ns2 happens tobe one of them maybe max will remedy this for the next build.<!--QuoteEnd--></div><!--QuoteEEnd-->
This is exactly correct. We found that when we loaded our bigger maps (like tram or an unannounced map which is even bigger), the game would run out of addressable memory. Our first step was to enable the large address aware flag which solved the problem for 64-bit machines, but not for 32-bit ones. We knew we'd have to optimize this at some point, but have been delaying it since we've had other more important things to deal with. Fortunately as you can see, there's plenty of easy optimization and we've solved the out of memory problem. Using less memory is a generally good thing for performance, so we'll be doing more memory usage optimization.
Loading up ns2_tram in a listen server makes ns2 easily hit the 2GB wall which cause it fail to creates some textures and will eventfully crash.
This is still a problem on a 64 bit windows with a 32 process because for silly compatibility reasons the user virtual address space is still capped at 2GB instead of 4GB unless the exe of the process has the Large Address Aware flag set, so many games are built with this flag not set and crash because of it, ns2 happens tobe one of them maybe max will remedy this for the next build.<!--QuoteEnd--></div><!--QuoteEEnd-->
Wow good to know, I thought it was 3.2GB but fair enuff.
Is this what was causing the console to be flooded with 'out of memory errors', fps to drop and game to crash?
Is this what was causing the console to be flooded with 'out of memory errors', fps to drop and game to crash?<!--QuoteEnd--></div><!--QuoteEEnd-->
Yes.
Sweetness, would be lovely if mappers where up for the challenge.
Only problem is the current map layouts could have both teams starting right next to each other.
I think that this may not be as much of a problem as it could be.
Imagine the following scenario.
Aliens get random start at Heliport, Marines have their usual start.
Teams have to divide into 2 parts, one fighting a desperate turf war/attack+defend between the two start areas, the others trying to
a) sneakily gather the resources to make a decisive push
b) outflank the opposing team across the rest of the map.
It's a whole new dynamic.
Well that's the risk of developing maps for an unfinished game. My map I was making in the early days was ruined due to minigun sentries and powernodes.
mapping guidelines specified viable map layouts that would now be broken by random start locations. i'm not against it, i just want to turn it off for my map. let that be a server option.