<!--quoteo(post=2063985:date=Jan 21 2013, 04:06 AM:name=matso)--><div class='quotetop'>QUOTE (matso @ Jan 21 2013, 04:06 AM) <a href="index.php?act=findpost&pid=2063985"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Mmm... the current iteration of the game does not contain any easy optimizations. Those have been done; fps doubled or trippled over the last 6 months before the release. Yea, it was really bad ...
So while performance will increase a little bit now and then, any major performance increases will require complex and time-consuming re-architecting, and its doubtful that you can make a case for that compared to adding more content/features.
Do note that because the rendering thread is run in a parallel thread, decreasing the amount of stuff rendered will not normally affect your fps (unless you have a really old graphics card) unless your fps is really high OR you are running around in areas full of models/particles. Usually, the bottleneck is in the game logic part.
You can use either the "profile" console command to do online profiling, or "p_logall" and the perfanalyzer.py program to do offline profiling.<!--QuoteEnd--></div><!--QuoteEEnd-->
Well, thats pretty depressing considering the amount of fps drops and hitching still in the game.
In an event-driven scripting language, which I assume Lua is, there shouldn't be any code running in the nodes at all unless some event took place (node getting repaired, node getting destroyed).
Same should actually be true for cysts. There should only be logic involved in cysts when an existing one gets destroyed. There is no other time when you need to do something with the cyst linking. Placing a new cyst only requires to check the radius requirements since it assumes that all cysts are up to date regarding their connectivity since they get updated when one gets destroyed.
The infestation is probably performance heavy because it seems to be recomputed whenever you look at a location anew, otherwise it probably wouldn't have any additional logic once it has expanded to a cyst's maximum range.
Alien structures are probably also a bit more logic intense because of their maturing process, which requires to update them once every frame (or after a set timer, depending on whether Lua is capable of having multiple independent timers per entity that are managed by the native C++ code and call Lua functions when the timers pop or if it actually has to calculate it's own DeltaTime every tick and check the timer itself) compared to marine structures. And depending on whether or not Lua has an integrated state machine, those alien structures shouldn't get any per-frame logic updates anymore once they are fully matured.
<!--quoteo(post=2064171:date=Jan 21 2013, 04:17 AM:name=CrushaK)--><div class='quotetop'>QUOTE (CrushaK @ Jan 21 2013, 04:17 AM) <a href="index.php?act=findpost&pid=2064171"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->What logic would be involved in power nodes?
In an event-driven scripting language, which I assume Lua is, there shouldn't be any code running in the nodes at all unless some event took place (node getting repaired, node getting destroyed).
Same should actually be true for cysts. There should only be logic involved in cysts when an existing one gets destroyed. There is no other time when you need to do something with the cyst linking. Placing a new cyst only requires to check the radius requirements since it assumes that all cysts are up to date regarding their connectivity since they get updated when one gets destroyed.
The infestation is probably performance heavy because it seems to be recomputed whenever you look at a location anew, otherwise it probably wouldn't have any additional logic once it has expanded to a cyst's maximum range.
Alien structures are probably also a bit more logic intense because of their maturing process, which requires to update them once every frame (or after a set timer, depending on whether Lua is capable of having multiple independent timers per entity that are managed by the native C++ code and call Lua functions when the timers pop or if it actually has to calculate it's own DeltaTime every tick and check the timer itself) compared to marine structures. And depending on whether or not Lua has an integrated state machine, those alien structures shouldn't get any per-frame logic updates anymore once they are fully matured.<!--QuoteEnd--></div><!--QuoteEEnd-->
I remember a conversation a while back I had with a guy who looked at cyst code because I brought up this very thing. Cysts check their connection once a second. I bet marine structures do that same thing. I'm not sure how Lua works, but in C++ this would be handled much better by having cysts tell cysts its connected to that it has died when it dies and then those cysts check if it depended on that cyst for its connection back to the hive and then if unconnected tell cysts that depend on it for a connection that it was no longer connected. Same for marine structures. Powernodes would store a list of buildings connected to it and when the powernode is destroyed, tell the buildings, lol powernode down.
Structures might also be checking once a frame if something is near, such as crags and armories. They might be doing their checking each tick/frame to see if they should be changing what they are doing instead of the player telling the structure "Hey, im close so do your ######". If every structure that does something to something else is checking each frame what is and is not going to be acted on, that is a lot of unnecessary code being run.
<!--quoteo(post=2064173:date=Jan 21 2013, 04:30 AM:name=Yuuki)--><div class='quotetop'>QUOTE (Yuuki @ Jan 21 2013, 04:30 AM) <a href="index.php?act=findpost&pid=2064173"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I'm also a bit puzzle about how cysts/power nodes could affect client side performance so much, it's not like they are doing much.<!--QuoteEnd--></div><!--QuoteEEnd-->
The client needs to check if those things are happening because of things like animations and whatever changes in visual can occur. It would also effect prediction actions. If you move to an armory before the server realizes it, then the client will predict what is happening. It could be that you get to the armory and the client predicts that you are going to get health and ammo, but the powernode goes down before it actually happens on the server so you don't actually get it (the chance of happening is very very small given the time between ticks, but it could).
Ideally the Armory has a slightly larger non-blocking collision component than the actual mesh collision and then gets notified of incoming players through a Touch event from the collision code, rather than checking for player distances every frame. This event would occur on the server as well as predicted event on the client.
<!--quoteo(post=2063953:date=Jan 20 2013, 03:36 PM:name=CrushaK)--><div class='quotetop'>QUOTE (CrushaK @ Jan 20 2013, 03:36 PM) <a href="index.php?act=findpost&pid=2063953"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Actually would the lack of it be really poor design that sacrifices standards of level design that have been around for more than the last decade for a minor desperate performance gain.
If the removal of that stuff actually has any noticeable impact on the performance, you rather have to blame the engine than the existence of those assets. Other engines laugh about such things and don't really care a lot these days about how many polygons they have to render. The complexity of shaders and number of different materials on a mesh weigh much more into performance than the bare object and polygon count.<!--QuoteEnd--></div><!--QuoteEEnd-->
The point is that the engine <b>does</b> suck, and removing stuff in the example does have a massive impact on FPS. Go play on any ns2classic map. The maps are actually far bigger in most cases, but the FPS you get on them is dramatically higher than any of the stock maps - especially the worst offenders like tram. Calling up to a 3x performance increase "minor" is simply hilarious.
On most ns2 classic maps, I hold a solid 120-150 FPS in all areas even late into the game. On a non-tram stock map, I'm lucky to keep 80 FPS in the early game that slowly drops down to the 40-60 range for the rest of the game. It's a massive, massive difference, and much of it comes from how the engine is handling extra objects in the map.
The engine is terrible, but you can work around it by getting rid of all the useless crap on most maps. Fact.
<!--quoteo(post=2063985:date=Jan 20 2013, 05:06 PM:name=matso)--><div class='quotetop'>QUOTE (matso @ Jan 20 2013, 05:06 PM) <a href="index.php?act=findpost&pid=2063985"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Do note that because the rendering thread is run in a parallel thread, decreasing the amount of stuff rendered will not normally affect your fps (unless you have a really old graphics card) unless your fps is really high OR you are running around in areas full of models/particles. Usually, the bottleneck is in the game logic part.<!--QuoteEnd--></div><!--QuoteEEnd-->
I think there's the possibility many people disagree with you on what your threshold of very high is. To give some more specific numbers:
On ns2classic maps, my FPS is almost always 120+ in all areas, spiking as high at 150-160. This goes late into the game, and gives optimal FPS for playing (ie: a solid 120 FPS to be paired with a 120hz monitor).
On average stock maps (that aren't tram. tram has significantly worse FPS than anything else), I start the game with 80ish FPS in most areas. That FPS drops down to 40-60 as the game progresses.
40-60 FPS is not "high" FPS. It's terrible FPS that makes the gameplay feel choppy to anyone who's played on engines that can support 120 FPS with no lag. Holding that level of FPS on a top level PC should not be an acceptable benchmark.
edit: Note, I'm talking about playing on <b>just</b> the ns2c maps. Not the full NS2c mod. Just to throw that out as a reason for why those maps perform dramatically better than stock. If you go into the editor and examine those maps, the biggest difference you'll run into is that they're very simplistic. You have walls and boxes in rooms, but not much else. Hardly anything in the way of decorative pipes/wall plating/what have you.
<!--quoteo(post=2064179:date=Jan 21 2013, 08:55 PM:name=JAMESEARLJONOS)--><div class='quotetop'>QUOTE (JAMESEARLJONOS @ Jan 21 2013, 08:55 PM) <a href="index.php?act=findpost&pid=2064179"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I think there's the possibility many people disagree with you on what your threshold of very high is. To give some more specific numbers:
On ns2classic maps, my FPS is almost always 120+ in all areas, spiking as high at 150-160. This goes late into the game, and gives optimal FPS for playing (ie: a solid 120 FPS to be paired with a 120hz monitor).
On average stock maps (that aren't tram. tram has significantly worse FPS than anything else), I start the game with 80ish FPS in most areas. That FPS drops down to 40-60 as the game progresses.
40-60 FPS is not "high" FPS. It's terrible FPS that makes the gameplay feel choppy to anyone who's played on engines that can support 120 FPS with no lag. Holding that level of FPS on a top level PC should not be an acceptable benchmark.
edit: Note, I'm talking about playing on <b>just</b> the ns2c maps. Not the full NS2c mod. Just to throw that out as a reason for why those maps perform dramatically better than stock. If you go into the editor and examine those maps, the biggest difference you'll run into is that they're very simplistic. You have walls and boxes in rooms, but not much else. Hardly anything in the way of decorative pipes/wall plating/what have you.<!--QuoteEnd--></div><!--QuoteEEnd-->
i agree.
in some threads, when i see other forum posters saying that it's "playable", i often wonder what kind of fps range they're talking about, as "playable" is very subjective. i have a friend who is playing ns2 with 15 fps and he's far better than i am. he deems the game "playable". for me, maybe i'm just spoiled, but anything less than 60 fps at any point in the game is "unplayable".
i myself have a lowly 3-year-old LCD monitor with a refresh rate of 60hz, which i think is the standard for most people. this translates to at least 60 fps for no-chop-gaming experience. i run a i2500k overclocked to 3.8ghz and still have my fps drop under 60 during mid-to-late game. i don't think that's acceptable at all.
now imagine someone with a 120hz monitor who will require his game to run at least 120 fps at any point in the game in order for it to not be choppy. he'll probably need 6ghz or something. i'd be very sad if i were him.
I get 60 fps in the menu and i have a corei5 8 gigs of ram and a 6870 1gb
but someone mentioned something about SSDs I use one and i install ns2 on it, i hoped it would help with anything related to that game. not sure if i have issues though except the occasional lockup with it.
Kouji_SanSr. Hινε UÏкεεÏεг - EUPT DeputyThe NetherlandsJoin Date: 2003-05-13Member: 16271Members, NS2 Playtester, Squad Five Blue
edited January 2013
An SSD won't affect your FPS, it will only affect your load times. And you should get more FPS then 60 in the menu or readyroom on that rig, unless you're using v-sync
ScardyBobScardyBobJoin Date: 2009-11-25Member: 69528Forum Admins, Forum Moderators, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow
<!--quoteo(post=2064205:date=Jan 21 2013, 06:06 AM:name=cream)--><div class='quotetop'>QUOTE (cream @ Jan 21 2013, 06:06 AM) <a href="index.php?act=findpost&pid=2064205"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->in some threads, when i see other forum posters saying that it's "playable", i often wonder what kind of fps range they're talking about, as "playable" is very subjective. i have a friend who is playing ns2 with 15 fps and he's far better than i am. he deems the game "playable". for me, maybe i'm just spoiled, but anything less than 60 fps at any point in the game is "unplayable".<!--QuoteEnd--></div><!--QuoteEEnd-->
Personally, I find my cutoff for 'playable' fps to be about 50. Anything below begins to affect my gameplay.
<!--quoteo(post=2064205:date=Jan 21 2013, 02:06 PM:name=cream)--><div class='quotetop'>QUOTE (cream @ Jan 21 2013, 02:06 PM) <a href="index.php?act=findpost&pid=2064205"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->i have a friend who is playing ns2 with 15 fps and he's far better than i am. he deems the game "playable". for me, maybe i'm just spoiled, but anything less than 60 fps at any point in the game is "unplayable".<!--QuoteEnd--></div><!--QuoteEEnd-->
I'm one of those people. My FPS fluctuates from 20 to 5, depending on the scene. But I'm used to it and to be fair, I tend to score quite highly on the scoreboard. I choose to command more often though since it is one of the few things that I can do without noticing the poor FPS. They can optimise the commander experience though, as I mentioned in another thread. I don't understand the need to render the walls, for example. They could simply be replaced by a black space. It would make the map easier to see, improve performance slightly, and look tidier.
<!--quoteo(post=2064177:date=Jan 21 2013, 01:47 PM:name=JAMESEARLJONOS)--><div class='quotetop'>QUOTE (JAMESEARLJONOS @ Jan 21 2013, 01:47 PM) <a href="index.php?act=findpost&pid=2064177"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The point is that the engine <b>does</b> suck, and removing stuff in the example does have a massive impact on FPS. Go play on any ns2classic map. The maps are actually far bigger in most cases, but the FPS you get on them is dramatically higher than any of the stock maps - especially the worst offenders like tram. Calling up to a 3x performance increase "minor" is simply hilarious.<!--QuoteEnd--></div><!--QuoteEEnd-->
You sir do obviously do not know much about graphics/rendering and performance.
The NS2 enginge (aka the spark engine) is, for the time and effort put into it, a piece of art itselve. I doubt that others would be able to produce such an engine with the same amount of manpower and time.
As your statement of the FPS. Yes the engine is not yet fully optimized, but it was either that or a delayed release. And as with most games bugfixes/enhancements come after content. When it comes to the point that removing objects increases performance, of friggin course it does so. 3D Objects rendered in game (also called a mech) take different amount of GPU power to renderd based on a couple of factors. First of all the amount of polygons (sort of the sides) it uses. Besides the polygon itselve you also have to take into account the lightnigh, shadow and collysion detection on that object. And these are just a couple things.
Ofcourse removing these object increases FPS. And while you're doing it you might aswell smooth all surfaces untill they excist out of 1 polygon so we can all come back to play NS2 in doom 3d style.....
I understand the reason to create NS2c or a better performance NS2 well because with a "normal" rig I'd also be happy to play NS2 smoother myselve. Therefor I really hope the developers start spending some more time into this then into the modding tools/new maps. Simply "simplefying the map" is however not what I call performance improvements.
<!--quoteo(post=2064337:date=Jan 21 2013, 11:06 AM:name=Mindstorm)--><div class='quotetop'>QUOTE (Mindstorm @ Jan 21 2013, 11:06 AM) <a href="index.php?act=findpost&pid=2064337"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Simply "simplefying the map" is however not what I call performance improvements.<!--QuoteEnd--></div><!--QuoteEEnd-->
Sure it is. On most of the maps right now, you can gain a <b>huge</b> performance increase by cutting out all of the map aspects that are more for eye candy than actual gameplay function.
If the choice is between seeing crap like random wall plating/non-gameplay effecting pipes/decorative parts to the map, and actually playing the map with a solid 120+ FPS, I'll choose the latter every time.
<!--quoteo(post=2064337:date=Jan 21 2013, 08:06 PM:name=Mindstorm)--><div class='quotetop'>QUOTE (Mindstorm @ Jan 21 2013, 08:06 PM) <a href="index.php?act=findpost&pid=2064337"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->As your statement of the FPS. Yes the engine is not yet fully optimized, but it was either that or a delayed release. And as with most games bugfixes/enhancements come after content. When it comes to the point that removing objects increases performance, of friggin course it does so. 3D Objects rendered in game (also called a mech) take different amount of GPU power to renderd based on a couple of factors. First of all the amount of polygons (sort of the sides) it uses. Besides the polygon itselve you also have to take into account the lightnigh, shadow and collysion detection on that object. And these are just a couple things.<!--QuoteEnd--></div><!--QuoteEEnd-->
It's funny you mention GPU power, as virtually everyone agrees on NS2 being mostly slowed down by the CPU which handles the game logic. I only got a HD7950 but the game NEVER waits for the GPU...
Even the guy with a GTX690 here gets less than 60 FPS in lategame.
The thing about cysts constantly checking for other cysts etc. really is a quite terrible way of handling things if it's true.
<!--quoteo(post=2064337:date=Jan 21 2013, 07:06 PM:name=Mindstorm)--><div class='quotetop'>QUOTE (Mindstorm @ Jan 21 2013, 07:06 PM) <a href="index.php?act=findpost&pid=2064337"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The NS2 enginge (aka the spark engine) is, for the time and effort put into it, a piece of art itselve. I doubt that others would be able to produce such an engine with the same amount of manpower and time.<!--QuoteEnd--></div><!--QuoteEEnd--> You need to realise it's caveats like "for the time and effort put into it..." that nobody cares about - it's the end product. It's like getting a crappy "D-" at school but taking solace in the fact that you got a "1" for effort.
<!--quoteo(post=2064337:date=Jan 21 2013, 07:06 PM:name=Mindstorm)--><div class='quotetop'>QUOTE (Mindstorm @ Jan 21 2013, 07:06 PM) <a href="index.php?act=findpost&pid=2064337"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Ofcourse removing these object increases FPS. And while you're doing it you might aswell smooth all surfaces untill they excist out of 1 polygon so we can all come back to play NS2 in doom 3d style.....
I understand the reason to create NS2c or a better performance NS2 well because with a "normal" rig I'd also be happy to play NS2 smoother myselve. Therefor I really hope the developers start spending some more time into this then into the modding tools/new maps. Simply "simplefying the map" is however not what I call performance improvements.<!--QuoteEnd--></div><!--QuoteEEnd--> I think the point being made here is not simply that removing stuff improves fps, but that - by the sounds of it - there's not much else we can actually do without a massive overhaul. If UWE want to focus on new content and features, we need alternative ways of improving our gaming experience.
<!--quoteo(post=2064374:date=Jan 21 2013, 08:04 PM:name=Tweadle)--><div class='quotetop'>QUOTE (Tweadle @ Jan 21 2013, 08:04 PM) <a href="index.php?act=findpost&pid=2064374"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You need to realise it's caveats like "for the time and effort put into it..." that nobody cares about - it's the end product. It's like getting a crappy "D-" at school but taking solace in the fact that you got a "1" for effort.<!--QuoteEnd--></div><!--QuoteEEnd-->
Ahaha! Put perfectly! People constantly use the argument: "other game developers have more professionals" and "UWE is an indie company" as though they are valid excuses.
ScardyBobScardyBobJoin Date: 2009-11-25Member: 69528Forum Admins, Forum Moderators, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow
<!--quoteo(post=2064374:date=Jan 21 2013, 12:04 PM:name=Tweadle)--><div class='quotetop'>QUOTE (Tweadle @ Jan 21 2013, 12:04 PM) <a href="index.php?act=findpost&pid=2064374"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You need to realise it's caveats like "for the time and effort put into it..." that nobody cares about - it's the end product. It's like getting a crappy "D-" at school but taking solace in the fact that you got a "1" for effort.<!--QuoteEnd--></div><!--QuoteEEnd--> If you previously got an F, then it would actually be a good thing. Nobody expects a failing student to suddenly become an A student overnight and gamers shouldn't expect an Indie studio to put out a AAA-level quality game. If people are so concerned about bugs, less-than-stellar performance, and balance issues, there are many bland, AAA games that may satisfy you instead. I'm willing to accept some of these sacrifices for the interesting gameplay that Indie games regularly provide.
<!--quoteo(post=2064374:date=Jan 21 2013, 09:04 PM:name=Tweadle)--><div class='quotetop'>QUOTE (Tweadle @ Jan 21 2013, 09:04 PM) <a href="index.php?act=findpost&pid=2064374"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You need to realise it's caveats like "for the time and effort put into it..." that nobody cares about - it's the end product. It's like getting a crappy "D-" at school but taking solace in the fact that you got a "1" for effort.<!--QuoteEnd--></div><!--QuoteEEnd-->
You forget the fact that you paid a max of 23 euro's (don't know the dollar price) for this game. With steam sales all around x-mas I guess the avarage player probably spent more like 15 euro's.
Besides that you did read the system requirements didn't you? Every game takes these and a minimum is like what? 10-20 fps?
<b>System Requirements</b> <i>Minimum:</i>
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->OS:Windows 7 32/64-bit / Vista 32/64 / XP Processor:Core 2 Duo 2.6 ghz Memory:2 GB RAM Graphics:DirectX 9 compatible video card with 1GB, ATI X800, NVidia 8600 or better DirectX®:9.0 Hard Drive:5 GB HD space<!--QuoteEnd--></div><!--QuoteEEnd-->
Compare these to op: <!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->2.0ghz quadcore CPU, 4650 HD Radeon 2gb vram, 4gb ram<!--QuoteEnd--></div><!--QuoteEEnd-->
I wonder what's causing his low fps....
If your lunning low fps your hardware is probably not good enough for the sparks enginge's leetness. Do not take complainments to unknown worlds but rather to your own lack of being able to read the system requirements.
<!--quoteo(post=2064421:date=Jan 21 2013, 09:16 PM:name=ScardyBob)--><div class='quotetop'>QUOTE (ScardyBob @ Jan 21 2013, 09:16 PM) <a href="index.php?act=findpost&pid=2064421"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->If you previously got an F, then it would actually be a good thing. Nobody expects a failing student to suddenly become an A student overnight and gamers shouldn't expect an Indie studio to put out a AAA-level quality game. If people are so concerned about bugs, less-than-stellar performance, and balance issues, there are many bland, AAA games that may satisfy you instead. I'm willing to accept some of these sacrifices for the interesting gameplay that Indie games regularly provide.<!--QuoteEnd--></div><!--QuoteEEnd--> I still think this is a poor excuse. A "D-" is still a "D-" and getting an "F" prior doesn't magically make the "D-" desirable. If I shouldn't expect an Indie Studio to put out a AAA-level game, then UWE shouldn't have attempted to in the first place. As it happens my gripe is not that it can't perform well next to those titles, it's that it tried to in the first place and fell flat. The one thing I expect from <i>every game</i> is for it to run properly and not hitch - perform on a different stage and expect the audience to judge against those that came before you. I only ever make exception when a game is deliberately pushing the frontiers of science to make a point (and only for single-player). Needless to say, NS2 is a world apart from that standard.
I respect the difficulty of creating a title like NS2 for a small team such as UWE but I wish, perhaps, they had feared it!
@Mindstorm For the record, I pre-purchased NS2 when the requirements were laughably lower than that and so did many others. To reiterate for your other point, however much money I spend on a game, I still expect it to run well.
I see the opportunity to further optimize a large portion of the gamecode, as many events are triggered simply by checking something every single frame. While overall that may not add up to much time, every little bit does help to an extent. I will say from my testing the slowest parts of the game have always been movement code, and while they have done much to accelerate that, I believe it still remains the major slowness. Infestation and other things do add to the fps hits, but comparatively they are much less so.
There are many factors with regards to perceived slowness however and I still believe that a major proponent of that is the infestation network causing network traffic bottlenecks. Each cyst currently is comprised of 7 entities, all which need to be propagated between the client/server. I would still personally like to see a good client side infestation model developed that requires no additional entities.
<!--quoteo(post=2063985:date=Jan 20 2013, 08:06 PM:name=matso)--><div class='quotetop'>QUOTE (matso @ Jan 20 2013, 08:06 PM) <a href="index.php?act=findpost&pid=2063985"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Mmm... the current iteration of the game does not contain any easy optimizations. Those have been done; fps doubled or trippled over the last 6 months before the release. Yea, it was really bad ...
So while performance will increase a little bit now and then, any major performance increases will require complex and time-consuming re-architecting, and its doubtful that you can make a case for that compared to adding more content/features.
Do note that because the rendering thread is run in a parallel thread, decreasing the amount of stuff rendered will not normally affect your fps (unless you have a really old graphics card) unless your fps is really high OR you are running around in areas full of models/particles. Usually, the bottleneck is in the game logic part.
You can use either the "profile" console command to do online profiling, or "p_logall" and the perfanalyzer.py program to do offline profiling.<!--QuoteEnd--></div><!--QuoteEEnd-->
If this is the case would they not be spending more time trying to open the game up for more cores assuming that it is so hard to make it run any better than it does now? Given too that the game has so many loops running every frame I would logically think that removing them in place of event triggers would dramatically improve server performance.
matsoMaster of PatchesJoin Date: 2002-11-05Member: 7000Members, Forum Moderators, NS2 Developer, Constellation, NS2 Playtester, Squad Five Blue, Squad Five Silver, Squad Five Gold, Reinforced - Shadow, NS2 Community Developer
<!--quoteo(post=2064651:date=Jan 22 2013, 06:24 AM:name=ZEROibis)--><div class='quotetop'>QUOTE (ZEROibis @ Jan 22 2013, 06:24 AM) <a href="index.php?act=findpost&pid=2064651"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->If this is the case would they not be spending more time trying to open the game up for more cores assuming that it is so hard to make it run any better than it does now?<!--QuoteEnd--></div><!--QuoteEEnd-->
Yea, that's what I had in mind when I wrote "complex and time-consuming re-architecting". There are some pretty straightforward optimizations possible when it comes to multi-threading, but they require capabilities that are not part of the standard Lua VMs, and it would also require a partial rewrite of the ns2 lua code.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Given too that the game has so many loops running every frame I would logically think that removing them in place of event triggers would dramatically improve server performance.<!--QuoteEnd--></div><!--QuoteEEnd-->
I used to think so to. But for games like NS2, event based coding is just to complex, fragile and costly - timed checks turns out to be much easier to code and understand, and there is no clear case for it being significantly slower.
If you check the profiler, OnUpdate() for the various classes is not a dominant cost (any longer; costly OnUpdate() fixes belongs to the class of "easy" optimizations that has already been done). The real cost is processing moves and updating physics/animations, which are mostly in C++.
It's a pretty old comp, but I don't see how my specs are relevant since I can play modern games, and I should ideally be able to play NS2 very smoothly.<!--QuoteEnd--></div><!--QuoteEEnd-->
I'm really curious as to what modern games are playable under your specs. I think you're bull sht. your computer is ridiculously under the requirements on the ns2 website. buy a new computer, end of thread.
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=2064868:date=Jan 22 2013, 10:47 AM:name=t0ne)--><div class='quotetop'>QUOTE (t0ne @ Jan 22 2013, 10:47 AM) <a href="index.php?act=findpost&pid=2064868"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I'm really curious as to what modern games are playable under your specs. I think you're bull sht. your computer is ridiculously under the requirements on the ns2 website. buy a new computer, end of thread.<!--QuoteEnd--></div><!--QuoteEEnd-->
Don't need to be an ass, maybe he purchased the game when this was displayed in the buy page.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->What are the system requirements?
The target specifications for Version 1.0 are 1.2 GHz Processor, 256MB RAM, a DirectX 9 level graphics card, Windows Vista/2000/XP, Steam, mouse, keyboard and of course, an internet connection. We are working hard to make sure NS2 runs well on average hardware without having to upgrade your machine!<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo(post=2064876:date=Jan 22 2013, 10:52 AM:name=IeptBarakat)--><div class='quotetop'>QUOTE (IeptBarakat @ Jan 22 2013, 10:52 AM) <a href="index.php?act=findpost&pid=2064876"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Don't need to be an ass, maybe he purchased the game when this was displayed in the buy page.<!--QuoteEnd--></div><!--QuoteEEnd-->
sure, good point, but his video card was released in 2008-09-10. that video card is now 5 years old. hes being completely ignorant or just a cheap ass that doesnt want to spend money on a new computer and wants to complain.
<!--quoteo(post=2064879:date=Jan 22 2013, 09:59 AM:name=t0ne)--><div class='quotetop'>QUOTE (t0ne @ Jan 22 2013, 09:59 AM) <a href="index.php?act=findpost&pid=2064879"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->sure, good point, but his video card was released in 2008-09-10. that video card is now 5 years old. hes being completely ignorant or just a cheap ass that doesnt want to spend money on a new computer and wants to complain.<!--QuoteEnd--></div><!--QuoteEEnd-->
If he bought it under the 1.0 version listed requirements, he isn't being ignorant. To be frank the real requirements should be more like
Minimum (30-60fps) 3.0Ghz Quadcore nvidia 600 series ati 6000 series 4GB RAM 7200 RPM HD
Recommended would be i5 or higher, 8gb ram, SSD, etc etc etc
Guess what though, if they told people their game required a minimum 1500 dollar investment to play well, they would've tanked. (I consider 60 fps poor, so you may disagree that 30 fps plays poorly)
Comments
So while performance will increase a little bit now and then, any major performance increases will require complex and time-consuming re-architecting, and its doubtful that you can make a case for that compared to adding more content/features.
Do note that because the rendering thread is run in a parallel thread, decreasing the amount of stuff rendered will not normally affect your fps (unless you have a really old graphics card) unless your fps is really high OR you are running around in areas full of models/particles. Usually, the bottleneck is in the game logic part.
You can use either the "profile" console command to do online profiling, or "p_logall" and the perfanalyzer.py program to do offline profiling.<!--QuoteEnd--></div><!--QuoteEEnd-->
Well, thats pretty depressing considering the amount of fps drops and hitching still in the game.
What logic would be involved in power nodes?
In an event-driven scripting language, which I assume Lua is, there shouldn't be any code running in the nodes at all unless some event took place (node getting repaired, node getting destroyed).
Same should actually be true for cysts. There should only be logic involved in cysts when an existing one gets destroyed. There is no other time when you need to do something with the cyst linking. Placing a new cyst only requires to check the radius requirements since it assumes that all cysts are up to date regarding their connectivity since they get updated when one gets destroyed.
The infestation is probably performance heavy because it seems to be recomputed whenever you look at a location anew, otherwise it probably wouldn't have any additional logic once it has expanded to a cyst's maximum range.
Alien structures are probably also a bit more logic intense because of their maturing process, which requires to update them once every frame (or after a set timer, depending on whether Lua is capable of having multiple independent timers per entity that are managed by the native C++ code and call Lua functions when the timers pop or if it actually has to calculate it's own DeltaTime every tick and check the timer itself) compared to marine structures. And depending on whether or not Lua has an integrated state machine, those alien structures shouldn't get any per-frame logic updates anymore once they are fully matured.
In an event-driven scripting language, which I assume Lua is, there shouldn't be any code running in the nodes at all unless some event took place (node getting repaired, node getting destroyed).
Same should actually be true for cysts. There should only be logic involved in cysts when an existing one gets destroyed. There is no other time when you need to do something with the cyst linking. Placing a new cyst only requires to check the radius requirements since it assumes that all cysts are up to date regarding their connectivity since they get updated when one gets destroyed.
The infestation is probably performance heavy because it seems to be recomputed whenever you look at a location anew, otherwise it probably wouldn't have any additional logic once it has expanded to a cyst's maximum range.
Alien structures are probably also a bit more logic intense because of their maturing process, which requires to update them once every frame (or after a set timer, depending on whether Lua is capable of having multiple independent timers per entity that are managed by the native C++ code and call Lua functions when the timers pop or if it actually has to calculate it's own DeltaTime every tick and check the timer itself) compared to marine structures. And depending on whether or not Lua has an integrated state machine, those alien structures shouldn't get any per-frame logic updates anymore once they are fully matured.<!--QuoteEnd--></div><!--QuoteEEnd-->
I remember a conversation a while back I had with a guy who looked at cyst code because I brought up this very thing. Cysts check their connection once a second. I bet marine structures do that same thing. I'm not sure how Lua works, but in C++ this would be handled much better by having cysts tell cysts its connected to that it has died when it dies and then those cysts check if it depended on that cyst for its connection back to the hive and then if unconnected tell cysts that depend on it for a connection that it was no longer connected. Same for marine structures. Powernodes would store a list of buildings connected to it and when the powernode is destroyed, tell the buildings, lol powernode down.
Structures might also be checking once a frame if something is near, such as crags and armories. They might be doing their checking each tick/frame to see if they should be changing what they are doing instead of the player telling the structure "Hey, im close so do your ######". If every structure that does something to something else is checking each frame what is and is not going to be acted on, that is a lot of unnecessary code being run.
The client needs to check if those things are happening because of things like animations and whatever changes in visual can occur. It would also effect prediction actions. If you move to an armory before the server realizes it, then the client will predict what is happening. It could be that you get to the armory and the client predicts that you are going to get health and ammo, but the powernode goes down before it actually happens on the server so you don't actually get it (the chance of happening is very very small given the time between ticks, but it could).
If the removal of that stuff actually has any noticeable impact on the performance, you rather have to blame the engine than the existence of those assets. Other engines laugh about such things and don't really care a lot these days about how many polygons they have to render. The complexity of shaders and number of different materials on a mesh weigh much more into performance than the bare object and polygon count.<!--QuoteEnd--></div><!--QuoteEEnd-->
The point is that the engine <b>does</b> suck, and removing stuff in the example does have a massive impact on FPS. Go play on any ns2classic map. The maps are actually far bigger in most cases, but the FPS you get on them is dramatically higher than any of the stock maps - especially the worst offenders like tram. Calling up to a 3x performance increase "minor" is simply hilarious.
On most ns2 classic maps, I hold a solid 120-150 FPS in all areas even late into the game. On a non-tram stock map, I'm lucky to keep 80 FPS in the early game that slowly drops down to the 40-60 range for the rest of the game. It's a massive, massive difference, and much of it comes from how the engine is handling extra objects in the map.
The engine is terrible, but you can work around it by getting rid of all the useless crap on most maps. Fact.
I think there's the possibility many people disagree with you on what your threshold of very high is. To give some more specific numbers:
On ns2classic maps, my FPS is almost always 120+ in all areas, spiking as high at 150-160. This goes late into the game, and gives optimal FPS for playing (ie: a solid 120 FPS to be paired with a 120hz monitor).
On average stock maps (that aren't tram. tram has significantly worse FPS than anything else), I start the game with 80ish FPS in most areas. That FPS drops down to 40-60 as the game progresses.
40-60 FPS is not "high" FPS. It's terrible FPS that makes the gameplay feel choppy to anyone who's played on engines that can support 120 FPS with no lag. Holding that level of FPS on a top level PC should not be an acceptable benchmark.
edit: Note, I'm talking about playing on <b>just</b> the ns2c maps. Not the full NS2c mod. Just to throw that out as a reason for why those maps perform dramatically better than stock. If you go into the editor and examine those maps, the biggest difference you'll run into is that they're very simplistic. You have walls and boxes in rooms, but not much else. Hardly anything in the way of decorative pipes/wall plating/what have you.
On ns2classic maps, my FPS is almost always 120+ in all areas, spiking as high at 150-160. This goes late into the game, and gives optimal FPS for playing (ie: a solid 120 FPS to be paired with a 120hz monitor).
On average stock maps (that aren't tram. tram has significantly worse FPS than anything else), I start the game with 80ish FPS in most areas. That FPS drops down to 40-60 as the game progresses.
40-60 FPS is not "high" FPS. It's terrible FPS that makes the gameplay feel choppy to anyone who's played on engines that can support 120 FPS with no lag. Holding that level of FPS on a top level PC should not be an acceptable benchmark.
edit: Note, I'm talking about playing on <b>just</b> the ns2c maps. Not the full NS2c mod. Just to throw that out as a reason for why those maps perform dramatically better than stock. If you go into the editor and examine those maps, the biggest difference you'll run into is that they're very simplistic. You have walls and boxes in rooms, but not much else. Hardly anything in the way of decorative pipes/wall plating/what have you.<!--QuoteEnd--></div><!--QuoteEEnd-->
i agree.
in some threads, when i see other forum posters saying that it's "playable", i often wonder what kind of fps range they're talking about, as "playable" is very subjective. i have a friend who is playing ns2 with 15 fps and he's far better than i am. he deems the game "playable". for me, maybe i'm just spoiled, but anything less than 60 fps at any point in the game is "unplayable".
i myself have a lowly 3-year-old LCD monitor with a refresh rate of 60hz, which i think is the standard for most people. this translates to at least 60 fps for no-chop-gaming experience. i run a i2500k overclocked to 3.8ghz and still have my fps drop under 60 during mid-to-late game. i don't think that's acceptable at all.
now imagine someone with a 120hz monitor who will require his game to run at least 120 fps at any point in the game in order for it to not be choppy. he'll probably need 6ghz or something. i'd be very sad if i were him.
but someone mentioned something about SSDs I use one and i install ns2 on it, i hoped it would help with anything related to that game. not sure if i have issues though except the occasional lockup with it.
Personally, I find my cutoff for 'playable' fps to be about 50. Anything below begins to affect my gameplay.
I'm one of those people. My FPS fluctuates from 20 to 5, depending on the scene. But I'm used to it and to be fair, I tend to score quite highly on the scoreboard. I choose to command more often though since it is one of the few things that I can do without noticing the poor FPS. They can optimise the commander experience though, as I mentioned in another thread. I don't understand the need to render the walls, for example. They could simply be replaced by a black space. It would make the map easier to see, improve performance slightly, and look tidier.
You sir do obviously do not know much about graphics/rendering and performance.
The NS2 enginge (aka the spark engine) is, for the time and effort put into it, a piece of art itselve. I doubt that others would be able to produce such an engine with the same amount of manpower and time.
As your statement of the FPS. Yes the engine is not yet fully optimized, but it was either that or a delayed release. And as with most games bugfixes/enhancements come after content. When it comes to the point that removing objects increases performance, of friggin course it does so. 3D Objects rendered in game (also called a mech) take different amount of GPU power to renderd based on a couple of factors. First of all the amount of polygons (sort of the sides) it uses. Besides the polygon itselve you also have to take into account the lightnigh, shadow and collysion detection on that object. And these are just a couple things.
Ofcourse removing these object increases FPS. And while you're doing it you might aswell smooth all surfaces untill they excist out of 1 polygon so we can all come back to play NS2 in doom 3d style.....
I understand the reason to create NS2c or a better performance NS2 well because with a "normal" rig I'd also be happy to play NS2 smoother myselve. Therefor I really hope the developers start spending some more time into this then into the modding tools/new maps. Simply "simplefying the map" is however not what I call performance improvements.
Sure it is. On most of the maps right now, you can gain a <b>huge</b> performance increase by cutting out all of the map aspects that are more for eye candy than actual gameplay function.
If the choice is between seeing crap like random wall plating/non-gameplay effecting pipes/decorative parts to the map, and actually playing the map with a solid 120+ FPS, I'll choose the latter every time.
It's funny you mention GPU power, as virtually everyone agrees on NS2 being mostly slowed down by the CPU which handles the game logic. I only got a HD7950 but the game NEVER waits for the GPU...
Even the guy with a GTX690 here gets less than 60 FPS in lategame.
The thing about cysts constantly checking for other cysts etc. really is a quite terrible way of handling things if it's true.
You need to realise it's caveats like "for the time and effort put into it..." that nobody cares about - it's the end product. It's like getting a crappy "D-" at school but taking solace in the fact that you got a "1" for effort.
<!--quoteo(post=2064337:date=Jan 21 2013, 07:06 PM:name=Mindstorm)--><div class='quotetop'>QUOTE (Mindstorm @ Jan 21 2013, 07:06 PM) <a href="index.php?act=findpost&pid=2064337"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Ofcourse removing these object increases FPS. And while you're doing it you might aswell smooth all surfaces untill they excist out of 1 polygon so we can all come back to play NS2 in doom 3d style.....
I understand the reason to create NS2c or a better performance NS2 well because with a "normal" rig I'd also be happy to play NS2 smoother myselve. Therefor I really hope the developers start spending some more time into this then into the modding tools/new maps. Simply "simplefying the map" is however not what I call performance improvements.<!--QuoteEnd--></div><!--QuoteEEnd-->
I think the point being made here is not simply that removing stuff improves fps, but that - by the sounds of it - there's not much else we can actually do without a massive overhaul. If UWE want to focus on new content and features, we need alternative ways of improving our gaming experience.
Ahaha! Put perfectly! People constantly use the argument: "other game developers have more professionals" and "UWE is an indie company" as though they are valid excuses.
If you previously got an F, then it would actually be a good thing. Nobody expects a failing student to suddenly become an A student overnight and gamers shouldn't expect an Indie studio to put out a AAA-level quality game. If people are so concerned about bugs, less-than-stellar performance, and balance issues, there are many bland, AAA games that may satisfy you instead. I'm willing to accept some of these sacrifices for the interesting gameplay that Indie games regularly provide.
You forget the fact that you paid a max of 23 euro's (don't know the dollar price) for this game. With steam sales all around x-mas I guess the avarage player probably spent more like 15 euro's.
Besides that you did read the system requirements didn't you? Every game takes these and a minimum is like what? 10-20 fps?
<b>System Requirements</b>
<i>Minimum:</i>
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->OS:Windows 7 32/64-bit / Vista 32/64 / XP
Processor:Core 2 Duo 2.6 ghz
Memory:2 GB RAM
Graphics:DirectX 9 compatible video card with 1GB, ATI X800, NVidia 8600 or better
DirectX®:9.0
Hard Drive:5 GB HD space<!--QuoteEnd--></div><!--QuoteEEnd-->
Compare these to op:
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->2.0ghz quadcore CPU,
4650 HD Radeon 2gb vram,
4gb ram<!--QuoteEnd--></div><!--QuoteEEnd-->
I wonder what's causing his low fps....
If your lunning low fps your hardware is probably not good enough for the sparks enginge's leetness. Do not take complainments to unknown worlds but rather to your own lack of being able to read the system requirements.
I still think this is a poor excuse. A "D-" is still a "D-" and getting an "F" prior doesn't magically make the "D-" desirable. If I shouldn't expect an Indie Studio to put out a AAA-level game, then UWE shouldn't have attempted to in the first place. As it happens my gripe is not that it can't perform well next to those titles, it's that it tried to in the first place and fell flat. The one thing I expect from <i>every game</i> is for it to run properly and not hitch - perform on a different stage and expect the audience to judge against those that came before you. I only ever make exception when a game is deliberately pushing the frontiers of science to make a point (and only for single-player). Needless to say, NS2 is a world apart from that standard.
I respect the difficulty of creating a title like NS2 for a small team such as UWE but I wish, perhaps, they had feared it!
@Mindstorm
For the record, I pre-purchased NS2 when the requirements were laughably lower than that and so did many others. To reiterate for your other point, however much money I spend on a game, I still expect it to run well.
There are many factors with regards to perceived slowness however and I still believe that a major proponent of that is the infestation network causing network traffic bottlenecks. Each cyst currently is comprised of 7 entities, all which need to be propagated between the client/server. I would still personally like to see a good client side infestation model developed that requires no additional entities.
So while performance will increase a little bit now and then, any major performance increases will require complex and time-consuming re-architecting, and its doubtful that you can make a case for that compared to adding more content/features.
Do note that because the rendering thread is run in a parallel thread, decreasing the amount of stuff rendered will not normally affect your fps (unless you have a really old graphics card) unless your fps is really high OR you are running around in areas full of models/particles. Usually, the bottleneck is in the game logic part.
You can use either the "profile" console command to do online profiling, or "p_logall" and the perfanalyzer.py program to do offline profiling.<!--QuoteEnd--></div><!--QuoteEEnd-->
If this is the case would they not be spending more time trying to open the game up for more cores assuming that it is so hard to make it run any better than it does now? Given too that the game has so many loops running every frame I would logically think that removing them in place of event triggers would dramatically improve server performance.
Yea, that's what I had in mind when I wrote "complex and time-consuming re-architecting". There are some pretty straightforward optimizations possible when it comes to multi-threading, but they require capabilities that are not part of the standard Lua VMs, and it would also require a partial rewrite of the ns2 lua code.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Given too that the game has so many loops running every frame I would logically think that removing them in place of event triggers would dramatically improve server performance.<!--QuoteEnd--></div><!--QuoteEEnd-->
I used to think so to. But for games like NS2, event based coding is just to complex, fragile and costly - timed checks turns out to be much easier to code and understand, and there is no clear case for it being significantly slower.
If you check the profiler, OnUpdate() for the various classes is not a dominant cost (any longer; costly OnUpdate() fixes belongs to the class of "easy" optimizations that has already been done). The real cost is processing moves and updating physics/animations, which are mostly in C++.
4650 HD Radeon 2gb vram,
4gb ram
It's a pretty old comp, but I don't see how my specs are relevant since I can play modern games, and I should ideally be able to play NS2 very smoothly.<!--QuoteEnd--></div><!--QuoteEEnd-->
I'm really curious as to what modern games are playable under your specs. I think you're bull sht. your computer is ridiculously under the requirements on the ns2 website. buy a new computer, end of thread.
Don't need to be an ass, maybe he purchased the game when this was displayed in the buy page.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->What are the system requirements?
The target specifications for Version 1.0 are 1.2 GHz Processor, 256MB RAM, a DirectX 9 level graphics card, Windows Vista/2000/XP, Steam, mouse, keyboard and of course, an internet connection. We are working hard to make sure NS2 runs well on average hardware without having to upgrade your machine!<!--QuoteEnd--></div><!--QuoteEEnd-->
sure, good point, but his video card was released in 2008-09-10. that video card is now 5 years old. hes being completely ignorant or just a cheap ass that doesnt want to spend money on a new computer and wants to complain.
If he bought it under the 1.0 version listed requirements, he isn't being ignorant. To be frank the real requirements should be more like
Minimum (30-60fps)
3.0Ghz Quadcore
nvidia 600 series
ati 6000 series
4GB RAM
7200 RPM HD
Recommended would be i5 or higher, 8gb ram, SSD, etc etc etc
Guess what though, if they told people their game required a minimum 1500 dollar investment to play well, they would've tanked. (I consider 60 fps poor, so you may disagree that 30 fps plays poorly)