But what about the openGL/DX11 things, what exactly does this do? (besides openGL possibly making it playable or mac or linux or something?) and dx11? No complaints as I'm running a card with dx11 though
The primary reason this is being done right now is to be able to port the game over to other platforms, like MAC and Linux. However, we are also hoping there will be some additional performance boost on the GPU side as well, though exactly how much is unknown at the moment. Between this and the LuaJITstuff that is being worked on, which will help out on the CPU side, there should be noticeable performance improvements coming.
This whole post sounds fantastic, hope it works out
Yes. I most definitely agree!
As, I have played NS1 since CY2006 and have been running an NS1 server ever since. I would really LOVE to play NS2, but my only caveat is I want to do it fully on a Linux-native build. Wine does not count. Sorry, I am tired of Microsoft's and Apple's corporate attitude and I really love the community spirit in the Linux world. Ahhhh, so refreshing...!
Speaking of which, I plan to fully shut down my NS1 server coming soon. Since even though it runs on Linux, I know only Windows machines can connect to it. For the longest while I didn't think of it much, as I wasn't fully tired of Microsoft/Apple yet, but I am putting my sights on making Linux a true gaming environment. Steam is already there (along with MANY quality games). Hopefully NS2 will join next. And while I'm on this subject: Why not release NS1 under an Open Source license or something? Unknown Worlds doesn't even have to do any further development beyond that. I'm sure some creative hackers would put some effort to port NS1 to Linux. Half-Life 1 already runs great on Linux... But the NS1 client-side DLLs and the like (and the source code to all of that) is what is holding things up.
But what about the openGL/DX11 things, what exactly does this do? (besides openGL possibly making it playable or mac or linux or something?) and dx11? No complaints as I'm running a card with dx11 though
The primary reason this is being done right now is to be able to port the game over to other platforms, like MAC and Linux. However, we are also hoping there will be some additional performance boost on the GPU side as well, though exactly how much is unknown at the moment. Between this and the LuaJITstuff that is being worked on, which will help out on the CPU side, there should be noticeable performance improvements coming.
This whole post sounds fantastic, hope it works out
Yes. I most definitely agree!
As, I have played NS1 since CY2006 and have been running an NS1 server ever since. I would really LOVE to play NS2, but my only caveat is I want to do it fully on a Linux-native build. Wine does not count. Sorry, I am tired of Microsoft's and Apple's corporate attitude and I really love the community spirit in the Linux world. Ahhhh, so refreshing...!
Speaking of which, I plan to fully shut down my NS1 server coming soon. Since even though it runs on Linux, I know only Windows machines can connect to it. For the longest while I didn't think of it much, as I wasn't fully tired of Microsoft/Apple yet, but I am putting my sights on making Linux a true gaming environment. Steam is already there (along with MANY quality games). Hopefully NS2 will join next. And while I'm on this subject: Why not release NS1 under an Open Source license or something? Unknown Worlds doesn't even have to do any further development beyond that. I'm sure some creative hackers would put some effort to port NS1 to Linux. Half-Life 1 already runs great on Linux... But the NS1 client-side DLLs and the like (and the source code to all of that) is what is holding things up.
--William
May i add:
With all due respect having players on Linux or MAC will never be the core player base. Yes i think it's ok to have this on linux, but the core CPU problem stays.
We are slowly passing from an era of "you have to buy a stronger graphical card to get there" to "you have to buy a new computer". That starts to be a little annoying to hear the same arguments all the time while coders should be a little bit more caring about optimization. The more power you have in computer the weaker the code becomes.
Most of high level languages are portable between platforms. Some are faster than others.
Better code runs on more computer = more players = good.
Well, according to steam the majority of users has 2.3 Ghz to 2.69 Ghz ... so the majority can't really enjoy NS2. Sad. I really looove NS2, it's such a great game. But i can't get ANYONE of my friends get to play it.....cuz of the performance. Most of them didn't even have the patience to wait for the loading screen to finish ....
A multiplayer game needs to be fast. Loading, ingame performance.
NS2 has such a low player count ... it truely has some great esports potential.
I wonder if Spark is using LUAJIT or if UWE is at least planning to experiment with it. LUAJIT, in addition to JITting code (as opposed to interpreting, which is slower), also enables you to use fibers (kind of lightweight "threads") which might help increase performance on multi-core CPUs depending on how well they're used.
I'd like to hear from UWE about that.
And since you seem to be fairly technically minded, the major challenge we face with LuaJIT is the Lua->C++ API. For LuaJIT to be performant, you have to architect that API in some pretty specific ways, otherwise you will always break the JIT compiles and get almost no benefit from it. Completely changing the API is not an attractive option (rewrite a lot of code..break all the mods..), so we're currently investigating ways of avoiding this.
Ah, I see. Thanks for the responses and insight! Hopefully you can find a way around these issues.
Would in-VM multithreading buy you that much vs. using multiple-VMs? Isn't the hard part making the game logic multithreadable in the first place, i.e. separating out the parts that can run asynchronously from each other?
I believe the biggest advantage for in-VM multithreading would be related to data sharing. In-VM MT means all VM threads can access the same data set, while with multiple VMs you have to duplicate and synchronize data between them. That results in less memory usage and less time spent copying/synchronizing data == more CPU time available for the logic itself. And with proper concurrent programming, you can achieve pretty large performance boosts.
But MT won't help you much when most of the time is spent interpreting the code. The CPU works better when it speaks its own language, which is what LuaJIT does.
When they say a cpu can make like 300 million (billion?) decisions a second does that mean it can check that many true/false things a second? like a 100101 w/e
If so I don't think anything utilizes the computer to its maximum properly, cause that sounds like a lot of power. I remember just fooling around with a game that didn't properly support more than 2 cores? Setting it to 4 threads or 8 threads increased framerates by like 600 and it wasn't even working properly
Is LuaJIT something that must be implemented game wide or can it be used in certain critical pathways? I have a basic coding understanding but not enough to really know this off hand.
I think luaJIT splits the workload, so one part of the game goes through luaJIT, then another part goes through regular lua.. so making the work more evenly split on the cores already supported
or I'm an idiot and you can just disregard what I said because it's a complete guess
Not quite. In very simple terms, LuaJIT translates Lua code into a format that your CPU can read more quickly. It does this just before the code segment is actually executed, hence the name (Just In Time).
Is LuaJIT something that must be implemented game wide or can it be used in certain critical pathways? I have a basic coding understanding but not enough to really know this off hand.
I think luaJIT splits the workload, so one part of the game goes through luaJIT, then another part goes through regular lua.. so making the work more evenly split on the cores already supported
or I'm an idiot and you can just disregard what I said because it's a complete guess
Not quite. In very simple terms, LuaJIT translates Lua code into a format that your CPU can read more quickly. It does this just before the code segment is actually executed, hence the name (Just In Time).
IronHorseDeveloper, QA Manager, Technical Support & contributorJoin Date: 2010-05-08Member: 71669Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Subnautica Playtester, Subnautica PT Lead, Pistachionauts
Its a great workflow for development if the results are even near what a compiled language can do - because it means you can write in an easy to read/write high level language like LUA and yet it wouldn't have nearly as bad of downsides as typical scripting/realtime languages, more closely mimicking a compiled language - sort of like a hybrid between the two extremes in the programming language spectrum. At least that's how i understand it.
I found this a while back and got excited, thinking UWE could program easier and faster with LUA, and yet when it came time to make the build / publish a patch, it could be converted to faster C.
All of the benefits with none of the downsides? Hehe, almost, it ended up being too good to be true i guess :-P
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
Is LuaJIT something that must be implemented game wide or can it be used in certain critical pathways? I have a basic coding understanding but not enough to really know this off hand.
I think luaJIT splits the workload, so one part of the game goes through luaJIT, then another part goes through regular lua.. so making the work more evenly split on the cores already supported
or I'm an idiot and you can just disregard what I said because it's a complete guess
Not quite. In very simple terms, LuaJIT translates Lua code into a format that your CPU can read more quickly. It does this just before the code segment is actually executed, hence the name (Just In Time).
thanks for the interesting information and article, I read the whole thing and have no idea what's even going on anymore! But I feel educated, man I deserve a drink
I believe the biggest advantage for in-VM multithreading would be related to data sharing. In-VM MT means all VM threads can access the same data set, while with multiple VMs you have to duplicate and synchronize data between them. That results in less memory usage and less time spent copying/synchronizing data == more CPU time available for the logic itself. And with proper concurrent programming, you can achieve pretty large performance boosts.
The "Lua Way" seems very much to be: if you need it, make your own implementation. For example: Lua doesn't have objects... it has a clever metadata mechanism which allows you to create your own object system, and consequently there are literally a dozen different implementations of OOP in Lua.
Same thing with multithreading. People have created several different ways to do something-like-multithreading using Lua, and each one has different properties and trade-offs. See here for example.
In all honesty, UWE probably doesn't really need multithreading. They just need some way to offload more functionality into separate "things" such that the "things" can be spread across multiple cores. Threads would do that, but so would processes. Architecturally, it's a lot easier to keep things manageable (and thus bug-free) if you have a handful of discreet things with cleanly separated environments and clear and explicit channels to communicate and/or share data. The multiple-VM approach would do that, and they wouldn't have to wait for better single-VM threading support.
Yes, with multiple VMs you have to deal with the overhead of IPC and data sharing... but a really solid design would minimize the amount of IPC and sharing that's needed and keep it constrained to a well-understood and well-behaved set of data. And to handle that IPC and sharing, UWE would be well-served to write their own plumbing in C++. Since they'd have a good idea of what kind of data needs to be shared and what kinds of processes it needs to be shared between, they could write something that was super-efficient at it. It would be a piece of cake for each separate Lua process to plug into it; Lua is good at making use of C interfaces.
The end result wouldn't be multithreading, exactly, and it wouldn't be as flexible as a general-purpose multithreading solution native to Lua. But it would be even more efficient than that at the specific task it was designed for, and it would be a lot simpler to design and maintain. And it would split the load up among multiple cores... and that's the big performance win right there.
But regardless, switching to LuaJIT is probably the best use of their time at the moment. That could be a big win for everyone, soon.
While I sort of get but don't get at all what you're saying, what kind of performance benefits are we talking about here? (Cause I know just going from 2 cores to 4 cores it's over 300+ frames added to your current framerate, depending on clock speeds, and probably the game engine)
and for future reference, technically speaking won't people with 4-8+ cores gain performance as the years go on? Because then developers will begin to use more of the cores, cause I hear majority games only really use 2 cores and nothing more
Alright, I haven't read the whole thread, I'm just reacting to OP's statement saying no one can have constant >60 fps. Well I do, and I don't have the best PC around either. Performances are a great problem for NS2, I agree there though. I used to get 20 FPS @ 800*600 on my old PC, while now it's ~90 @ 1080p.
Alright, I haven't read the whole thread, I'm just reacting to OP's statement saying no one can have constant >60 fps. Well I do, and I don't have the best PC around either. Performances are a great problem for NS2, I agree there though. I used to get 20 FPS @ 800*600 on my old PC, while now it's ~90 @ 1080p.
Can you please post the specs of your mystical PC. Im sure everyone here want to know what to buy to get constant >60 fps.
Btw, im running NS2 on an i5-2500k@4,4 ghz, gtx670, SSD, enough RAM.
I have tried EVERYTHING to get stable FPS:
- Every possible ingame graphic setting in all possible variations
- Fresh windows install
- Im using a processtamer to boost the foward NS2-Process to high priority and lower the priority of backroundprocesses
- Install the latest drivers of all components
- I create an own NS2- Nvidia profile with all settings to low
- I disabled all no needed services
- Networktraffic shaping
What should i say:
In Endgame it goes down to 35FP sometimes. An these 35 fps feels like horrible 10-15 fps.
Everyone i ask describes the same endgame issues.
This thread should not transform into an technical one wich would be in the wrong forum.
But sorry ezay, i dont believe that you get >60fps in an heavy endgame fight.
I have faith in the devs, its just frustrating to see all these updates with a bunch of changes to maps, balance, etc when the performance issue is #1 on the list of problems people complain about. Every patch I get excited that there may have been a performance increase, then, nope just moved a bunch of vents around on maps again. Seems like wasted effort from a dumb users perspective.
I have faith in the devs, its just frustrating to see all these updates with a bunch of changes to maps, balance, etc when the performance issue is #1 on the list of problems people complain about. Every patch I get excited that there may have been a performance increase, then, nope just moved a bunch of vents around on maps again. Seems like wasted effort from a dumb users perspective.
Gotta remember every one at UWE has their area of expertise. No sense in the mappers not attempting to create and balancing their maps while others work on other issues.
Alright, I haven't read the whole thread, I'm just reacting to OP's statement saying no one can have constant >60 fps. Well I do, and I don't have the best PC around either. Performances are a great problem for NS2, I agree there though. I used to get 20 FPS @ 800*600 on my old PC, while now it's ~90 @ 1080p.
Can you please post the specs of your mystical PC. Im sure everyone here want to know what to buy to get constant >60 fps.
Btw, im running NS2 on an i5-2500k@4,4 ghz, gtx670, SSD, enough RAM.
I have tried EVERYTHING to get stable FPS:
- Every possible ingame graphic setting in all possible variations
- Fresh windows install
- Im using a processtamer to boost the foward NS2-Process to high priority and lower the priority of backroundprocesses
- Install the latest drivers of all components
- I create an own NS2- Nvidia profile with all settings to low
- I disabled all no needed services
- Networktraffic shaping
What should i say:
In Endgame it goes down to 35FP sometimes. An these 35 fps feels like horrible 10-15 fps.
Everyone i ask describes the same endgame issues.
This thread should not transform into an technical one wich would be in the wrong forum.
But sorry ezay, i dont believe that you get >60fps in an heavy endgame fight.
It's strange you get such low fps.
Here's what I just upgraded to, and it's not that impressive. I get 100-200 fps in ready room or at start of game. At the worst I get 70 fps towards end game with all entities.
i5 3770k at stock speed (not overclocked) 3.4 gHz.
660 gtx (not the ti) video card
solid state Hard Drive
8gb RAM at 2133 MHz
I use a program called process lasso ( bitsum.com/processlasso/ ) . I use this program to isolate EVERY running process on my PC to core 0 (I have 4 cores). Then I put any game I am playing to core 1, 2, and 3. This allows the game nearly complete access to 3 cores only for its own processing, which cuts down on a shit ton of caching that has to take place when a core switches processes thousands of times a second. It wont need to switch processes much if at all, making all the caching that has to happen only related to NS2.
Also, I never play on servers with more than 20 players. These overload most servers and cause poor server performance, which a lot of the time translates into poor client performance. Not to mention the imbalances that exist on >20 man servers.
Btw, im running NS2 on an i5-2500k@4,4 ghz, gtx670, SSD, enough RAM.
[...]
What should i say:
In Endgame it goes down to 35FP sometimes. An these 35 fps feels like horrible 10-15 fps.
How many players were in the server? If you're playing on a 24+ player server then yes, fps will go down badly.
I never get frame rates that low on comp matches. The game runs perfectly fine on 6v6, never below 60 fps, even in end-game, even while streaming. Running on an i7-2600K @ 4.5GHz, GTX 680. That's not to say it needs optimization, because I should be getting 120+ fps all the time on a 6v6 match.
dePARAJoin Date: 2011-04-29Member: 96321Members, Squad Five Blue
edited May 2013
Comp matches are played 6v6 on nsl-maps. These maps are opimized for max performance cause they have less ligtning. So, thats not a really argument. Im talking about "normal" games on an 18 slot server.
And im talking about the fact, that everything under 50fps feels like 10-15 fps in NS2. I never head this bad gaming experience in any game i played before.
I used to play UT2004 on a Pentium III 500 MHz. That game required a P3 733 minimum. Ran it at like 20 fps avg, and I still beat lots of people to a pulp, even though it felt really laggy.
I do lose some of my aiming accuracy when NS2 runs at 40 fps when I'm playing on a full 24 player combat server, but it's not as bad as you're saying. 40 fps feels like 40 fps for me, probably because I'm already used to playing at 20 fps, and for some reason I'm lucky not to have any kind of input lag issues.
I agree that 40 fps on such a beast of a machine should not happen.
Comp matches are played 6v6 on nsl-maps. These maps are opimized for max performance cause they have less ligtning. So, thats not a really argument. Im talking about "normal" games on an 18 slot server.
And im talking about the fact, that everything under 50fps feels like 10-15 fps in NS2. I never head this bad gaming experience in any game i played before.
Just try it: Open console and type maxfps 40.
That command is known to not do what people think it would. I makes FPS feel FAR worse then when you artificially limit it. Getting a true 60fps in game is far better then typing fpsmax 60 in consol.
Comments
Yes. I most definitely agree!
As, I have played NS1 since CY2006 and have been running an NS1 server ever since. I would really LOVE to play NS2, but my only caveat is I want to do it fully on a Linux-native build. Wine does not count. Sorry, I am tired of Microsoft's and Apple's corporate attitude and I really love the community spirit in the Linux world. Ahhhh, so refreshing...!
Speaking of which, I plan to fully shut down my NS1 server coming soon. Since even though it runs on Linux, I know only Windows machines can connect to it. For the longest while I didn't think of it much, as I wasn't fully tired of Microsoft/Apple yet, but I am putting my sights on making Linux a true gaming environment. Steam is already there (along with MANY quality games). Hopefully NS2 will join next. And while I'm on this subject: Why not release NS1 under an Open Source license or something? Unknown Worlds doesn't even have to do any further development beyond that. I'm sure some creative hackers would put some effort to port NS1 to Linux. Half-Life 1 already runs great on Linux... But the NS1 client-side DLLs and the like (and the source code to all of that) is what is holding things up.
--William
May i add:
With all due respect having players on Linux or MAC will never be the core player base. Yes i think it's ok to have this on linux, but the core CPU problem stays.
We are slowly passing from an era of "you have to buy a stronger graphical card to get there" to "you have to buy a new computer". That starts to be a little annoying to hear the same arguments all the time while coders should be a little bit more caring about optimization. The more power you have in computer the weaker the code becomes.
Most of high level languages are portable between platforms. Some are faster than others.
Better code runs on more computer = more players = good.
A multiplayer game needs to be fast. Loading, ingame performance.
NS2 has such a low player count ... it truely has some great esports potential.
Ah, I see. Thanks for the responses and insight! Hopefully you can find a way around these issues.
I believe the biggest advantage for in-VM multithreading would be related to data sharing. In-VM MT means all VM threads can access the same data set, while with multiple VMs you have to duplicate and synchronize data between them. That results in less memory usage and less time spent copying/synchronizing data == more CPU time available for the logic itself. And with proper concurrent programming, you can achieve pretty large performance boosts.
But MT won't help you much when most of the time is spent interpreting the code. The CPU works better when it speaks its own language, which is what LuaJIT does.
If so I don't think anything utilizes the computer to its maximum properly, cause that sounds like a lot of power. I remember just fooling around with a game that didn't properly support more than 2 cores? Setting it to 4 threads or 8 threads increased framerates by like 600 and it wasn't even working properly
Not quite. In very simple terms, LuaJIT translates Lua code into a format that your CPU can read more quickly. It does this just before the code segment is actually executed, hence the name (Just In Time).
Like what a browser does with JavaScript
I found this a while back and got excited, thinking UWE could program easier and faster with LUA, and yet when it came time to make the build / publish a patch, it could be converted to faster C.
All of the benefits with none of the downsides? Hehe, almost, it ended up being too good to be true i guess :-P
Turns out that Wikepedia has a very nice article how a tracing JIT compiler like LuaJIT actually works ... https://en.wikipedia.org/wiki/Tracing_just-in-time_compilation
Same thing with multithreading. People have created several different ways to do something-like-multithreading using Lua, and each one has different properties and trade-offs. See here for example.
In all honesty, UWE probably doesn't really need multithreading. They just need some way to offload more functionality into separate "things" such that the "things" can be spread across multiple cores. Threads would do that, but so would processes. Architecturally, it's a lot easier to keep things manageable (and thus bug-free) if you have a handful of discreet things with cleanly separated environments and clear and explicit channels to communicate and/or share data. The multiple-VM approach would do that, and they wouldn't have to wait for better single-VM threading support.
Yes, with multiple VMs you have to deal with the overhead of IPC and data sharing... but a really solid design would minimize the amount of IPC and sharing that's needed and keep it constrained to a well-understood and well-behaved set of data. And to handle that IPC and sharing, UWE would be well-served to write their own plumbing in C++. Since they'd have a good idea of what kind of data needs to be shared and what kinds of processes it needs to be shared between, they could write something that was super-efficient at it. It would be a piece of cake for each separate Lua process to plug into it; Lua is good at making use of C interfaces.
The end result wouldn't be multithreading, exactly, and it wouldn't be as flexible as a general-purpose multithreading solution native to Lua. But it would be even more efficient than that at the specific task it was designed for, and it would be a lot simpler to design and maintain. And it would split the load up among multiple cores... and that's the big performance win right there.
But regardless, switching to LuaJIT is probably the best use of their time at the moment. That could be a big win for everyone, soon.
and for future reference, technically speaking won't people with 4-8+ cores gain performance as the years go on? Because then developers will begin to use more of the cores, cause I hear majority games only really use 2 cores and nothing more
Is it just me or are the smiley faces appearing about the size of a pin head on the forums?
Can you please post the specs of your mystical PC. Im sure everyone here want to know what to buy to get constant >60 fps.
Btw, im running NS2 on an i5-2500k@4,4 ghz, gtx670, SSD, enough RAM.
I have tried EVERYTHING to get stable FPS:
- Every possible ingame graphic setting in all possible variations
- Fresh windows install
- Im using a processtamer to boost the foward NS2-Process to high priority and lower the priority of backroundprocesses
- Install the latest drivers of all components
- I create an own NS2- Nvidia profile with all settings to low
- I disabled all no needed services
- Networktraffic shaping
What should i say:
In Endgame it goes down to 35FP sometimes. An these 35 fps feels like horrible 10-15 fps.
Everyone i ask describes the same endgame issues.
This thread should not transform into an technical one wich would be in the wrong forum.
But sorry ezay, i dont believe that you get >60fps in an heavy endgame fight.
Mind sharing what settings you personally have on high?
Gotta remember every one at UWE has their area of expertise. No sense in the mappers not attempting to create and balancing their maps while others work on other issues.
It's strange you get such low fps.
Here's what I just upgraded to, and it's not that impressive. I get 100-200 fps in ready room or at start of game. At the worst I get 70 fps towards end game with all entities.
i5 3770k at stock speed (not overclocked) 3.4 gHz.
660 gtx (not the ti) video card
solid state Hard Drive
8gb RAM at 2133 MHz
I use a program called process lasso ( bitsum.com/processlasso/ ) . I use this program to isolate EVERY running process on my PC to core 0 (I have 4 cores). Then I put any game I am playing to core 1, 2, and 3. This allows the game nearly complete access to 3 cores only for its own processing, which cuts down on a shit ton of caching that has to take place when a core switches processes thousands of times a second. It wont need to switch processes much if at all, making all the caching that has to happen only related to NS2.
Also, I never play on servers with more than 20 players. These overload most servers and cause poor server performance, which a lot of the time translates into poor client performance. Not to mention the imbalances that exist on >20 man servers.
How many players were in the server? If you're playing on a 24+ player server then yes, fps will go down badly.
I never get frame rates that low on comp matches. The game runs perfectly fine on 6v6, never below 60 fps, even in end-game, even while streaming. Running on an i7-2600K @ 4.5GHz, GTX 680. That's not to say it needs optimization, because I should be getting 120+ fps all the time on a 6v6 match.
And im talking about the fact, that everything under 50fps feels like 10-15 fps in NS2. I never head this bad gaming experience in any game i played before.
Just try it: Open console and type maxfps 40.
I do lose some of my aiming accuracy when NS2 runs at 40 fps when I'm playing on a full 24 player combat server, but it's not as bad as you're saying. 40 fps feels like 40 fps for me, probably because I'm already used to playing at 20 fps, and for some reason I'm lucky not to have any kind of input lag issues.
I agree that 40 fps on such a beast of a machine should not happen.
FTFY.
That command is known to not do what people think it would. I makes FPS feel FAR worse then when you artificially limit it. Getting a true 60fps in game is far better then typing fpsmax 60 in consol.