Problem with NS2 is that keeps using more memory without freeing memory which is why it eventually crashes.
Maybe it does have memleaks. With the current version it hasn't crashed on my machine due to memory problems. Peak virtual size didn't increase after 2 rounds including a map change for example ... so I'm not sure, but yeah maybe there are some leaks.
@omega_k2 maybe this is a silly question, but what's the difference between unused and free [ ]...
I'm not sure if Omega_K2 means the same thing, but it's usually called a memory leak. When you allocate a block of memory you get a pointer to it. If you forget to free that block of memory but throw away the pointer, the block is basically lost. The application cannot use it since it has no pointer that points to the block, and the operating system (OS) thinks the process is still using that block so cannot free it.
Only when you terminate the process, the OS can finally reclaim all of the "lost" (leaked) memory.
Originally we thought fragmentation was the issue since our code only allocates about 1 GB of memory, [...]
Afaik, fragmentation is only an issue if the number of allocated bytes approaches the virtual address space (~3 GB with the large memory switch on on x86). Ideally, virtual address space is a *lot* larger than the allocated memory. That's the case for 64 bit processes, as long as we don't have applications that take up several terabytes of memory.
So it may indeed be some leaks or other bugs that cause spikes of memory allocation. I've noticed that when ALT+TAB switching to the desktop directly after loading the map, when the textures are still blurry, the memory usage increases rapidly, but drops again after switching back to ns2.
Someone thought because Microsoft fixed the problem that caused all addresses on VRAM to be written to RAM as well. Now it only writes to the VRAM giving the impression that you can use more ram. It increased performance in some areas. In reality if you shift more load to the VRAM more RAM will become available, but it will not usable.
Virtual address space allows the application to deal with virtual memory, so it has an address space that is independent of other applications, the OS and even physical memory.
The OS will map allocated blocks of virtual memory to some real location in the physical RAM or maybe even in the pagefile on your HDD.
What could you do with NS2 if it would be 64bit? Better Textures and more props in the maps or even things like dynamic dust(dont know how it actually is called) and Pixel Accurate Displacement Mapping?
I'm not using task manager. I didn't pull those numbers out of thin air. Take a look at Process Explorer or Process Hacker.
NS2 Docking windowed with 1080p lowest everything, alone. I'm getting 1.69GB RAM growing slowly and .4 GB of VRAM. I imagine a full game would inflate these numbers. As would increasing graphics quality above minimum. I'll get back and edit this...
Virtual address space allows the application to deal with virtual memory, so it has an address space that is independent of other applications, the OS and even physical memory.
The OS will map allocated blocks of virtual memory to some real location in the physical RAM or maybe even in the pagefile on your HDD.
Your worries are unfounded! 64Bit is the same thing but with no limit and much better performance, no driver problems since Windows 7. But NS2, you might be right about. I would have to decompile and reverse engineer it to find out. I doubt devs will be open about it, especially if it looks like spaghetti. /0/
Now you're reffering to more or additional caching, in which's case 64 bit might make sense, so they can cache more. But you'd still have to do on-demand loading, unless you have shitloads of memory available, it's good to have on demand loading, or why would you need descent textures in memory if you haven't played descent for 10 rounds? Unless they'd change the requiremens of NS2 to 64 bit os, 16GB of ram and a gfx card with 3GB VRAM, a bold move to finally kill NS2 userbase (except the hardcore gamers that have high end systems already).
They still need to do on-demand loading, especially for lower end systems with less memory.
There's just simply no future for 32 man. You have to go 64 some time or face restrictions. 64 would future proof it, fix crashing for now and open up countless possibilities for performance gains. Who says we can't have both? The initial write would take time. But after it's done, it wouldn't eat any more dev time if it's done right as far as I know. Game would start, see if your 32 or 64 and optimize from there. But I could be wrong.
How to Get Cheap PC Parts:
http://www.newegg.ca/Desktop-Memory/SubCategory/ID-147 (or.com wtvr) Now that's pretty cheap. Now find what you want. Go to Google, enter its name + shopbot to the end, find the cheapest in the world. Take the link and price to NCIX and price match it. Bam 16GB DDR3 for around $80, and a slightly older medium end card for cheap.
I could build a gaming PC for $300-$400. It's about building it over time and watching prices. Personally, I have 24GB DDR3 and a 7970 3GB(I side-graded a 5970 and made money selling to bit miners). RAM... is dirt cheap, and you can pick up any old card now with 2GB for under $80. It has made back its cost in steam savings 10x. All I'm asking is to spend as much as a new console. Most people can't complain about that.
Off Topic:
Is everyone working at Mc.Donalds these days? We have wage laws in Canada, so I really don't know what the problem is elsewhere.
Your worries are unfounded! 64Bit is the same thing but with no limit and much better performance, no driver problems since Windows 7. But NS2, you might be right about. I would have to decompile and reverse engineer it to find out. I doubt devs will be open about it, especially if it looks like spaghetti. /0/
Now you're reffering to more or additional caching, in which's case 64 bit might make sense, so they can cache more. But you'd still have to do on-demand loading, unless you have shitloads of memory available, it's good to have on demand loading, or why would you need descent textures in memory if you haven't played descent for 10 rounds? Unless they'd change the requiremens of NS2 to 64 bit os, 16GB of ram and a gfx card with 3GB VRAM, a bold move to finally kill NS2 userbase (except the hardcore gamers that have high end systems already).
They still need to do on-demand loading, especially for lower end systems with less memory.
There's just simply no future for 32 man. You have to go 64 some time or face restrictions. 64 would future proof it, fix crashing for now and open up countless possibilities for performance gains. Who says we can't have both? The initial write would take time. But after it's done, it wouldn't eat any more dev time if it's done right as far as I know. Game would start, see if your 32 or 64 and optimize from there. But I could be wrong.
How to Get Cheap PC Parts:
http://www.newegg.ca/Desktop-Memory/SubCategory/ID-147 (or.com wtvr) Now that's pretty cheap. Now find what you want. Go to Google, enter its name + shopbot to the end, find the cheapest in the world. Take the link and price to NCIX and price match it. Bam 16GB DDR3 for around $80, and a slightly older medium end card for cheap.
I could build a gaming PC for $300-$400. It's about building it over time and watching prices. Personally, I have 24GB DDR3 and a 7970 3GB(I side-graded a 5970 and made money selling to bit miners). RAM... is dirt cheap, and you can pick up any old card now with 2GB for under $80. It has made back its cost in steam savings 10x. All I'm asking is to spend as much as a new console. Most people can't complain about that.
Off Topic:
Is everyone working at Mc.Donalds these days? We have wage laws in Canada, so I really don't know what the problem is elsewhere.
With on-demand loading I mean loading, for example, detailed textures to replace blurry ones you already see.
I wasn't talking about additional caching. You would only load the stuff you need for the current map during the loading screen, so that when you are in the actual game everything you see is in memory. On map change it of course would make a lot of sense to throw away all the unneeded stuff from the previous map to free memory for the next map.
Btw: deleting the ns2 cache folder sped up loading of maps, textures etc. on my machine significantly!
What could you do with NS2 if it would be 64bit? Better Textures and more props in the maps or even things like dynamic dust(dont know how it actually is called) and Pixel Accurate Displacement Mapping?
I'm quite sure you can have whatever resolution on the textures whether it's a 64-bit executable or not.
@Discowitz
Well, if that shiny stuff takes up a lot of the address space which would be beyond the 4GB mark than probably a 64bit system does matter!
Texture resolution is not held back by 32 bit, though. You could have super-high resolution on textures and just let 32 bit users use a lower quality setting since it's only loading the resolution into memory that it actually needs.
The thing is more that a higher texture resolution also means a larger file size, so the game would take up more disk space and would also increase the download size. Increasing the resolution by factor 2 also increases the file size by factor 2. (The game is using DXT1-compressed textures)
All textures in NS2 currently make up ~5 GB. 8 byte per 16 pixels with 3-4 individual textures per material. There is a point where you don't to force players to download another 5 GB just to get to the next higher texture resolution. Aside from probably taking up slightly more GPU time to draw the larger texture. And loading times increasing even more, since there is more data to read from the files.
Comments
I guess that's right. Would still be nice if it loaded all the stuff upfront on a machine that can handle it.
I'm not sure if Omega_K2 means the same thing, but it's usually called a memory leak. When you allocate a block of memory you get a pointer to it. If you forget to free that block of memory but throw away the pointer, the block is basically lost. The application cannot use it since it has no pointer that points to the block, and the operating system (OS) thinks the process is still using that block so cannot free it.
Only when you terminate the process, the OS can finally reclaim all of the "lost" (leaked) memory.
Afaik, fragmentation is only an issue if the number of allocated bytes approaches the virtual address space (~3 GB with the large memory switch on on x86). Ideally, virtual address space is a *lot* larger than the allocated memory. That's the case for 64 bit processes, as long as we don't have applications that take up several terabytes of memory.
So it may indeed be some leaks or other bugs that cause spikes of memory allocation. I've noticed that when ALT+TAB switching to the desktop directly after loading the map, when the textures are still blurry, the memory usage increases rapidly, but drops again after switching back to ns2.
I'm not using task manager. I didn't pull those numbers out of thin air. Take a look at Process Explorer or Process Hacker.
Virtual address space allows the application to deal with virtual memory, so it has an address space that is independent of other applications, the OS and even physical memory.
The OS will map allocated blocks of virtual memory to some real location in the physical RAM or maybe even in the pagefile on your HDD.
It all makes sense now. :P
Your worries are unfounded! 64Bit is the same thing but with no limit and much better performance, no driver problems since Windows 7. But NS2, you might be right about. I would have to decompile and reverse engineer it to find out. I doubt devs will be open about it, especially if it looks like spaghetti. /0/
There's just simply no future for 32 man. You have to go 64 some time or face restrictions. 64 would future proof it, fix crashing for now and open up countless possibilities for performance gains. Who says we can't have both? The initial write would take time. But after it's done, it wouldn't eat any more dev time if it's done right as far as I know. Game would start, see if your 32 or 64 and optimize from there. But I could be wrong.
How to Get Cheap PC Parts:
http://www.newegg.ca/Desktop-Memory/SubCategory/ID-147 (or.com wtvr) Now that's pretty cheap. Now find what you want. Go to Google, enter its name + shopbot to the end, find the cheapest in the world. Take the link and price to NCIX and price match it. Bam 16GB DDR3 for around $80, and a slightly older medium end card for cheap.
I could build a gaming PC for $300-$400. It's about building it over time and watching prices. Personally, I have 24GB DDR3 and a 7970 3GB(I side-graded a 5970 and made money selling to bit miners). RAM... is dirt cheap, and you can pick up any old card now with 2GB for under $80. It has made back its cost in steam savings 10x. All I'm asking is to spend as much as a new console. Most people can't complain about that.
Off Topic:
Is everyone working at Mc.Donalds these days? We have wage laws in Canada, so I really don't know what the problem is elsewhere.
Your worries are unfounded! 64Bit is the same thing but with no limit and much better performance, no driver problems since Windows 7. But NS2, you might be right about. I would have to decompile and reverse engineer it to find out. I doubt devs will be open about it, especially if it looks like spaghetti. /0/
There's just simply no future for 32 man. You have to go 64 some time or face restrictions. 64 would future proof it, fix crashing for now and open up countless possibilities for performance gains. Who says we can't have both? The initial write would take time. But after it's done, it wouldn't eat any more dev time if it's done right as far as I know. Game would start, see if your 32 or 64 and optimize from there. But I could be wrong.
How to Get Cheap PC Parts:
http://www.newegg.ca/Desktop-Memory/SubCategory/ID-147 (or.com wtvr) Now that's pretty cheap. Now find what you want. Go to Google, enter its name + shopbot to the end, find the cheapest in the world. Take the link and price to NCIX and price match it. Bam 16GB DDR3 for around $80, and a slightly older medium end card for cheap.
I could build a gaming PC for $300-$400. It's about building it over time and watching prices. Personally, I have 24GB DDR3 and a 7970 3GB(I side-graded a 5970 and made money selling to bit miners). RAM... is dirt cheap, and you can pick up any old card now with 2GB for under $80. It has made back its cost in steam savings 10x. All I'm asking is to spend as much as a new console. Most people can't complain about that.
Off Topic:
Is everyone working at Mc.Donalds these days? We have wage laws in Canada, so I really don't know what the problem is elsewhere.
I wasn't talking about additional caching. You would only load the stuff you need for the current map during the loading screen, so that when you are in the actual game everything you see is in memory. On map change it of course would make a lot of sense to throw away all the unneeded stuff from the previous map to free memory for the next map.
Btw: deleting the ns2 cache folder sped up loading of maps, textures etc. on my machine significantly!
I'm quite sure you can have whatever resolution on the textures whether it's a 64-bit executable or not.
Well, if that shiny stuff takes up a lot of the address space which would be beyond the 4GB mark than probably a 64bit system does matter!
Texture resolution is not held back by 32 bit, though. You could have super-high resolution on textures and just let 32 bit users use a lower quality setting since it's only loading the resolution into memory that it actually needs.
The thing is more that a higher texture resolution also means a larger file size, so the game would take up more disk space and would also increase the download size. Increasing the resolution by factor 2 also increases the file size by factor 2. (The game is using DXT1-compressed textures)
All textures in NS2 currently make up ~5 GB. 8 byte per 16 pixels with 3-4 individual textures per material. There is a point where you don't to force players to download another 5 GB just to get to the next higher texture resolution. Aside from probably taking up slightly more GPU time to draw the larger texture. And loading times increasing even more, since there is more data to read from the files.
The fix they posted seems to be working fine with me anyway. Haven't had a crash since I did it