Latest Developer Posts
ezekel wrote: » Just to clear things up with this update We have a multi-thread option we can enable (but it's disabled by default) and we have a new vram option? and if we have 2gb of VRAM we should set it to 1.5GB or is it default to that. That's what I got out of all the posts so far 1) Yes, you can enable Multithreaded Physics. This will help improve frame-rates in your end-game of a round (when tons of stuff is happening and FPS seems to tank). Quad cores can see up to a 20% FPS increase in this worst-case scenario, with Dual-Cores up to 15%. The reason this is off by default, is that it's still experimental. We had a few issues during playtesting but those were all resolved. But we might have missed something - we need people to test it and give us feedback 2) If you have a 2GB Card, set it to the 2GB Option. If you find you're still hitching a little on texture loading, set it to a lower setting until you find the best one for you. Note that the lower setting you go, the more you will notice texture pop (where the texture loads in the High-Resolution one over the top of the really low-res one). Your FPS SHOULD remain smooth throughout this though which is the most important change.
Hugh Cameraman San Francisco, CA
The guys over at Techreport have shown you'd need to write an average user's amount for 35 YEARS before your drive would start to fail from writing. http://techreport.com/review/25681/the-ssd-endurance-experiment-testing-data-retention-at-300tb And there are various other articles via google you can find. Basically, as long as you're not writing over 1TB a day, you're going to be fine. Install NS2 to your SSD.
One very important part of the NS2 client is showing up the various models going through their animations. Internally, the model consists of bones to which the skin of the model (with its textures) are attached. The animation then controls how the bones move in relation to each other. When you move the bones, the skin (and hitboxes) follow. Animations needs be blended together (ie, running forward while aiming the rifle requires blending several animations together), and there is quite a few bones to keep track of, so figuring just how the left little pinkie should be curved takes a fair bit of processing power. Lategame, when the number of entities goes up, this tends to become a bottleneck when it comes time to produce new frames. Upto 30-40% of the frametime can be spent setting up the physics. In 266, this is all controlled by Lua code, which goes through all the models one by one, collects the animation data, asks the engine to calculate the new settings and then finally applying the result to the collision world before continuing with the next model. Adding multithreading is kinda difficult, because the Lua VM is strictly single-threaded. Also, the results of the physics calculations needs to be stored in the collision world, which is also single-threaded. However, the middle part - where the little toes and pinkies gets sorted out - is where most of the time is spent. This opens up for applying a bit of pipelining. Pipelining basically means that instead of having one thread doing for every entity do A (collect data), B (compute) C (apply them) we instead do Thread 1: [ Pipeline stage 1 ] for every entity do A (collect data) Store data in engine for use by the next stage Thread 2-4: [ Pipeline stage 2 ] Wait for data to be stored in engine: B (compute) Store result for use by the next stage Thread 5: [ Pipeline stage 3 ] Wait for data: C (Apply it). So we need to do the first and last part in a single-threaded fashion, but we can do all the core heavy lifting in the middle part, where we have 1-3 threads all working to keep things going as fast as possible (the balance between the first thread producing data for the rest of the threads to work with means that more than 3 isn't really going to help any). Now, the engine is not really designed to be used this way, but its been playtested for about 6 weeks now and after a few initial (and fixed) bugs, it seems to be pretty stable (ie, no known bugs). However, it is OFF by default, because ...well, shit happens. And multhreaded shit happens to be especially stinky. So its off until we feel confident it won't cause too many sticky problems. Yes, we want victi^H^H^H^H volunteers to try it out... if it crashes too much, it stays off by default ( and its off for linux users, because it causes the linux client to crash ). That said, the effect can be quite dramatic for your worst case FPS. 20% better worst-case FPS seems to be pretty standard for quad-cores. Even dual-cores gain a bit, though not as much. tl;dr - Multithreading will increase your worst-case FPS by 20% (for quad core+) _OR_ possibly crash your machine. Off by default, turn on at your peril (yea, as if that's going to stop anyone... )
The second part of the NS2 frame time quality pretty much comes down to incomplete asset setup. Essentially, all assets (models, textures, animation, fonts, sounds, materials, shaders etc) should have been loaded and compiled/prepared before you start playing the game so that if you need an asset while the program is on the critical path (ie working on the next frame), it is instantly available. That's what NS2 is doing during that long Loading/Precaching phase. Or rather "should" be doing. When looking at hitchy "p_logall" logs in the PerfAnylyzer, I could see that many of the had a of File::Open lingering in the neighbourhood. Unfortunately, there was no way of seeing WHAT file was opened in the profiler. Once I had engine access, I added a "file critical path" logging - ie, you could tell the filesystem when it was on a critical path so it could log file opens there (there is a lot of files being opened in non-critical paths (texture streaming among other things), so logging all file accesses would be tedious). After looking at that, it turned out that there was a lot of files being opened in the wrong place, and for lots of different reasons. - Fonts were opened up on demand, and the FontManager kept track of how many were using a font ... and releasing it when the usage count went to zero. But sometimes your HUD display pops up an element that is the only users of a font - which means you take a hit loading the font from the filesystem AND compiling it; an average of 5-10ms. Then the element fades out ... and the FontManager promptly releases the font, preparing for another 5-10ms hitch the next time that HUD element needs to be shown. - Materials are short files ~100bytes or so. They were considered too small to be precached... which is fine if the file is in the filesystem buffers or on an SSD, but if not - 5-20ms hitch for each (http://en.wikipedia.org/wiki/Hard_disk_drive_performance_characteristics). - Cinematics is kinda like a movie containing sounds, models (with materials and textures) and a script; there are droves of them in the game, doing everything from waterfalls to railgun splatting. Turns out that cinematics precached their textures. Nothing else. Which meant that the first time a cinematic was played for you, it would start out by compiling any models that wasn't present already. Starting by loading them from the filesystem... and a cinematic can contain upto 20 models. And models take time to compile... hi, 100+ ms hitch. As cinematics control stuff like blink effects, blood spray etc ... guess what happens the first time you are in combat - or the first time you meet a new lifeform or marine weapon. - The GUI system is used for the HUD display, and it's ... weird. All the rest of the lua code is loaded when the client starts, but the GUI code is loaded on demand. So the first time you become a jetpack marine or an Exo or an alien, the gui script is compiled. Not so bad, really - a one time hitch the first time you become a new lifeform isn't really anything to worry about. However, it interferes badly with how you precache things in NS2. You do that by doing a compile time statement that you will be using an asset, so as the lua code is being loaded, the NS2 client is being told what assets it needs. Works well when the lua code is loaded during startup... actually, it ONLY works during that time, as the precaching system does not like being used DURING the game ... then it's not _pre_ caching, really. So no assets used only by the GUI elements are precached... and there are 422 files in "ui/*" just waiting to hitch your frame. - The only weirder part than the GUI system is actually a GUI subsystem called GUIViews ..this allows you to paint on a texture, and originally (like, back in the oughties) this was done in its own Flash virtual machine. Adding Flash just to tell you how many bullets were in the rifle was a silly idea, so Flash got kicked out and replaced by a Lua VM. Unfortunately, it wasn't replaced by using the already existing Lua VM. It was replaced by an individual Lua VM. One for every display. So a standard marine has one Lua VM dedicated to his rifle bullet display and one for his pistol bullet display. Oh, and one for the builder display. And another for the welder, if he has one. This isn't really as bad as it sounds - Lua VMs are small and cheap. The problem here is that the displays are dynamically created and destroyed - if you drop your rifle, the Lua VM is destroyed. When you pick it up again, a new Lua VM is created - AND loaded up with code ... which is read from the filesystem. And of course, the Lua code used in these separate lua VM don't even have access to the precaching system (not that they could have used it anyhow ....) so any textures or fonts used in them will of course not have been precached. So if you wonder why picking up today's first shotgun off the floor can freeze you for 100+ ms, now you know. Anyhow, most of these things (the most critical stuff) are fixed in 267, resulting in a much smoother experience. The rest are scheduled for 268. Ain't gonna be no hitching on CDT's watch.