Devnote Tuesday: New Format!

Hi everyone and welcome to a newly formatted devnote! This week we’re consolidating everyone’s news into one article to improve readability, we hope you like it.

It’s been a hectic week at Squad, the Xbox announcement received a ton of attention in the games media and the first information on KSP’s next patch seems to have blown a lot of people out of the water. We are proud of Daniel’s work, he did the Xbox One animation trailer, it’s the fastest animation he have made, with only one week to prep it. On top of all that we’ve seen the year’s largest community-organised event (KPE 3) raise over $17,000 for charity: water. We’re proud of our community for many reasons, and this event proved that is rightly so.

“ Co-hosting KPE 3 on Friday (with Ted), Saturday and Sunday was definitely a highlight in my week. ”, -Kasper (KasperVld)

On the development side, this week has been spent filling in holes, fixing bugs, and revising the new UI systems. Felipe has been focussing on the staging interface and the orbit splines. For the latter we use an external tool called Vectrosity, which handles drawing lines on screen. It seems that just like Kerbal Space Program, Vectrosity was overhauled for the new Unity UI system, which means that a lot has changed with it now, which in turn means that our orbits are all messed up and need fixing. This is a good opportunity to rewrite the code that draws the orbit, as it’s never been one of the most efficient parts of the game.

We’re really happy about the decision to push the Unity 5 upgrade to it’s own distinct patch. Mike and Felipe especially put a lot of time and work to get KSP running on Unity 5, and we feel it’ll be great to be able to run and profile the two games back-to-back both and get a good measure of the performance tweaks.

“ We are so very close to having a QA worthy build of the new patch. Very excited to see it finished and out the door! ” -Mike (Mu)

After last week’s Squadcast there have been questions about how exactly multithreaded PhysX will work in Kerbal Space Program, One of the biggest improvements is that is optimized for multi-threaded processing. The short answer is, we aren’t sure how it’ll work exactly. The insides of PhysX are hardcoded deep under Unity’s hood, which means we have very little access to it from our end.

“ Our own code hasn’t changed to support multithreaded physics simulation, so how exactly it will handle KSP objects like multi-rigidbody vessels, is not something we can see in detail.” -Felipe (HarvesteR)

There also seems to be some confusion about the difference between the terms multi-threading and multi-core. When we talk about cores, we are generally talking about hardware. Software, however, deals with threads. Threads and Cores are related, but they are different concepts altogether. Threads are virtual, abstract entities used by software to split their workload for separate. Cores are the hardware used to actually process multiple threads at the same time.

What this means for KSP is that there’s no way to know which CPU cores will get used for any given vessel, part, or anything along those lines, and we’re also not sure how simulation is split into separate threads. The way PhysX handles its multithreaded execution is internal to PhysX, and we don’t really get to see behind those curtains… That’s not a bad thing though. We get to focus on making the game on top of the physics engine, and PhysX handles the low-level simulation/computation stuff.