<!--quoteo(post=1925863:date=Apr 16 2012, 08:41 AM:name=_Necro_)--><div class='quotetop'>QUOTE (_Necro_ @ Apr 16 2012, 08:41 AM) <a href="index.php?act=findpost&pid=1925863"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->[*]Are there tools to automatically translate LUA code into C++? If so, this should be made for every beta-release. Adding a flag or param for modders, which tells the engine to use the lua files instead of the translated C++ code.<!--QuoteEnd--></div><!--QuoteEEnd--> Heh, people keep asking for this, but if you knew Lua and C++ you'd know that, while having similarities, there are parts of the design that would be radically differently implemented in C++. You can't ask a converter to do that. There are some 'converters' out there that take a bite of basic Lua and output a C++-variant with C-API calls, but that is not what you want, nor would it work on a shipping-product like NS2. It's more of a curiosity really.
You can rewrite the serverside-scripts in C++. It's not complicated, but very time-consuming. Furthermore you would want a proper Engine-API as well, because as soon as you need to interact with the engine, you'd have to fall back on the Lua-API which would ruin the performance-improvements. Additionally, doing this now would be kinda moot, as the game isn't completed yet, so you're trying to hit a moving target.
A doubling of performance for the client would bring it's performance into the acceptable-range (although JUST, prepare for a rage-fest upon release), but only if the server can sustain a very good tickrate, as you know the client's performance depends a lot on the server. A doubling of server-performance though would be wholly insufficient. A move to LuaJIT was shot down by Max with good reason I'm sure, but even if things were JITd I'm not sure performance would be up to scratch. At this point I'm really taken by the idea of a C++ rewrite of the server-scripts, though it may fall on the community to do so.
What UWE can do now is expose that Engine-API so that, upon the right animo, the (C++) community can go ahead and make this happen. It would also be nice for server-side modders that are starving for performance (eg. me). Per example, to make the gamestate-recorder happen I need to read out many networked-variables continuously, this is an expensive process. However, the engine already does this too (in order to transmit this data to relevant clients), so I'm basically doing repeat (expensive) work, while the data is already there sitting in the engine (I can see parts of the API, which makes it all the more aggravating I have to go the long route and read it from Lua). If this was exposed though a C++-API I could just pick up the data at (almost) no cost.
So yeah, a (native) engine(& server)-SDK would be good addition to multiple domains of the community.
And what would keep UWE from releasing the engine-API or the C++ source for the server to the community? We can all imagine the benefits of that but since they are not doing it there must be a big problem with it that I can't think of right now. Or is something along these lines planned for a later point in time already?
I actually see positive feedback on this topic. Not the case in-game i can assure you.
When combat gets heavy or too many cysts are dopped performance takes a poop. FPS drops can go well below 30 in most cases and I myself am on an i5 with 16gb RAM and a Geforce 460 GTX and can run BF3 with near high settings.
Granted the game has been said to run more single threaded. Honestly, I don't know what that means exactly. But considering in todays tech world we have multithreaded processors, I would imagine that you guys can on the dev team can take more advantage of that fact.
We ARE still in beta, sure. But if you plan on releasing this in summer, you're behind schedule. Considering you still have features to implement, balance issues to be addressed (overkill Lerk, etc.) and probably some more models to improve (as far as I know, just the Mine model. I'm over the nostalgia of the NS1 version. I'm ready to move on. :) )
If your team were larger I'd say you can pull off the Summer release. As it stands I'm not holding my breath. I also realize that I'm no expert in the world of game developement and that I could very well be wrong. I'm basing my statements on how complex the process is and how much effort and sacrifice it takes to make something great. (I'm a musician. I've sacrificed plenty so I can relate on that fact.)
One thing I am certain of though is that this game will be fantastic once it reaches it's archetype and gone gold. The graphics are spectacular. The gameplay is intense and highly addicting. NS1 has a large cult following and I'm quite sure this game will have a much larger one.
But in the Summer...well, we'll just have to see now won't we.
<!--quoteo(post=1925987:date=Apr 16 2012, 08:42 PM:name=cron)--><div class='quotetop'>QUOTE (cron @ Apr 16 2012, 08:42 PM) <a href="index.php?act=findpost&pid=1925987"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->And what would keep UWE from releasing the engine-API or the C++ source for the server to the community? We can all imagine the benefits of that but since they are not doing it there must be a big problem with it that I can't think of right now. Or is something along these lines planned for a later point in time already?<!--QuoteEnd--></div><!--QuoteEEnd--> Well, I guess some effort to isolated the relevant declarations, include some rudimentary documention, and package it with each release. I can see why they haven't done it (yet). Maybe they didn't expect anyone to mod so close to the metal, after all, you can count the number of mods to feature C-API interaction on one hand.
But Max himself said in a video interview that he learned a lot of what he now knows from the open source code of Id Tech 3, I always assumed they would release as much of the code as possible and make it as accessible as possible; the server for example. Not trying to create pressure here, that's just the perspective I had so far and based on what has been said in this thread I'm beginning to have doubts. Kinda hoping for a comment from the devs here.
<!--quoteo(post=1925944:date=Apr 16 2012, 12:13 PM:name=Insane)--><div class='quotetop'>QUOTE (Insane @ Apr 16 2012, 12:13 PM) <a href="index.php?act=findpost&pid=1925944"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->All of our game programmers are talented and experienced.<!--QuoteEnd--></div><!--QuoteEEnd-->
That was just me implying that real programmers don't use scripting languages. Just a hyperbole. I really do not like dynamic typing. Let the compiler catch the bugs I say.
I also said you guys should stick to the guns and not move code into C++ code (like Far Cry), because that would negate the benefits you get from having the scripts (clear interface, easier moddable, you can probably change the code at runtime?).
<!--quoteo(post=1926118:date=Apr 17 2012, 01:56 AM:name=tobias3)--><div class='quotetop'>QUOTE (tobias3 @ Apr 17 2012, 01:56 AM) <a href="index.php?act=findpost&pid=1926118"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->That was just me implying that real programmers don't use scripting languages.<!--QuoteEnd--></div><!--QuoteEEnd-->
Real programmers work with the tools they're given. Real good programmers make miracles happen with the tools they're given.
<!--quoteo(post=1925990:date=Apr 16 2012, 09:00 PM:name=MetalGarret)--><div class='quotetop'>QUOTE (MetalGarret @ Apr 16 2012, 09:00 PM) <a href="index.php?act=findpost&pid=1925990"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->We ARE still in beta, sure. But if you plan on releasing this in summer, you're behind schedule. Considering you still have features to implement, balance issues to be addressed (overkill Lerk, etc.) and probably some more models to improve (as far as I know, just the Mine model. I'm over the nostalgia of the NS1 version. I'm ready to move on. :) )<!--QuoteEnd--></div><!--QuoteEEnd--> With all due respect, you really can't say we are behind schedule if you haven't seen our schedule :) There is a lot going on behind the scenes, many features that have been almost completed, but just not released yet, due to inadequate testing, or just requiring the final polish pass on them. For example, you give the example of a new mine model, which has already been concepted and modeled and is now in the process of being textured, so not very far from completion.
We wouldn't have set a Summer release date if we weren't confident we could hit it, as we are obviously a bit sensitive on the subject of release dates after the whole fall 2009 thing.
<!--quoteo(post=1926175:date=Apr 16 2012, 11:37 PM:name=Squeal_Like_A_Pig)--><div class='quotetop'>QUOTE (Squeal_Like_A_Pig @ Apr 16 2012, 11:37 PM) <a href="index.php?act=findpost&pid=1926175"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->We wouldn't have set a Summer release date if we weren't confident we could hit it, as we are obviously a bit sensitive on the subject of release dates after the whole fall 2009 thing.
--Cory<!--QuoteEnd--></div><!--QuoteEEnd-->
for what it's worth, you'll never beat Valve in that department.
PlasmaJoin Date: 2003-04-26Member: 15855Members, Constellation, Squad Five Blue
<!--quoteo(post=1925720:date=Apr 16 2012, 07:22 AM:name=tobias3)--><div class='quotetop'>QUOTE (tobias3 @ Apr 16 2012, 07:22 AM) <a href="index.php?act=findpost&pid=1925720"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The fallacy of the scripting lanuage: 1. Engine programmer decides that the main engine language (C++) is to complicated for the people who make the game. He integrates a simple scripting engine for "non-programmers". 2. Non-programmers write unmaintanable and inefficient code because they have not much experience. 3. Whole thing blows up.<!--QuoteEnd--></div><!--QuoteEEnd-->
I'm an experienced programmer (7 years in various languages), just for some context.
I think using a scripting language like Lua for game code is a good idea - it's far easier to rapidly prototype and build the game using the scripting language, as opposed to C++.
There are various spots of optimization going forward:
1) Lua game logic (eg, optimizing the logical flow of the code - like the hydra optimization).
For the record, it would be slow in C++ if the logical code was the same as well (but not as slow).
2) Putting more upfront effort in optimizing the Lua runtime (which Max is working on I believe?) sounds like a much better win in terms of performance (and on-going game development) than porting code to C++.
<!--quoteo(post=1926303:date=Apr 17 2012, 03:27 AM:name=Plasma)--><div class='quotetop'>QUOTE (Plasma @ Apr 17 2012, 03:27 AM) <a href="index.php?act=findpost&pid=1926303"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I think using a scripting language like Lua for game code is a good idea - it's far easier to rapidly prototype and build the game using the scripting language, as opposed to C++.<!--QuoteEnd--></div><!--QuoteEEnd-->
I think that argument goes either way. There are advantages and disadvantages to weight. You certainly have to know where to use which tools. After all there must be a reason most games are written in C++. But it is a personal choice and as long as it works out I don't care.
<!--quoteo(post=1926175:date=Apr 16 2012, 09:37 PM:name=Squeal_Like_A_Pig)--><div class='quotetop'>QUOTE (Squeal_Like_A_Pig @ Apr 16 2012, 09:37 PM) <a href="index.php?act=findpost&pid=1926175"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->We wouldn't have set a Summer release date if we weren't confident we could hit it, as we are obviously a bit sensitive on the subject of release dates after the whole fall 2009 thing. --Cory<!--QuoteEnd--></div><!--QuoteEEnd-->
I want this to succeed and I am invested, but please don't lie to me. I can see the state of the game and it is nowhere near a beta stage yet alone "release". I don't know if releasing something unfinished and naming it final is a good move. (As a reminder: beta stage is when things stabilize. <a href="http://www.unknownworlds.com/ns2/news/2012/4/alien_commander_v2_0" target="_blank">http://www.unknownworlds.com/ns2/news/2012..._commander_v2_0</a> shows that you are not stabilizing.)
<!--quoteo(post=1926175:date=Apr 17 2012, 03:37 AM:name=Squeal_Like_A_Pig)--><div class='quotetop'>QUOTE (Squeal_Like_A_Pig @ Apr 17 2012, 03:37 AM) <a href="index.php?act=findpost&pid=1926175"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->With all due respect, you really can't say we are behind schedule if you haven't seen our schedule :) There is a lot going on behind the scenes, many features that have been almost completed, but just not released yet, due to inadequate testing, or just requiring the final polish pass on them. For example, you give the example of a new mine model, which has already been concepted and modeled and is now in the process of being textured, so not very far from completion.
We wouldn't have set a Summer release date if we weren't confident we could hit it, as we are obviously a bit sensitive on the subject of release dates after the whole fall 2009 thing.
--Cory<!--QuoteEnd--></div><!--QuoteEEnd-->
Would it be too cheeky to beg for some concept art? For some reason I'm really interested to see how you've worked your re-interpretation magic on the mine, specifically.
God, that's a weird thing to be interested in. I think it's because I've been so impressed with all the other NS1->NS2 transitions that I kind of wonder what you can possibly do with a wee square of metal.
<!--quoteo(post=1926175:date=Apr 16 2012, 08:37 PM:name=Squeal_Like_A_Pig)--><div class='quotetop'>QUOTE (Squeal_Like_A_Pig @ Apr 16 2012, 08:37 PM) <a href="index.php?act=findpost&pid=1926175"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->With all due respect, you really can't say we are behind schedule if you haven't seen our schedule :) There is a lot going on behind the scenes, many features that have been almost completed, but just not released yet, due to inadequate testing, or just requiring the final polish pass on them. For example, you give the example of a new mine model, which has already been concepted and modeled and is now in the process of being textured, so not very far from completion.
We wouldn't have set a Summer release date if we weren't confident we could hit it, as we are obviously a bit sensitive on the subject of release dates after the whole fall 2009 thing.
--Cory<!--QuoteEnd--></div><!--QuoteEEnd-->
Relax. That wasn't a "come at me bro" moment. :) I understand you're working tirelessly to get the job done and I/we respect that. And who are we to say what's what? True.
But I did say "We'll see." And perhaps we shall. If this game ships during summer time I'll tuck my tail between my legs and play.
<!--quoteo(post=1926130:date=Apr 17 2012, 03:38 AM:name=Scrogneugneu)--><div class='quotetop'>QUOTE (Scrogneugneu @ Apr 17 2012, 03:38 AM) <a href="index.php?act=findpost&pid=1926130"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Real programmers work with the tools they're given. Real good programmers make miracles happen with the tools they're given.<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo(post=1926312:date=Apr 17 2012, 10:41 AM:name=MuYeah)--><div class='quotetop'>QUOTE (MuYeah @ Apr 17 2012, 10:41 AM) <a href="index.php?act=findpost&pid=1926312"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Would it be too cheeky to beg for some concept art? For some reason I'm really interested to see how you've worked your re-interpretation magic on the mine, specifically.
God, that's a weird thing to be interested in. I think it's because I've been so impressed with all the other NS1->NS2 transitions that I kind of wonder what you can possibly do with a wee square of metal.<!--QuoteEnd--></div><!--QuoteEEnd--> Ok, I'm kind of derailing the thread here, so I apologize. But here's the mine concept.
[attachment=36081:Mines_LowRes.jpg]
Back to your regularly scheduled performance discussion.
Well, this is nice to read and certainly good to know tha they work on the lua part, but:
- Threading is not even mentioned? What is being done about it?
With modern cpus striving for more cores in addition to more processing power per core (in general at least), it only seems natural to focus on multi-threading aswell. According to the steam hw survey, 50% have a dual core system, while 40% have a quad core system. I am postive the trend will continue torwards multicore cpus, so making more effienct use of the CPU would help to address the issue aswell. This is especailly true if I assume the scaleability to be high; if ns2 would run in threads with roughly even distribution of load, I'd get more then double the frame rate (ingoreing posible GPU limit). Bunch of processors also support hyper threading; with decent multi-threading support it would also yield an improvement.
- Moving lua to c++ code?
Of course you mention that moddability is important, but performance increases would be nice to have though. In some cases it still may make sense I guess, though I see gettingf some design conflict (eg engine unspecific code (ns 2 code) in spark). I'd guess it will be avoided, but some word on that aswell?
<!--quoteo(post=1926864:date=Apr 18 2012, 06:36 PM:name=mechanicalDR)--><div class='quotetop'>QUOTE (mechanicalDR @ Apr 18 2012, 06:36 PM) <a href="index.php?act=findpost&pid=1926864"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Long as you don't pull an RO2 I'm happy.<!--QuoteEnd--></div><!--QuoteEEnd-->
lol o man. UWE, if you need to delay the game again, keep doing it. If the community says it's not ready, please believe them. Being in the RO2 beta, all of us kept petitioning for the game to not be released yet and what happens? bad reviews, people left in droves.. it was a disaster area.
<!--quoteo(post=1926781:date=Apr 18 2012, 06:18 PM:name=Omega_K2)--><div class='quotetop'>QUOTE (Omega_K2 @ Apr 18 2012, 06:18 PM) <a href="index.php?act=findpost&pid=1926781"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->- Threading is not even mentioned? What is being done about it?
With modern cpus striving for more cores in addition to more processing power per core (in general at least), it only seems natural to focus on multi-threading aswell. According to the steam hw survey, 50% have a dual core system, while 40% have a quad core system. I am postive the trend will continue torwards multicore cpus, so making more effienct use of the CPU would help to address the issue aswell. This is especailly true if I assume the scaleability to be high; if ns2 would run in threads with roughly even distribution of load, I'd get more then double the frame rate (ingoreing posible GPU limit).<!--QuoteEnd--></div><!--QuoteEEnd-->
You can thread physics, AI, input, all of which is handled by the engine and written in C++ with great efficiency. Game logic however is very hard to solve in parallel threads as usually all is within one loop and depends on itself sequentially. Also, you can not just "make something threaded", usually only small parts of the code are candidate for multi threading and with that also the amount of efficiency that can be gained throughout the entire program. See Amdahl's law for an accurate description of that phenomenon.
Comments
Heh, people keep asking for this, but if you knew Lua and C++ you'd know that, while having similarities, there are parts of the design that would be radically differently implemented in C++. You can't ask a converter to do that. There are some 'converters' out there that take a bite of basic Lua and output a C++-variant with C-API calls, but that is not what you want, nor would it work on a shipping-product like NS2. It's more of a curiosity really.
You can rewrite the serverside-scripts in C++. It's not complicated, but very time-consuming. Furthermore you would want a proper Engine-API as well, because as soon as you need to interact with the engine, you'd have to fall back on the Lua-API which would ruin the performance-improvements. Additionally, doing this now would be kinda moot, as the game isn't completed yet, so you're trying to hit a moving target.
A doubling of performance for the client would bring it's performance into the acceptable-range (although JUST, prepare for a rage-fest upon release), but only if the server can sustain a very good tickrate, as you know the client's performance depends a lot on the server. A doubling of server-performance though would be wholly insufficient. A move to LuaJIT was shot down by Max with good reason I'm sure, but even if things were JITd I'm not sure performance would be up to scratch. At this point I'm really taken by the idea of a C++ rewrite of the server-scripts, though it may fall on the community to do so.
What UWE can do now is expose that Engine-API so that, upon the right animo, the (C++) community can go ahead and make this happen. It would also be nice for server-side modders that are starving for performance (eg. me). Per example, to make the gamestate-recorder happen I need to read out many networked-variables continuously, this is an expensive process. However, the engine already does this too (in order to transmit this data to relevant clients), so I'm basically doing repeat (expensive) work, while the data is already there sitting in the engine (I can see parts of the API, which makes it all the more aggravating I have to go the long route and read it from Lua). If this was exposed though a C++-API I could just pick up the data at (almost) no cost.
So yeah, a (native) engine(& server)-SDK would be good addition to multiple domains of the community.
We can all imagine the benefits of that but since they are not doing it there must be a big problem with it that I can't think of right now. Or is something along these lines planned for a later point in time already?
When combat gets heavy or too many cysts are dopped performance takes a poop. FPS drops can go well below 30 in most cases and I myself am on an i5 with 16gb RAM and a Geforce 460 GTX and can run BF3 with near high settings.
Granted the game has been said to run more single threaded. Honestly, I don't know what that means exactly. But considering in todays tech world we have multithreaded processors, I would imagine that you guys can on the dev team can take more advantage of that fact.
We ARE still in beta, sure. But if you plan on releasing this in summer, you're behind schedule. Considering you still have features to implement, balance issues to be addressed (overkill Lerk, etc.) and probably some more models to improve (as far as I know, just the Mine model. I'm over the nostalgia of the NS1 version. I'm ready to move on. :) )
If your team were larger I'd say you can pull off the Summer release. As it stands I'm not holding my breath. I also realize that I'm no expert in the world of game developement and that I could very well be wrong. I'm basing my statements on how complex the process is and how much effort and sacrifice it takes to make something great. (I'm a musician. I've sacrificed plenty so I can relate on that fact.)
One thing I am certain of though is that this game will be fantastic once it reaches it's archetype and gone gold. The graphics are spectacular. The gameplay is intense and highly addicting. NS1 has a large cult following and I'm quite sure this game will have a much larger one.
But in the Summer...well, we'll just have to see now won't we.
We can all imagine the benefits of that but since they are not doing it there must be a big problem with it that I can't think of right now. Or is something along these lines planned for a later point in time already?<!--QuoteEnd--></div><!--QuoteEEnd-->
Well, I guess some effort to isolated the relevant declarations, include some rudimentary documention, and package it with each release. I can see why they haven't done it (yet). Maybe they didn't expect anyone to mod so close to the metal, after all, you can count the number of mods to feature C-API interaction on one hand.
Not trying to create pressure here, that's just the perspective I had so far and based on what has been said in this thread I'm beginning to have doubts. Kinda hoping for a comment from the devs here.
That was just me implying that real programmers don't use scripting languages. Just a hyperbole. I really do not like dynamic typing. Let the compiler catch the bugs I say.
I also said you guys should stick to the guns and not move code into C++ code (like Far Cry), because that would negate the benefits you get from having the scripts (clear interface, easier moddable, you can probably change the code at runtime?).
Real programmers work with the tools they're given. Real good programmers make miracles happen with the tools they're given.
With all due respect, you really can't say we are behind schedule if you haven't seen our schedule :) There is a lot going on behind the scenes, many features that have been almost completed, but just not released yet, due to inadequate testing, or just requiring the final polish pass on them. For example, you give the example of a new mine model, which has already been concepted and modeled and is now in the process of being textured, so not very far from completion.
We wouldn't have set a Summer release date if we weren't confident we could hit it, as we are obviously a bit sensitive on the subject of release dates after the whole fall 2009 thing.
--Cory
--Cory<!--QuoteEnd--></div><!--QuoteEEnd-->
for what it's worth, you'll never beat Valve in that department.
1. Engine programmer decides that the main engine language (C++) is to complicated for the people who make the game. He integrates a simple scripting engine for "non-programmers".
2. Non-programmers write unmaintanable and inefficient code because they have not much experience.
3. Whole thing blows up.<!--QuoteEnd--></div><!--QuoteEEnd-->
I'm an experienced programmer (7 years in various languages), just for some context.
I think using a scripting language like Lua for game code is a good idea - it's far easier to rapidly prototype and build the game using the scripting language, as opposed to C++.
There are various spots of optimization going forward:
1) Lua game logic (eg, optimizing the logical flow of the code - like the hydra optimization).
For the record, it would be slow in C++ if the logical code was the same as well (but not as slow).
2) Putting more upfront effort in optimizing the Lua runtime (which Max is working on I believe?) sounds like a much better win in terms of performance (and on-going game development) than porting code to C++.
I think that argument goes either way. There are advantages and disadvantages to weight. You certainly have to know where to use which tools. After all there must be a reason most games are written in C++. But it is a personal choice and as long as it works out I don't care.
<!--quoteo(post=1926175:date=Apr 16 2012, 09:37 PM:name=Squeal_Like_A_Pig)--><div class='quotetop'>QUOTE (Squeal_Like_A_Pig @ Apr 16 2012, 09:37 PM) <a href="index.php?act=findpost&pid=1926175"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->We wouldn't have set a Summer release date if we weren't confident we could hit it, as we are obviously a bit sensitive on the subject of release dates after the whole fall 2009 thing.
--Cory<!--QuoteEnd--></div><!--QuoteEEnd-->
I want this to succeed and I am invested, but please don't lie to me. I can see the state of the game and it is nowhere near a beta stage yet alone "release". I don't know if releasing something unfinished and naming it final is a good move.
(As a reminder: beta stage is when things stabilize. <a href="http://www.unknownworlds.com/ns2/news/2012/4/alien_commander_v2_0" target="_blank">http://www.unknownworlds.com/ns2/news/2012..._commander_v2_0</a> shows that you are not stabilizing.)
We wouldn't have set a Summer release date if we weren't confident we could hit it, as we are obviously a bit sensitive on the subject of release dates after the whole fall 2009 thing.
--Cory<!--QuoteEnd--></div><!--QuoteEEnd-->
Would it be too cheeky to beg for some concept art? For some reason I'm really interested to see how you've worked your re-interpretation magic on the mine, specifically.
God, that's a weird thing to be interested in. I think it's because I've been so impressed with all the other NS1->NS2 transitions that I kind of wonder what you can possibly do with a wee square of metal.
We wouldn't have set a Summer release date if we weren't confident we could hit it, as we are obviously a bit sensitive on the subject of release dates after the whole fall 2009 thing.
--Cory<!--QuoteEnd--></div><!--QuoteEEnd-->
Relax. That wasn't a "come at me bro" moment. :) I understand you're working tirelessly to get the job done and I/we respect that. And who are we to say what's what? True.
But I did say "We'll see." And perhaps we shall. If this game ships during summer time I'll tuck my tail between my legs and play.
Haha - Aye.
God, that's a weird thing to be interested in. I think it's because I've been so impressed with all the other NS1->NS2 transitions that I kind of wonder what you can possibly do with a wee square of metal.<!--QuoteEnd--></div><!--QuoteEEnd-->
Ok, I'm kind of derailing the thread here, so I apologize. But here's the mine concept.
[attachment=36081:Mines_LowRes.jpg]
Back to your regularly scheduled performance discussion.
--Cory
--Cory<!--QuoteEnd--></div><!--QuoteEEnd-->
That kinda looks like a mobile version of that evilhouse in simpsons!
Love it!
Does the 'activated' sign pop up when an alien triggers it, like a toy popgun? You should make it say 'Gotcha!' instead ;-)
- Threading is not even mentioned? What is being done about it?
With modern cpus striving for more cores in addition to more processing power per core (in general at least), it only seems natural to focus on multi-threading aswell.
According to the steam hw survey, 50% have a dual core system, while 40% have a quad core system. I am postive the trend will continue torwards multicore cpus, so making more effienct use of the CPU would help to address the issue aswell. This is especailly true if I assume the scaleability to be high; if ns2 would run in threads with roughly even distribution of load, I'd get more then double the frame rate (ingoreing posible GPU limit).
Bunch of processors also support hyper threading; with decent multi-threading support it would also yield an improvement.
- Moving lua to c++ code?
Of course you mention that moddability is important, but performance increases would be nice to have though. In some cases it still may make sense I guess, though I see gettingf some design conflict (eg engine unspecific code (ns 2 code) in spark). I'd guess it will be avoided, but some word on that aswell?
/further derailed thread :)
lol o man. UWE, if you need to delay the game again, keep doing it. If the community says it's not ready, please believe them. Being in the RO2 beta, all of us kept petitioning for the game to not be released yet and what happens? bad reviews, people left in droves.. it was a disaster area.
<a href="http://web.archive.org/web/20100728234447/http://www.naturalselection2.com/faq/game-questions/what-are-the-system-requirements-and-when-will-ns2-be-releas.html" target="_blank">http://web.archive.org/web/20100728234447/...-be-releas.html</a>
<img src="http://naturalselection.de/images/smilies/ednk/icon_ups.gif" border="0" class="linked-image" />
I couldnt resist, sorry.
<a href="http://web.archive.org/web/20100728234447/http://www.naturalselection2.com/faq/game-questions/what-are-the-system-requirements-and-when-will-ns2-be-releas.html" target="_blank">http://web.archive.org/web/20100728234447/...-be-releas.html</a>
<img src="http://naturalselection.de/images/smilies/ednk/icon_ups.gif" border="0" class="linked-image" />
I couldnt resist, sorry.<!--QuoteEnd--></div><!--QuoteEEnd-->
Is there any official information about the real mininmal system requirements? (not that the above one wasn't official...)
With modern cpus striving for more cores in addition to more processing power per core (in general at least), it only seems natural to focus on multi-threading aswell.
According to the steam hw survey, 50% have a dual core system, while 40% have a quad core system. I am postive the trend will continue torwards multicore cpus, so making more effienct use of the CPU would help to address the issue aswell. This is especailly true if I assume the scaleability to be high; if ns2 would run in threads with roughly even distribution of load, I'd get more then double the frame rate (ingoreing posible GPU limit).<!--QuoteEnd--></div><!--QuoteEEnd-->
You can thread physics, AI, input, all of which is handled by the engine and written in C++ with great efficiency. Game logic however is very hard to solve in parallel threads as usually all is within one loop and depends on itself sequentially.
Also, you can not just "make something threaded", usually only small parts of the code are candidate for multi threading and with that also the amount of efficiency that can be gained throughout the entire program. See Amdahl's law for an accurate description of that phenomenon.