@soul_rider, is that what happened to CTF? It was a very interesting ns2 mod. I thought it was very worth playing, even though I could never get a game of it.
I herd the biggest reason they stopped supporting 32 bit was they removed (or set a higher limit) the entity limit. You could 100% run combat on 32 bit, but you might crash do to maxed out memory. So (and this is an assumption) they wanted to leave room for expansion beyond the limits of 32 bit.
Read my previous post. Combat is also only a 32bit application. IIRC FLG dropped 32 bit back then to avoid having to support and deal with player who have to less memory to play (NS2 had a lot issues with memory leaks back then (got fixed around build 265/266).
In case someone wants prove: just have a look at the details of this virustotal report
I think you'll find that there are more issues than that.
For example, when developing CTF with the intention of being a new game mode for Combat, after adding 3 new kTechData types, we hit the limit of the max number of datatypes in 32bit, so as this is a 64bit exectuable, datatypes was changed to 64bit, to hold all the relevant data.
Although CTF is no longer part of the game, with the additional items added in the last few updates, I am fairly sure they are again over this 32bit limit, which means they would have to cut tech from the game to make it 32-bit compatible.
---Edit---
My point being with all the items in techtypes in NS2 and Combat, in a single group, combat would need a lot of it's custom items cut.
Can you explain this in a little more detail to someone who doesn't understand coding at that level? It sounds to me like you are saying that NS2 is the most complex game it can possibly be in 32bit and adding anything more would make it incompatible, but there's no way that could be true.
They added more skins to the game and 32bit-user started to crash regularly. I can believe it. But that might had been a problem with sparks and not 32bit alone.
They added more skins to the game and 32bit-user started to crash regularly. I can believe it. But that might had been a problem with sparks and not 32bit alone.
Models, not skins, are what increase the memory usage.
They added more skins to the game and 32bit-user started to crash regularly. I can believe it. But that might had been a problem with sparks and not 32bit alone.
Models, not skins, are what increase the memory usage.
Actually, skins should increase the memory usage just as much. 90% of a model is just the texture data. Models themselves are relatively light.
EDIT: Maybe not... not sure about this exactly... animations take up a ton of memory... but similar models should share animation data... (eg shadow skulk, kodiak skulk both inherit animation from skulk).
I wish Combat would become an official part of NS2. Sometimes I just want to slug it out with others without waiting for half an hour in the lobby and then losing just because half the people were sleeping. Besides, Combat is a good training of aiming skills as well as certain tactics.
I've bought NS2:Combat for that purpose and the game is dead. 3 servers available with no people playing even at otherwise peak hours. Sos tupid and I really liked the game and it was huge fun for the first few days after release.
They added more skins to the game and 32bit-user started to crash regularly. I can believe it. But that might had been a problem with sparks and not 32bit alone.
Models, not skins, are what increase the memory usage.
Actually, skins should increase the memory usage just as much. 90% of a model is just the texture data. Models themselves are relatively light.
EDIT: Maybe not... not sure about this exactly... animations take up a ton of memory... but similar models should share animation data... (eg shadow skulk, kodiak skulk both inherit animation from skulk).
It depends on how things are done and what method was selected.
1 / Model + Animation (bone, ragdoll etc.). Lowest consumption but makes the program (or ragdoll stuff) work more. Hardware is pretty efficient at it now.
1B/ You can save CPU/GPU cycles by rendering in memory every animation frame before using it. Pre-calculating takes more memory and rendering time after loading. Useful if you want to draw an army running on a field and as the camera is IN the action, the model have to be detailed (lot of vertex). Animation stuff would probably slow down everything in this case.
2 / model + vertex animated (each animation frame is already rendered). So it's N vertex * N frame. Not really something any coder should do. But in the mean time, no need for 3D animation function/library stuff in the code. You just select the right frame and use the vertex.
Animation data can be tricky too. having only key frame saves storage. It require the program to rebuild the entire animation (ex: with IK data).
Same goes for textures. More pixels means more work... simple as that.
You can have any system you want actually. Then for each method there are downsides.
They added more skins to the game and 32bit-user started to crash regularly. I can believe it. But that might had been a problem with sparks and not 32bit alone.
Models, not skins, are what increase the memory usage.
Actually, skins should increase the memory usage just as much. 90% of a model is just the texture data. Models themselves are relatively light.
EDIT: Maybe not... not sure about this exactly... animations take up a ton of memory... but similar models should share animation data... (eg shadow skulk, kodiak skulk both inherit animation from skulk).
It depends on how things are done and what method was selected.
1 / Model + Animation (bone, ragdoll etc.). Lowest consumption but makes the program (or ragdoll stuff) work more. Hardware is pretty efficient at it now.
1B/ You can save CPU/GPU cycles by rendering in memory every animation frame before using it. Pre-calculating takes more memory and rendering time after loading. Useful if you want to draw an army running on a field and as the camera is IN the action, the model have to be detailed (lot of vertex). Animation stuff would probably slow down everything in this case.
2 / model + vertex animated (each animation frame is already rendered). So it's N vertex * N frame. Not really something any coder should do. But in the mean time, no need for 3D animation function/library stuff in the code. You just select the right frame and use the vertex.
Animation data can be tricky too. having only key frame saves storage. It require the program to rebuild the entire animation (ex: with IK data).
Same goes for textures. More pixels means more work... simple as that.
You can have any system you want actually. Then for each method there are downsides.
Spark stores a compressed version of the model's bone animations. It does not use any sort of IK system, rather all the poses are "baked in" when the animation is exported.
I wish Combat would become an official part of NS2. Sometimes I just want to slug it out with others without waiting for half an hour in the lobby and then losing just because half the people were sleeping. Besides, Combat is a good training of aiming skills as well as certain tactics.
I've bought NS2:Combat for that purpose and the game is dead. 3 servers available with no people playing even at otherwise peak hours. Sos tupid and I really liked the game and it was huge fun for the first few days after release.
Join the combat gather group for game invites and info on games.
Comments
Can you explain this in a little more detail to someone who doesn't understand coding at that level? It sounds to me like you are saying that NS2 is the most complex game it can possibly be in 32bit and adding anything more would make it incompatible, but there's no way that could be true.
I get that some computers / laptops are 32 bit, but 64 bit i would say is a must.
forums.unknownworlds.com/discussion/132243/32-bit-crashes-whats-going-on-natural-selection-2/p1
Actually, skins should increase the memory usage just as much. 90% of a model is just the texture data. Models themselves are relatively light.
EDIT: Maybe not... not sure about this exactly... animations take up a ton of memory... but similar models should share animation data... (eg shadow skulk, kodiak skulk both inherit animation from skulk).
I've bought NS2:Combat for that purpose and the game is dead. 3 servers available with no people playing even at otherwise peak hours. Sos tupid and I really liked the game and it was huge fun for the first few days after release.
It depends on how things are done and what method was selected.
1 / Model + Animation (bone, ragdoll etc.). Lowest consumption but makes the program (or ragdoll stuff) work more. Hardware is pretty efficient at it now.
1B/ You can save CPU/GPU cycles by rendering in memory every animation frame before using it. Pre-calculating takes more memory and rendering time after loading. Useful if you want to draw an army running on a field and as the camera is IN the action, the model have to be detailed (lot of vertex). Animation stuff would probably slow down everything in this case.
2 / model + vertex animated (each animation frame is already rendered). So it's N vertex * N frame. Not really something any coder should do. But in the mean time, no need for 3D animation function/library stuff in the code. You just select the right frame and use the vertex.
Animation data can be tricky too. having only key frame saves storage. It require the program to rebuild the entire animation (ex: with IK data).
Same goes for textures. More pixels means more work... simple as that.
You can have any system you want actually. Then for each method there are downsides.
Spark stores a compressed version of the model's bone animations. It does not use any sort of IK system, rather all the poses are "baked in" when the animation is exported.
And yes, models share animation data.
Join the combat gather group for game invites and info on games.
http://steamcommunity.com/groups/combatgather