<!--quoteo(post=1987727:date=Oct 5 2012, 08:52 PM:name=Sling_Blade)--><div class='quotetop'>QUOTE (Sling_Blade @ Oct 5 2012, 08:52 PM) <a href="index.php?act=findpost&pid=1987727"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->What I am seeing is so different than what you guys are seeing it is hard to understand. I see fairly consistent usage of all 4 cores of my i7 920 (hyperthreading is off, overclocked to 3.8Ghz). It certainly isn't 100% used but it certainly isn't 1 core pegged and the rest doing nothing.<!--QuoteEnd--></div><!--QuoteEEnd-->
The cores toss around NS2's single thread amongst themselves like a hot potato
As others have said, the game runs mostly on a single thread, i know that spectate mode is run on a separate thread
i could test, some time ago, that ns2 uses up to 3 cores, sometimes a little of the 4th.
Tested with an old beta (around version 200), I could gain ~20 fps per core. 1C=~22/23 fps 2C=~40 fPS 3C=~60 fps with 4 cores was like 63 fps.
That standing in the marine start.
With 221, as other stated, i had some frames drops in heavy load situations and i've noted that now it only uses 2 cores and a little in normal situations
What i think is: 1) server side has increased in performance, that makes more work for the clients 2) I don't know anything about programming and multithreading but i think that there is probably a primary thread going on a core and the others related to this one on the others. now if the first core is more busy because of problem number 1 we have the issue that the other cores are less effective, waiting for the primary thread to be calculated before they can do something. And that may explain why now i can't fill 3 cores at full as it used to be in 220 and <
<!--quoteo(post=1987141:date=Oct 4 2012, 07:43 PM:name=HeatSurge)--><div class='quotetop'>QUOTE (HeatSurge @ Oct 4 2012, 07:43 PM) <a href="index.php?act=findpost&pid=1987141"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You're not playing with 1-5 FPS. You're occupying a slot.<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo(post=1987533:date=Oct 5 2012, 11:07 AM:name=NeoRussia)--><div class='quotetop'>QUOTE (NeoRussia @ Oct 5 2012, 11:07 AM) <a href="index.php?act=findpost&pid=1987533"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I heard that the game is locked below some monitors' refresh rates at 100fps or so, is this true? I've never been able to get that much even on the main menu to test it, but if it is, don't see why it should be unless it's for technical reasons? 100-120fps makes a nice difference against fast-moving skulks and screen movement.<!--QuoteEnd--></div><!--QuoteEEnd--> this deserves some attention, especially with the rising popularity of 120hz monitors. it's quite frustrating being capped and not being able to take advantage of your monitor's potential. additionally, the game runs poorly for just about everyone - even those with amazing computers are not able to hold a steady framerate.
<!--quoteo(post=1987533:date=Oct 5 2012, 07:07 PM:name=NeoRussia)--><div class='quotetop'>QUOTE (NeoRussia @ Oct 5 2012, 07:07 PM) <a href="index.php?act=findpost&pid=1987533"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I heard that the game is locked below some monitors' refresh rates at 100fps or so, is this true? I've never been able to get that much even on the main menu to test it, but if it is, don't see why it should be unless it's for technical reasons? 100-120fps makes a nice difference against fast-moving skulks and screen movement.<!--QuoteEnd--></div><!--QuoteEEnd-->
I think you are referring to a change in some 19x build, they capped the FPS limit on the client side because the game uses client side FPS to calculate the speed of certain player actions based on the client FPS (at least that's what i got out of the explanation)
Imho one of the worst patches ever, before that i had constant 100+ FPS (and awesome movement xD), since than performance feels randomly all over the place because it's so dependent on server tick rates.
It's just another way to "balance" poor performance.. instead of pulling everybody up to "good performance" you just nerf down performance of good setups until they run as crappy as slow setups, in the end everybody will have crappy performance and it's "balanced".
<!--quoteo(post=1988778:date=Oct 9 2012, 06:27 AM:name=Cico)--><div class='quotetop'>QUOTE (Cico @ Oct 9 2012, 06:27 AM) <a href="index.php?act=findpost&pid=1988778"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->2) I don't know anything about programming and multithreading<!--QuoteEnd--></div><!--QuoteEEnd-->
This is exactly why you shouldn't make any statements regarding it... Threads and cores are NOT the same thing. Picture the core as like the base of a factory where things are coming out, and the thread as a conveyor belt. When you add another thread (2 per core) you get a second conveyor belt. So you have faster speed out of the factory, but the things are still being built at the same speed. If you have a loop running in the program it's locking up that core until it's done or it yields. Now if you have 2 cores, now you can have 2 different loops running.
With that being said, programs don't magically use multiple cores. They have to be specifically programmed to do so. A simple for loop in programming such as, for (n = 0; n < 5; n++) which basically says start at 0 and do whatever is in this loop then add 1 and continue until n = 5. Is changed into Parallel.For (n = 0; n < 5; n++), which simply tells the program to run that specific loop on a core other than the one it's parent loop is contained in. If it sounds confusing, it's cause it kind of is. It's only actually advantageous when you have loops within loops, which in games is very common. I'd do a whole example but it's really beyond the scope.
Suffice to say, the game is not optimized to actually use multiple cores to actually process the game. Hopefully this will be done before the release date and everyone will see a roughly 30% performance gain. 30% is about the average gain noticed once a program is optimized to use more than one core.
DghelneshiAims to surpass Fana in post edits.Join Date: 2011-11-01Member: 130634Members, Squad Five Blue, Reinforced - Shadow
edited October 2012
@Davil: Isn't the problem that Lua is the biggest bottleneck and inside one Lua VM you cannot create multiple threads (as far as I understand the matter)? Or is it somehow possible to multithread in Lua?
<!--quoteo(post=1989832:date=Oct 11 2012, 11:25 AM:name=Dghelneshi)--><div class='quotetop'>QUOTE (Dghelneshi @ Oct 11 2012, 11:25 AM) <a href="index.php?act=findpost&pid=1989832"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->@Davil: Isn't the problem that Lua is the biggest bottleneck and inside one Lua VM you cannot create multiple threads (as far as I understand the matter)? Or is it somehow possible to multithread in Lua?<!--QuoteEnd--></div><!--QuoteEEnd-->
The game is coded in Lua script? Yuck... Well there isn't really any use of multicore or multithread processing then. Lua can do concurrent processes but the performance gain isn't nearly the same. There has been some advances toward true parallelism in the language though. What I'm hoping is if this game is coded with Lua it uses C++ or C# through dll's or headers that could actually make use of multithreading. Otherwise...
(quick edit) Just to clarify, there are some extensions for Lua that do something similar to parallel processing but it's all just concurrent processing so not the same performance gain.
<!--quoteo(post=1989734:date=Oct 11 2012, 06:54 PM:name=Spektor56)--><div class='quotetop'>QUOTE (Spektor56 @ Oct 11 2012, 06:54 PM) <a href="index.php?act=findpost&pid=1989734"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Getting 100fps with core i5 3570k and a radeon 3870, approximately 80fps in combat<!--QuoteEnd--></div><!--QuoteEEnd-->
Wow seems like your 3570k is alot better than mine 3570@4,5Ghz. Seriously I even drop to 40 fps sometimes when there are more than 2 aliens around me.
<!--quoteo(post=1989892:date=Oct 11 2012, 05:38 PM:name=Davil)--><div class='quotetop'>QUOTE (Davil @ Oct 11 2012, 05:38 PM) <a href="index.php?act=findpost&pid=1989892"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The game is coded in Lua script? Yuck... Well there isn't really any use of multicore or multithread processing then. Lua can do concurrent processes but the performance gain isn't nearly the same. There has been some advances toward true parallelism in the language though. What I'm hoping is if this game is coded with Lua it uses C++ or C# through dll's or headers that could actually make use of multithreading. Otherwise...
(quick edit) Just to clarify, there are some extensions for Lua that do something similar to parallel processing but it's all just concurrent processing so not the same performance gain.<!--QuoteEnd--></div><!--QuoteEEnd-->
The issue is not so much language features, but that the game objects and logic have to be architected in a particular way to take advantage or parallel processing. Each game frame involves a lot of calculations that all make use of the results of other calculations, unless you build from the ground up intending to be multithreaded there isn't much work that can easily be farmed out to other threads. There was a good discussion about this a while ago, start <a href="http://www.unknownworlds.com/ns2/forums/index.php?showtopic=120514&view=findpost&p=1969575" target="_blank">here</a>.
<!--quoteo(post=1989918:date=Oct 11 2012, 02:56 PM:name=shader)--><div class='quotetop'>QUOTE (shader @ Oct 11 2012, 02:56 PM) <a href="index.php?act=findpost&pid=1989918"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The issue is not so much language features, but that the game objects and logic have to be architected in a particular way to take advantage or parallel processing. Each game frame involves a lot of calculations that all make use of the results of other calculations, unless you build from the ground up intending to be multithreaded there isn't much work that can easily be farmed out to other threads. There was a good discussion about this a while ago, start <a href="http://www.unknownworlds.com/ns2/forums/index.php?showtopic=120514&view=findpost&p=1969575" target="_blank">here</a>.<!--QuoteEnd--></div><!--QuoteEEnd-->
No Lua DOES NOT support multithreading unless you use some sort of C extension, which is what they do with this. Lua has (like I said) concurrency which is similar but much different. Concurrent processing allows for co-routines which are more or less just loops that don't lock up the system while they run, a 'while' loop for example in c++ locks up the system until it completes. And the way you guys were talking about it in that thread, it seemed more like blind conjecture than actual experience talking. For example, you wouldn't want something that's so simple to process as player input to be in it's own thread. Really things break down into much larger chunks, not individual functions running in their own special thread. The most amount of threads you will have is 8, and 4 cores to actually do the work, so it's not possible. Scheduling is actually what the process is called to decide what core will do what and when. As for how things are actually divided, like I said before, it's mostly loops that are within loops. I haven't seen the source code for this so I wouldn't know where to start. There are a lot of multithreading documents available for programmers and aspiring programmers available on Intel's website which I'd recommend checking out if you are so inclined.
<!--quoteo(post=1989933:date=Oct 11 2012, 03:25 PM:name=NurEinMensch)--><div class='quotetop'>QUOTE (NurEinMensch @ Oct 11 2012, 03:25 PM) <a href="index.php?act=findpost&pid=1989933"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The engine is written in C++. The game logic is in lua.<!--QuoteEnd--></div><!--QuoteEEnd-->
Yea that makes perfect sense to me. Lua, like most scripting languages, excels at runtime execution. So I can see why they'd use it for things like weapons and other objects to make it easier to change things at runtime.
<!--quoteo(post=1990088:date=Oct 11 2012, 11:23 PM:name=Davil)--><div class='quotetop'>QUOTE (Davil @ Oct 11 2012, 11:23 PM) <a href="index.php?act=findpost&pid=1990088"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->No Lua DOES NOT support multithreading unless you use some sort of C extension ...<!--QuoteEnd--></div><!--QuoteEEnd-->
I wasn't arguing that Lua supports multithreading internally, I was saying that even if it did it wouldn't currently help. i.e. the bulk of the gameplay code is single threaded not because it is in a language that doesn't support multithreading, but because the lua game objects and their interactions weren't designed from the start with multithreading in mind.
This is an issue because the game is mainly CPU bound, and a lot of that CPU time is being spent on the lua gameplay code. People continually raise multithreading as a possible solution to provide more performance. The thread I linked to has some discussion from one of the games coders about one way an architecture change could allow some of that gameplay code to take advantage of multiple threads.
<!--quoteo(post=1990122:date=Oct 11 2012, 09:48 PM:name=shader)--><div class='quotetop'>QUOTE (shader @ Oct 11 2012, 09:48 PM) <a href="index.php?act=findpost&pid=1990122"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I wasn't arguing that Lua supports multithreading internally, I was saying that even if it did it wouldn't currently help. i.e. the bulk of the gameplay code is single threaded not because it is in a language that doesn't support multithreading, but because the lua game objects and their interactions weren't designed from the start with multithreading in mind.
This is an issue because the game is mainly CPU bound, and a lot of that CPU time is being spent on the lua gameplay code. People continually raise multithreading as a possible solution to provide more performance. The thread I linked to has some discussion from one of the games coders about one way an architecture change could allow some of that gameplay code to take advantage of multiple threads.<!--QuoteEnd--></div><!--QuoteEEnd-->
Oh yea, I know I completely agree. But yea Lua will never have true parallelism, it's just a downfall of the language and it's developers for some reason think it's the way to go. Luckily since it's mostly just the game objects it should work out great because those don't really make much of a difference. This last build was a good step forward for optimization.
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
The way to introduce MT to Spark is to run multiple Lua VMs, each in their separate thread, and then merge/distribute the state between the VMs. Doable but difficult as it would invalidate some of the conventions that the NS2 code is using.
<!--quoteo(post=1988744:date=Oct 9 2012, 05:33 AM:name=terrorizer)--><div class='quotetop'>QUOTE (terrorizer @ Oct 9 2012, 05:33 AM) <a href="index.php?act=findpost&pid=1988744"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->AMD Phenom 1055T @ 3500mhz, Radeon 7850 OC, 16gb ram. All settings LOW, textures - high. No AA. Perfomance is about 50-60fps in readyroom, ingame is about 40-45, when fight it drops to 20-30, so i cannot aim. I feel that begin love this game, but perfomance still bad for me.
I think changing processor to i7 3770 will give about 30% additional perfomance. But i beleive there will be more optimisations.<!--QuoteEnd--></div><!--QuoteEEnd-->
That's depressing. I have Phenom 1055t (no OC), 6GB DDR2 800 CL4 RAM, Radeon 7770 GPU. I could run even Witcher 2 with some tweaks (no aa, ubersampling) at acceptable framerates with very good graphics quality. If you get 20-30 FPS with 3.5Ghz overclock, then I'd get 15-20 FPS with stock values (2.8Ghz). Wow.
I've been waiting for this game for a long time and have already pre-ordered it on Steam, but I kinda regret that decision now. Even if they could deliver 30% performance improvement, I'll get 20-30 FPS max during combat, well below my 45FPS playability limit.
I've got some thinking to do about this preorder :/
<!--quoteo(post=1990294:date=Oct 12 2012, 06:03 AM:name=Uruktos)--><div class='quotetop'>QUOTE (Uruktos @ Oct 12 2012, 06:03 AM) <a href="index.php?act=findpost&pid=1990294"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->That's depressing. I have Phenom 1055t (no OC), 6GB DDR2 800 CL4 RAM, Radeon 7770 GPU. I could run even Witcher 2 with some tweaks (no aa, ubersampling) at acceptable framerates with very good graphics quality. If you get 20-30 FPS with 3.5Ghz overclock, then I'd get 15-20 FPS with stock values (2.8Ghz). Wow.
I've been waiting for this game for a long time and have already pre-ordered it on Steam, but I kinda regret that decision now. Even if they could deliver 30% performance improvement, I'll get 20-30 FPS max during combat, well below my 45FPS playability limit.
I've got some thinking to do about this preorder :/<!--QuoteEnd--></div><!--QuoteEEnd-->
Wow how old are you and your 45fps playability limit. When CS 1.5 was around most ppl got 20-30fps and thought that was GOOD. I can still function in game (poorly) at 15-20fps. If you are hitting 20-30fps in a giant battle and above 30 in small fights then the game will be easily playable. 30fps is the speed of analog cable television, does that look laggy to you.
May sound strange, but If they implemented a per object motion blur. The game would at least look more presentable at lower frame rates and help in its playability. The frame rate would not look jarring when low
<!--quoteo(post=1990298:date=Oct 12 2012, 04:11 PM:name=statikg)--><div class='quotetop'>QUOTE (statikg @ Oct 12 2012, 04:11 PM) <a href="index.php?act=findpost&pid=1990298"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Wow how old are you and your 45fps playability limit. When CS 1.5 was around most ppl got 20-30fps and thought that was GOOD. I can still function in game (poorly) at 15-20fps. If you are hitting 20-30fps in a giant battle and above 30 in small fights then the game will be easily playable. 30fps is the speed of analog cable television, does that look laggy to you.<!--QuoteEnd--></div><!--QuoteEEnd--> He is right. 25/30 ips is the rate of television, but you don't control the camera directly with your gestures. Here you are directly in the game and directly controlling your virtual character throught your mouse, so it need to be really really responsive. Every time it's below a certain high framerate, it reminds you it's not real and totally break the immersion and can frustrate you a lot, because it does not feel responsive. Moreover, pause your television and look at the picture, it's all blurred out right? Try that on NS2... This is why a lot of people, and especially for competitive play, need at least 50-60 FPS at <b>minimum</b>.
I can actually "play" with 30 fps actually on NS2, but it's just because I was "playing" at 5 fps before all the optimization was done, and it's absolutely not pleasant. Also for a lot of games, more than 100 FPS is a lot better than 50 FPS. It can bring other advantages among other players too.
30fps is playable but there is a pretty big difference between 30 and 60. Google it and you'll find a pretty good example of this with a bouncing square.
<!--quoteo(post=1990298:date=Oct 12 2012, 07:11 AM:name=statikg)--><div class='quotetop'>QUOTE (statikg @ Oct 12 2012, 07:11 AM) <a href="index.php?act=findpost&pid=1990298"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Wow how old are you and your 45fps playability limit. When CS 1.5 was around most ppl got 20-30fps and thought that was GOOD. I can still function in game (poorly) at 15-20fps. If you are hitting 20-30fps in a giant battle and above 30 in small fights then the game will be easily playable. 30fps is the speed of analog cable television, does that look laggy to you.<!--QuoteEnd--></div><!--QuoteEEnd-->
When I was playing CS 6.2, I was getting 50FPS+ with 640x480 resolution during combat. Not to mention Counter Strike itself is a game about angles rather than fast paced combat (ala Quake).
20 to 30 FPS is only playable to those who don't know the difference between that and 60FPS, or in a game with huge amounts of motion blur (Crysis). 45FPS and up improves your aiming ability so much, you'd have to be really trying not to see the difference when you compare them side by side.
Movies run at 24FPS because they have giant, huge, humongous amount of motion blur. Video games can't do this properly yet. Even if they did, 60FPS would still be 10 times better because motion blur doesn't get rid of input delay.
Our hardware nowadays is fast. Even mid level computers like mine can pretty much run all games at appropriate resolutions at max details (Witcher 2 is exception here). A game should really be able to run at 60FPS during combat. If it can't, it better have some mind blowing graphics that should make Crysis look like children drawings.
FYI, there's a very noticable difference between 60FPS and 120FPS too. It's not as drastic as the difference between 30-60, but it's there.
222 has big improvements. I tested aroudn 30 fps with infestation and about 15 players fighting together, EXOS shooting, and gorges biling. It's starting to become kind of playable during intense fights. :D Things to consider. I updated to Nvidia 306.97 drivers, and the server i tested on now has a 20 player limit instead of 24. I play on 1680x1050 with everything low/off except multicore rendering.
<!--quoteo(post=1990685:date=Oct 13 2012, 04:34 AM:name=senate)--><div class='quotetop'>QUOTE (senate @ Oct 13 2012, 04:34 AM) <a href="index.php?act=findpost&pid=1990685"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->222 has big improvements. I tested aroudn 30 fps with infestation and about 15 players fighting together, EXOS shooting, and gorges biling. It's starting to become kind of playable during intense fights. :D Things to consider. I updated to Nvidia 306.97 drivers, and the server i tested on now has a 20 player limit instead of 24. I play on 1680x1050 with everything low/off except multicore rendering.<!--QuoteEnd--></div><!--QuoteEEnd-->
More performance boosts are on their way too. :) Coming faster now than ever before.
<!--quoteo(post=1990929:date=Oct 13 2012, 06:50 PM:name=Obraxis)--><div class='quotetop'>QUOTE (Obraxis @ Oct 13 2012, 06:50 PM) <a href="index.php?act=findpost&pid=1990929"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->More performance boosts are on their way too. :) Coming faster now than ever before.<!--QuoteEnd--></div><!--QuoteEEnd-->
Comments
The cores toss around NS2's single thread amongst themselves like a hot potato
As others have said, the game runs mostly on a single thread, i know that spectate mode is run on a separate thread
Tested with an old beta (around version 200), I could gain ~20 fps per core.
1C=~22/23 fps
2C=~40 fPS
3C=~60 fps
with 4 cores was like 63 fps.
That standing in the marine start.
With 221, as other stated, i had some frames drops in heavy load situations and i've noted that now it only uses 2 cores and a little in normal situations
What i think is: 1) server side has increased in performance, that makes more work for the clients
2) I don't know anything about programming and multithreading but i think that there is probably a primary thread going on a core and the others related to this one on the others. now if the first core is more busy because of problem number 1 we have the issue that the other cores are less effective, waiting for the primary thread to be calculated before they can do something.
And that may explain why now i can't fill 3 cores at full as it used to be in 220 and <
loooooooooool
this deserves some attention, especially with the rising popularity of 120hz monitors. it's quite frustrating being capped and not being able to take advantage of your monitor's potential.
additionally, the game runs poorly for just about everyone - even those with amazing computers are not able to hold a steady framerate.
OCT 31 YOLO
I think you are referring to a change in some 19x build, they capped the FPS limit on the client side because the game uses client side FPS to calculate the speed of certain player actions based on the client FPS (at least that's what i got out of the explanation)
Imho one of the worst patches ever, before that i had constant 100+ FPS (and awesome movement xD), since than performance feels randomly all over the place because it's so dependent on server tick rates.
It's just another way to "balance" poor performance.. instead of pulling everybody up to "good performance" you just nerf down performance of good setups until they run as crappy as slow setups, in the end everybody will have crappy performance and it's "balanced".
I5 760 (2.80 ghz)
Ati Radeon HD 5770 1gb DDr 5
4 Gb DDr 3
1 Tb Seagate Barracuda Hd
All video options : Low with Vertical Sync Double Buffered 1600 x 900
25/30 With players
40 In an Empty Server
This game needs to be less heavy, other games with wonderful graphics runs good the problem is not our pc :\
This is exactly why you shouldn't make any statements regarding it... Threads and cores are NOT the same thing. Picture the core as like the base of a factory where things are coming out, and the thread as a conveyor belt. When you add another thread (2 per core) you get a second conveyor belt. So you have faster speed out of the factory, but the things are still being built at the same speed. If you have a loop running in the program it's locking up that core until it's done or it yields. Now if you have 2 cores, now you can have 2 different loops running.
With that being said, programs don't magically use multiple cores. They have to be specifically programmed to do so. A simple for loop in programming such as, for (n = 0; n < 5; n++) which basically says start at 0 and do whatever is in this loop then add 1 and continue until n = 5. Is changed into Parallel.For (n = 0; n < 5; n++), which simply tells the program to run that specific loop on a core other than the one it's parent loop is contained in. If it sounds confusing, it's cause it kind of is. It's only actually advantageous when you have loops within loops, which in games is very common. I'd do a whole example but it's really beyond the scope.
Suffice to say, the game is not optimized to actually use multiple cores to actually process the game. Hopefully this will be done before the release date and everyone will see a roughly 30% performance gain. 30% is about the average gain noticed once a program is optimized to use more than one core.
The game is coded in Lua script? Yuck... Well there isn't really any use of multicore or multithread processing then. Lua can do concurrent processes but the performance gain isn't nearly the same. There has been some advances toward true parallelism in the language though. What I'm hoping is if this game is coded with Lua it uses C++ or C# through dll's or headers that could actually make use of multithreading. Otherwise...
(quick edit) Just to clarify, there are some extensions for Lua that do something similar to parallel processing but it's all just concurrent processing so not the same performance gain.
Wow seems like your 3570k is alot better than mine 3570@4,5Ghz. Seriously I even drop to 40 fps sometimes when there are more than 2 aliens around me.
(quick edit) Just to clarify, there are some extensions for Lua that do something similar to parallel processing but it's all just concurrent processing so not the same performance gain.<!--QuoteEnd--></div><!--QuoteEEnd-->
The issue is not so much language features, but that the game objects and logic have to be architected in a particular way to take advantage or parallel processing. Each game frame involves a lot of calculations that all make use of the results of other calculations, unless you build from the ground up intending to be multithreaded there isn't much work that can easily be farmed out to other threads. There was a good discussion about this a while ago, start <a href="http://www.unknownworlds.com/ns2/forums/index.php?showtopic=120514&view=findpost&p=1969575" target="_blank">here</a>.
No Lua DOES NOT support multithreading unless you use some sort of C extension, which is what they do with this. Lua has (like I said) concurrency which is similar but much different. Concurrent processing allows for co-routines which are more or less just loops that don't lock up the system while they run, a 'while' loop for example in c++ locks up the system until it completes. And the way you guys were talking about it in that thread, it seemed more like blind conjecture than actual experience talking. For example, you wouldn't want something that's so simple to process as player input to be in it's own thread. Really things break down into much larger chunks, not individual functions running in their own special thread. The most amount of threads you will have is 8, and 4 cores to actually do the work, so it's not possible. Scheduling is actually what the process is called to decide what core will do what and when. As for how things are actually divided, like I said before, it's mostly loops that are within loops. I haven't seen the source code for this so I wouldn't know where to start. There are a lot of multithreading documents available for programmers and aspiring programmers available on Intel's website which I'd recommend checking out if you are so inclined.
<!--quoteo(post=1989933:date=Oct 11 2012, 03:25 PM:name=NurEinMensch)--><div class='quotetop'>QUOTE (NurEinMensch @ Oct 11 2012, 03:25 PM) <a href="index.php?act=findpost&pid=1989933"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The engine is written in C++. The game logic is in lua.<!--QuoteEnd--></div><!--QuoteEEnd-->
Yea that makes perfect sense to me. Lua, like most scripting languages, excels at runtime execution. So I can see why they'd use it for things like weapons and other objects to make it easier to change things at runtime.
I wasn't arguing that Lua supports multithreading internally, I was saying that even if it did it wouldn't currently help. i.e. the bulk of the gameplay code is single threaded not because it is in a language that doesn't support multithreading, but because the lua game objects and their interactions weren't designed from the start with multithreading in mind.
This is an issue because the game is mainly CPU bound, and a lot of that CPU time is being spent on the lua gameplay code. People continually raise multithreading as a possible solution to provide more performance. The thread I linked to has some discussion from one of the games coders about one way an architecture change could allow some of that gameplay code to take advantage of multiple threads.
This is an issue because the game is mainly CPU bound, and a lot of that CPU time is being spent on the lua gameplay code. People continually raise multithreading as a possible solution to provide more performance. The thread I linked to has some discussion from one of the games coders about one way an architecture change could allow some of that gameplay code to take advantage of multiple threads.<!--QuoteEnd--></div><!--QuoteEEnd-->
Oh yea, I know I completely agree. But yea Lua will never have true parallelism, it's just a downfall of the language and it's developers for some reason think it's the way to go. Luckily since it's mostly just the game objects it should work out great because those don't really make much of a difference. This last build was a good step forward for optimization.
All settings LOW, textures - high. No AA.
Perfomance is about 50-60fps in readyroom, ingame is about 40-45, when fight it drops to 20-30, so i cannot aim.
I feel that begin love this game, but perfomance still bad for me.
I think changing processor to i7 3770 will give about 30% additional perfomance. But i beleive there will be more optimisations.<!--QuoteEnd--></div><!--QuoteEEnd-->
That's depressing. I have Phenom 1055t (no OC), 6GB DDR2 800 CL4 RAM, Radeon 7770 GPU. I could run even Witcher 2 with some tweaks (no aa, ubersampling) at acceptable framerates with very good graphics quality. If you get 20-30 FPS with 3.5Ghz overclock, then I'd get 15-20 FPS with stock values (2.8Ghz). Wow.
I've been waiting for this game for a long time and have already pre-ordered it on Steam, but I kinda regret that decision now. Even if they could deliver 30% performance improvement, I'll get 20-30 FPS max during combat, well below my 45FPS playability limit.
I've got some thinking to do about this preorder :/
I've been waiting for this game for a long time and have already pre-ordered it on Steam, but I kinda regret that decision now. Even if they could deliver 30% performance improvement, I'll get 20-30 FPS max during combat, well below my 45FPS playability limit.
I've got some thinking to do about this preorder :/<!--QuoteEnd--></div><!--QuoteEEnd-->
Wow how old are you and your 45fps playability limit. When CS 1.5 was around most ppl got 20-30fps and thought that was GOOD. I can still function in game (poorly) at 15-20fps. If you are hitting 20-30fps in a giant battle and above 30 in small fights then the game will be easily playable. 30fps is the speed of analog cable television, does that look laggy to you.
He is right.
25/30 ips is the rate of television, but you don't control the camera directly with your gestures. Here you are directly in the game and directly controlling your virtual character throught your mouse, so it need to be really really responsive. Every time it's below a certain high framerate, it reminds you it's not real and totally break the immersion and can frustrate you a lot, because it does not feel responsive.
Moreover, pause your television and look at the picture, it's all blurred out right? Try that on NS2...
This is why a lot of people, and especially for competitive play, need at least 50-60 FPS at <b>minimum</b>.
I can actually "play" with 30 fps actually on NS2, but it's just because I was "playing" at 5 fps before all the optimization was done, and it's absolutely not pleasant.
Also for a lot of games, more than 100 FPS is a lot better than 50 FPS. It can bring other advantages among other players too.
When I was playing CS 6.2, I was getting 50FPS+ with 640x480 resolution during combat. Not to mention Counter Strike itself is a game about angles rather than fast paced combat (ala Quake).
20 to 30 FPS is only playable to those who don't know the difference between that and 60FPS, or in a game with huge amounts of motion blur (Crysis). 45FPS and up improves your aiming ability so much, you'd have to be really trying not to see the difference when you compare them side by side.
Movies run at 24FPS because they have giant, huge, humongous amount of motion blur. Video games can't do this properly yet. Even if they did, 60FPS would still be 10 times better because motion blur doesn't get rid of input delay.
Our hardware nowadays is fast. Even mid level computers like mine can pretty much run all games at appropriate resolutions at max details (Witcher 2 is exception here). A game should really be able to run at 60FPS during combat. If it can't, it better have some mind blowing graphics that should make Crysis look like children drawings.
FYI, there's a very noticable difference between 60FPS and 120FPS too. It's not as drastic as the difference between 30-60, but it's there.
More performance boosts are on their way too. :) Coming faster now than ever before.
Yes please i (we) beg you more fps ! :o
October 31st is a seriously bad idea. The game is not ready. Even on top hardware configuration the game runs extremely poorly.
Release too early and you'll kill the game: /