Multi-core support

Started by Nickname34, January 19, 2016, 12:43:34 PM

Previous topic - Next topic

Fluffy (l2032)

QuoteIf I build my range 56 SIF shield, the game loses the ability to go at 3x speed anymore, and I have to play at 2x or less
I have to say I take offense at this. Clearly, that mod is horribly coded. I know in this day and age of cloud computing throwing more and more hardware (or cores) at everything is pretty much the default solution, but whatever happened to optimization?

Honestly, if a single mod is putting that much stress on your game, don't you think that mod is the problem, and not the game it self?

skullywag

#31
Ill post a pic of a rather large base i have running currently with a decent helping of mods on the biggest map and it still runs fine. Im running fx8350 so a single core of that is nothing like an i7 so yeah id agree with fluffy it must be the mods.

The 56 circular shield has to do a crazy amount of checking on the hundreds of cells in it area. I used the same code to make my shields and i can have 10+ of them simply  cuz they are smaller.
Skullywag modded to death.
I'd never met an iterator I liked....until Zhentar saved me.
Why Unity5, WHY do you forsake me?

Toggle

"If I could, I'd make everyone do it the way I wanted them to or their game will never survive." Literally what you said, vas...
Selling broken colonist souls for two thousand gold. Accepting cash or credit.

lude

Quote from: Vas on February 05, 2016, 10:15:51 AM
Quote from: Ectoplasm on February 05, 2016, 06:56:32 AMIn KSP though you have one physics model to compute all at the same time. You build your rocket and then launch it and the game only (ha! "only") Needs to compute the forces on the rockets structure & components or the temperatures generated through velocity. This occurs all at once - the game already knows the design and the various tolerances involved - it just needs to run the simulation.
Just a note, what happens when you enter 2.5KM of 7 other ships?  The game has to load all of them and calculate more than just their "on rails" status now in real time as you move towards/past them.  It also does physics on a per part basis, not "this rocket is one object".  If you don't have enough struts on one object to keep it attached and you make a wrong turn at a high speed, that single piece will rip off, and your balance will be offset and then physics starts hurting the rest of your unbalanced ship trying to tear more things off if you make another wrong turn or move.  Along with the heat calculations per part as time goes, and the wind force per part, current gravity's affect on your ship, etc etc.  It' a lot more than just "physics doing one thing".  KSP is a 3 dimensional game, with a lot going on all at once.
Oh I know, I also use Ferraroram and the integrity mod, I also know what happens with a lot of ships near each other and being kept in physics mode or how multiplayer mod deals with that limitation or how hard it is to try to crash two things at high speeds in orbit, tho i personally didn't manage that, just watched one of scott's videos.
Quote
Rimworld has a lot more going on of course, and is much more CPU intense than most games would be especially if you're a heavy mod user adding many more events objects pawns and such.  I'm on an i7 that goes up to 3.6GHz and I still get lagged down when my base reaches about one year old because of how massive it gets.  I get lagged down a lot less than I did on my previous laptop which was an i7 that got up to 3.1GHz (rarely though cause damaged CPU fan and the motherboard had melted partially apparently..) but yea.  I still get lagged down, and Rimworld is hardly using any of my CPU at all when I'm lagged down.  If I build my range 56 SIF shield, the game loses the ability to go at 3x speed anymore, and I have to play at 2x or less.  So that one building is a massive hit on the CPU.  A single core can not possibly keep up with everything in this game, and this game is the type that will require multi-core support.
Yeah, like the things propagating per cell is very elaborate, compared to simulators like DF2, I just upped my CPU to 4.2ghz with an FSB of 240, the "mysterious IPC" is more affected by FSB increase than by multiplier, keeping the other busses at their vanilla speeds with an increased FSB netted me very nice results with most single core limited games, especially in games like these I'm currently using 153 mods and I tend to play for longer, but can't say that having over medium sized maps is fun after a few years, I also tend to have around a 100 animals, a dozen or two bots and 40-50 colonists and a quarter of that in prisoners, but my game usually only hangs majorly when there's job ticker or pathfinder issues or other issues caused by mods, I try to resolve them as I go by playing.

So at least having some of the minor tasks that are not time critical or dynamic on another core would be nice, but that already would let debugging and bug finding problem arise that are a lot harder to fix, so I'm indifferent to should rimworld go multicore, I personally like the game and will just be waiting for it's ideological sequel that will come out in a few years or a decade when all these problems have already been tackled by students, professors and experienced game developers and the solutions then will be part of public knowledge, easily available to anyone.
Quote
All game developers should be doing multi-core support by default in their game engines.  Honestly if I became a game developer right now, I'd turn down any game engine (Unity 4) that did not support Multi-core and show them that they need to upgrade their support to have multi-core or other game developers could turn them down too.  "Nah, I'd rather go with something that has 64 bit and multi-core, you guys don't have it so I'll find someone better."  If other game developers were to follow this logic, then these people would have to get off their asses and make their game engines support both 64 bit and Multi-core, or they'll just keep losing customers.
If i became a game developer right now I'd also look into simple or elaborate multicore usage depending on what I want to achieve, but 64bit would be an absolute must unless what I want would be smaller and faster in a 32bit scenario.
But most people learn as they go by developing and there are few sets of standards, CCC tries to propagate some, for more elegant code, better propagation of solutions and simpler designs.
Quote
Quote from: lude on February 05, 2016, 07:46:59 AMalso under windows 10 my rimworld uses ~30% which is the utilization of more than two cores at 4.5 ghz
Refer to a statement above as well as this: Are you using 70+ mods in your game?  Is your map more than 2 years old thus far with lots of pawns and buildings everywhere?  If not, then you aren't playing the game as hard core as I am.  Good god you should see how bad it gets when Tribals spawn even on a small map with a small base.  Like 100 fracking pawns all spawn at once and lag your game so bad you die from lag more than you die from hoards of bodies being thrown at you.  And I'm on a 4th generation i7.  You're clearly on a desktop CPU of course so.  You have more power.

Yeah I use a desktop and will always be using them for gaming, even brought my old one to my parent's place so if I do vacation there I don't have to deal with my laptop.

I also know how horrible it gets once there's a few hundred pawns spawning or a tiny problem with that together bringing the game to a halt.

Also my CPU is the smaller brother of skullywag's but it does very fine in certain scenarios.
running 4 cores instead of 8 (the option where no core shares ressources with another)already increases it's single core performance by about 12-15% and increasing the FSB instead of the multiplier also increases single core performance a lot, just multiplier does a rather bad job and with games like these in most scenarios increasing FSB by 20% nets me a near 20% performance increase as well as often just being fast enough to have some overhead again or not having so much stuff lagging behind that needs to be calculated.

tl;dr that 20% made speed option 2 unlaggy again with over a 100 of my pawns and a lot of stuff.


Vas

#34
Quote from: Ectoplasm on February 05, 2016, 11:20:09 AM
Quote from: Vas on February 05, 2016, 10:15:51 AM
All game developers should be doing multi-core support by default in their game engines. 
To be fair, when Rimworld started this wasn't an option in Unity. Rimworld will be 3 in November. I think you need to consider this legacy, multi core just wasn't there in Unity.
Yes, but other engines had it and 64 bit too.

Quote
Quote from: Fluffy (l2032) on February 05, 2016, 11:37:26 AM
Quote from: VasIf I build my range 56 SIF shield, the game loses the ability to go at 3x speed anymore, and I have to play at 2x or less
Clearly, that mod is horribly coded. (stuff)
Honestly, if a single mod is putting that much stress on your game, don't you think that mod is the problem, and not the game it self?

Quote from: skullywag on February 05, 2016, 12:41:59 PMThe 56 circular shield has to do a crazy amount of checking on the hundreds of cells in it area. I used the same code to make my shields and i can have 10+ of them simply  cuz they are smaller.
56 is a massive range, that's why it slows down the game.  I got tired of trying to build a SIF shield every 6-8 blocks so I wanted one massive one to protect a large area so I made the mod that adds one, on top of the ED Shields mod.
Skully, are you saying that I could have 50+ small SIF shields as apposed to one large one?
Fluffy, The game lags down after I get a large base 2 or 3 years in.  Doesn't your game have an extreme lag hit in late game tribal raids?  Like 40+ pawns suddenly spawning to come destroy your base.

Quote from: Z0MBIE2 on February 05, 2016, 01:21:33 PM"If I could, I'd make everyone do it the way I wanted them to or their game will never survive." Literally what you said, vas...
No, I said I'd make game engine makers keep up with times or not use their product to make my game.  Get it right.
No one in the world has a single core CPU anymore.  All machines are multi-core unless you specifically go out designing one that is single core.  There's only so much you can do with a single core at this point.  You can't give more and more power to a single core without higher and higher temps.  I think the world record so far is almost 9GHz on a massively overclocked system cooled with Liquid Helium I think.  I'm guessing right now because I don't remember too well.  Also, see?  Even this extreme overclock is two core, multi-core.  http://valid.x86.fr/lpza4n
So why aren't game engine developers keeping up?  This technology has been out for ages, and some are just lazily lagging behind where it's safer and easier to work at rather than trying to keep up and take a little risk.  I mean, Unity is finally getting up there now or trying, but still.  If I were a game dev, I would look for a way to support all my potential users, and if the game engine I was looking at didn't support multicore, I would look into other game engines because I know for a fact that there is no single core gaming machines out there.



By the way, as stated before some things in this game CAN be offloaded to other cores.  Path finding, for example.  40+ tribals spawn and suddenly your game goes from a smooth 60FPS down to 5FPS (technically speaking, not graphics lag) trying to process their path finding and whatever else it's processing during their attack.

Also, temperature calculations can be offloaded to another core in order to speed up temp checks.  You don't need to specifically wait for a temp check to go through to test something.  Simply set the cell/room temp and have the other object that deals with temps do a "check current temp" every so often.
TempCore: Run Calculations every 50ms
Heater: Checks Temp every 200ms
Cooler: Checks Temp every 200ms
ObjectThatGoesBoomIfXTemp: Checks Temp every 100ms

Just an example really.  You can set how often it will check the current temp while the temp of everything is calculated separately.



Lude,
I use a gaming laptop because I don't have internet at home and have to go to town a lot.  :P  My current laptop can most likely do anything your desktop can do.  :P  Maybe not 4k resolutions and stuff but I don't care about that.  1080p is fine with me, not like I have 4k screens or need one anyway. xP  Not much else I can reply to as it would either be off topic or I agree.  :P
Click to see my steam. I'm a lazy modder who takes long breaks and everyone seems to hate.

Fluffy (l2032)

#35
QuoteSo why aren't game engine developers keeping up?  This technology has been out for ages, and some are just lazily lagging behind where it's safer and easier to work at rather than trying to keep up and take a little risk.
For the last time; because it is hard, and games do not lend themselves particularly well to parallelism.

At this point we're both sounding like broken records. I keep giving you perfectly valid reasons for why Ludeon/Tynan may not have implemented, and may never implement parallelism to take advantage of multi-core architecture ( we never know, maybe he'll get inspired. ), and you keep giving irrelevant counter examples.

In the end, I love Ludeon and Rimworld for what it is, one guy doing what he wants, how he wants to do it, and creating a creative and weird game that can truly surprise you.

oh on a final note, sure, my game slows down too when a colony gets large. But 1; the game was never meant to be a Sim City clone, it's a small-scale story telling game, and 2; I would not use a mod that scans ~350 cells every single tick.

<img removed>



Vas

Ludeon made Unity? I didn't know that.  </sarcasm>
I was blaming Unity for not being multi-core.  Not Ludeon.  I was saying that had I been the one choosing a game engine, I would have chosen one that had multi-core support to begin with, as well as 64 bit support.  Two technologies that are in every computer around the world now.  Yes, it's hard, but you have to adapt and get used to it.  You can't just stay in the past. 

I love the game still, even though I'm irritated that some of it literally throws logic out the window as if the laws of physics don't apply (The year's length, Steel being thousands of years old), I just want m new age computer to be able to play this game smoothly.  But it can't.  No computer can, because it does not utilize multi-core support and there is way too many things in this game that require CPU time.  Some things are constant and require per tick calculations thus putting a larger load on the CPU.  Some of these calculations literally can be offloaded to another core without hurting gameplay in the slightest and without anything waiting on that core to finish what its doing in order to continue.

Like I said in an earlier example.
Put temperature calculations into its own core.  Have it calculate all temperature things per tick as normal, maybe even give it double speed on that so it can check more often because it now has its own dedicated core.
Now, things that require the temp no longer need to ping the CPU or anything to find out, they just read the "CurrentTemp" value in memory provided by the other core that does the temperature work.  So one core is no longer managing path finding, temperatures, random event counters, animals, grass growing, power network, etc.

But yes, it is hard work. and UNITY, should have been putting support for this in to begin with and no game engine should not support multicore at this point in time because we simply aren't ever going back to a world of single core processing.  After seeing the game progress for a long time now, I can see that raids are increasing in size in order to make them more difficult which is putting even more hurt on the CPU.  What happens when this game is released and it is set up in such a way that you can only play for 6 game months before the world's greatest super computers start to lag?  Who's going to want a game that can't be processed unless you have a liquid hydrogen cooled CPU running at extreme levels of overclock that'll melt your CPU in less than half a second should your cooling solution fail?

Your argument: Because it's hard.
My argument: It needs to be done.

You proved its hard.
I proved it needs to be done.

So yes, we've gone around in a circle of you saying "its too hard, so we shouldn't do it." while I keep pointing out how the game lags too much even on high end CPUs mid-late game and it isn't even released yet which could be bad for the future of the game if we add any more advanced things to the game.

EDIT: Nice image, I don't even remember who that is, but it did manage to take me about 20 minutes to load it.  :P
Click to see my steam. I'm a lazy modder who takes long breaks and everyone seems to hate.

skullywag

And when you get into this never ending loop ease will more than likely win out.
Skullywag modded to death.
I'd never met an iterator I liked....until Zhentar saved me.
Why Unity5, WHY do you forsake me?

Vas

#38
Well, I guess that means when the game is released and you can't play for more than 1 hour because an hour later even on the most high end machines, people will complain, rate the game down for being unplayable, and it will lose many sales.  And you will have no one to blame but yourselves for not pushing multi-core harder before release.  I know for a fact, if people play the game and it starts to lag on their high end machines, they aren't going to be "understanding" of the programming difficulties of multi-core support.  They will complain, and they will bitch.  Some people even bitch about Metal Drift not being multi-core, and it doesn't even need multi-core support because it's too basic of a game that can't even lag on any processor that's still working today (assuming people stop using 10 year old CPUs that is) (graphics is another story).

I know that the community will complain about lack of multi-core support, and while we here understand the difficulties of making the game multi-core, the masses will not understand and will rant, bitch, complain, rate the game down, make it out to be a bad game to buy.  I foresee this happening.  So if Tynan is ok with the risk of this happening, sure, he can continue on the easy path and let the game continue being laggy on high end multi-core CPUs.  It's his choice after all.



I originally replied because people here were trolling the author of this post for wanting multi-core.  I mean sure, he did kinda say it in a basic way and a bit of that standard ignoring everything others say "please we need it, do it, make it happen" way...  But no one should troll another for such a legitimate suggestion.  That's wrong, no, just don't do it.  He hasn't even been back since then.

Multi-core is a legitimate suggestion that no one should troll someone over because as you know, nearly all CPUs in the world are multi-core multi-threaded.  Even the world record CPU is multi-core with a speed of nearly 9GHz.  You'd think a world record CPU would be single core to promote more speed and better temp stability but nope, it was multi-core.
Click to see my steam. I'm a lazy modder who takes long breaks and everyone seems to hate.

spacemarine658

Quote from: Vas on February 06, 2016, 09:16:28 PM
Ludeon made Unity? I didn't know that.  </sarcasm>
I was blaming Unity for not being multi-core.  Not Ludeon.  I was saying that had I been the one choosing a game engine, I would have chosen one that had multi-core support to begin with, as well as 64 bit support.  Two technologies that are in every computer around the world now.  Yes, it's hard, but you have to adapt and get used to it.  You can't just stay in the past. 

I love the game still, even though I'm irritated that some of it literally throws logic out the window as if the laws of physics don't apply (The year's length, Steel being thousands of years old), I just want m new age computer to be able to play this game smoothly.  But it can't.  No computer can, because it does not utilize multi-core support and there is way too many things in this game that require CPU time.  Some things are constant and require per tick calculations thus putting a larger load on the CPU.  Some of these calculations literally can be offloaded to another core without hurting gameplay in the slightest and without anything waiting on that core to finish what its doing in order to continue.

Like I said in an earlier example.
Put temperature calculations into its own core.  Have it calculate all temperature things per tick as normal, maybe even give it double speed on that so it can check more often because it now has its own dedicated core.
Now, things that require the temp no longer need to ping the CPU or anything to find out, they just read the "CurrentTemp" value in memory provided by the other core that does the temperature work.  So one core is no longer managing path finding, temperatures, random event counters, animals, grass growing, power network, etc.

But yes, it is hard work. and UNITY, should have been putting support for this in to begin with and no game engine should not support multicore at this point in time because we simply aren't ever going back to a world of single core processing.  After seeing the game progress for a long time now, I can see that raids are increasing in size in order to make them more difficult which is putting even more hurt on the CPU.  What happens when this game is released and it is set up in such a way that you can only play for 6 game months before the world's greatest super computers start to lag?  Who's going to want a game that can't be processed unless you have a liquid hydrogen cooled CPU running at extreme levels of overclock that'll melt your CPU in less than half a second should your cooling solution fail?

Your argument: Because it's hard.
My argument: It needs to be done.

You proved its hard.
I proved it needs to be done.

So yes, we've gone around in a circle of you saying "its too hard, so we shouldn't do it." while I keep pointing out how the game lags too much even on high end CPUs mid-late game and it isn't even released yet which could be bad for the future of the game if we add any more advanced things to the game.

EDIT: Nice image, I don't even remember who that is, but it did manage to take me about 20 minutes to load it.  :P

actually unity is multi threaded:

"We internally multithread code with our job system. We do it in a way that is completely hidden from the user for as much code as possible. The guiding principle is always that from a script the outputs and order of outputs are always the same, whether multithreading is enabled or not. Essentially we provide deterministic behaviour when multithreaded code is enabled. Eg. Mecanim / Shuriken / Multithreaded renderer / Mesh skinning / Cloth / Various smaller tasks etc all use the job system. "
Recent versions of Unity introduced more multithreaded editor improvements like substance reimports (from http://unity3d.com/unity/whats-new/unity-4.2 ), and skinning can be done on the GPU (DX11, Pro only), which technically isn't multithreaded but does run massively parallel outside the CPU, so you know, basically the same thing :)

Additionally, going forward Unity is looking at the following:

"We have recently invested a some good chunk of time in improving the scheduling. Specifically we are coming up with safe ways of running as much code as possible in parallel to scripting code. Running not only the render thread but also arbitrary jobs in parallel to scripting is quite important for getting full multithreading utilization.

Scripting code can do pretty much anything at any point and our goal is to make it invisible to game code when we do multithreading except for the performance increase. So it's a bit of a tricky problem.

For example a script might get/set the position of a transform component at any point. So if you run the animation system in parallel and it writes to the transform position, accessing the transform must wait for the job to complete. We found some very interesting ways to handle this in a safe and very efficient way. A lot of work went into lock free data structures to make it efficient. But it's showing some very big improvements. This is definitely not shipping yet and still in deep R&D.

We also are converting more and more code, recently Navmesh, culling a couple of smaller chunks of code like caching transforms prior to culling etc to be multithreaded."

lude

as a tip win10 scheduling is superior to win7 or 8 and will net you an improvement in single core heavy games, up to 12% but mostly somewhere around 6-8% and there are probably scenarios where it's worse or better

and under win10 the game utilizes three cores, no clue what exactly it does but two are usually heavily utilized while the third not so much

skullywag

I would need a monumental colony in vanilla to test my processor (which doesnt have a particularly high clock) even modded im not seeing slowdowns with 15+ colonist plus a dozen bots and 100s of animals on full size maps 5 years into the game. It sounds to me like the people mentioning slowdows are using the same set of mods of the hardcore modpack. My guess is we have a few mods that need some optimisation, cuz im just not seeing these performance issues...
Skullywag modded to death.
I'd never met an iterator I liked....until Zhentar saved me.
Why Unity5, WHY do you forsake me?

Ectoplasm

Quote from: Vas on February 06, 2016, 09:16:28 PM
Well, I guess that means when the game is released and you can't play for more than 1 hour because an hour later even on the most high end machines, people will complain

Anyone else here thinking that this is complete and utter rubbish? ONE hour and your game is unplayable? Rubbish. Total rubbish. Stop exaggerating. That doesn't happen for me on an i3-2100. And if it is happening for you, clearly it's something other than rimworld that's the root cause. MODs maybe? If a mod is causing problems no number of additional threads will fix things.

Quote from: skullywag on February 08, 2016, 12:06:38 PM
I would need a monumental colony in vanilla to test my processor (which doesnt have a particularly high clock) even modded im not seeing slowdowns with 15+ colonist plus a dozen bots and 100s of animals on full size maps 5 years into the game. It sounds to me like the people mentioning slowdows are using the same set of mods of the hardcore modpack. My guess is we have a few mods that need some optimisation, cuz im just not seeing these performance issues...

Ultimately though I'd concede the point that multi threading would be better, but even in Factorio which uses multi threading (though currently in a limited way) You can still end up with a factory so big that the game slows down.

Quote from: kovarexYes, but in a limited way.

  • It uses separate threads when preparing the render data.
  • It uses separate thread for render and game update.
  • It uses separate thread for map generation.
But the game logic (which is the most limited factor) runs in single thread, so when your factory gets really big it will start to lag while your other cores will not be utilitised fully.
We will probably split the game logic into multi threaded algorithm someday, but it is not as easy :)

And it is that last sentence from kovarex (head developer for Factorio) Which I feel just flies over your head. Multi thread support was not available when rimworld started development, would you tell us now how long it would take to rewrite rimworld to facilitate multi threads? I do not know the complexity or intricacies involved, but I do know that if it were easy - it would of been done already. But who knows what plans there are for rimworld down the line.




Vas

Quote from: lude on February 08, 2016, 11:17:20 AM
as a tip win10 scheduling is superior to win7 or 8 and will net you an improvement in single core heavy games, up to 12% but mostly somewhere around 6-8% and there are probably scenarios where it's worse or better
I'm on Windows 10 and after many straight hours of gameplay, the game gets laggy, and then when I start making intense structures like massive shield generators, the game bogs down to a crawl.  So the game does get laggier the larger my base is, even on Windows 10 and it's crappy horrible minimalist system where people seem to THINK it runs faster because they deleted all graphics in Windows 10 and deleted old code making older games incompatible, like Blit technology.

Quote from: Ectoplasm on February 08, 2016, 01:46:12 PM
Quote from: Vas on February 06, 2016, 09:16:28 PM
Well, I guess that means when the game is released and you can't play for more than 1 hour because an hour later even on the most high end machines, people will complain
Anyone else here thinking that this is complete and utter rubbish? ONE hour and your game is unplayable? Rubbish. Total rubbish. Stop exaggerating.

Quote from: skullywag on February 08, 2016, 12:06:38 PMMy guess is we have a few mods that need some optimisation, cuz im just not seeing these performance issues...
Ultimately though I'd concede the point that multi threading would be better, but even in Factorio which uses multi threading (though currently in a limited way) You can still end up with a factory so big that the game slows down.

Quote from: kovarexWe will probably split the game logic into multi threaded algorithm someday, but it is not as easy :)
Multi thread support was not available when rimworld started development, would you tell us now how long it would take to rewrite rimworld to facilitate multi threads? I do not know the complexity or intricacies involved, but I do know that if it were easy - it would of been done already. But who knows what plans there are for rimworld down the line.
1. I was saying when the game is released, this could be an effect of the game when trying to play long term if it does not use multi-threading by then.  You're meant to quickly get off the planet, which is what Tynan is trying to do for the game.  He wants to make late game players like me have a harder and harder time treating the game as a colony simulator rather than a "get the hell off this planet" simulator.  His making larger and more complex raids is proof that the game is going down a semi-bad path where in order to make it more difficult, he just lobs more and more mindless AI at you.  The more complex you make the AI, the more CPU they will need to operate.  So whether he increases the AI abilities or increases the number of AI thrown at you, both are going to need more than one core to operate if it is to maintain smoothness.

2. I didn't look much into Factorio.  It never interested me when I saw it.

3. I'm pretty sure at this point multi-core support will be very complex to add in.  The only things I can see that can somewhat easily be split off into their own threads without needing to wait for other things in the game to process first, is Temperature, and Path finding.  Path finding may need to wait on a few things in the game, but the way it works now I don't think so.  There might also be the power grid that could be split off, but that one does affect one of the main threads in the game so that could be hard to do, who knows.  I just know that, after 6+ hours of gameplay, my game becomes very laggy.  I can't build my favorite shield generator because the ProtectCell method is very CPU intense.

Quote from: skullywag on February 08, 2016, 12:06:38 PMMy guess is we have a few mods that need some optimisation, cuz im just not seeing these performance issues...
I have 70 mods.  6 hours into the game, without even making shields yet, my game gets laggy.  Particularly laggy when a Tribal Raid comes in, which is just a cluster fuck of 100+ pawns bum rushing you.
Click to see my steam. I'm a lazy modder who takes long breaks and everyone seems to hate.

Fluffy (l2032)

Vas, you actually have a point in that there will probably be negative comments about it being single threaded on steam. This is something for Tynan to think about, and balance with the cost and opportunity cost of adding more content. As noted before, it's a huge amount of work, during which time no or hardly any new content would be added. We could debate if such a 'content drought' would be worse for PR/sales than being single threaded, but that would all boil down to assumptions, so let's not go there.

As for your comments about speed. Again, you mention that adding 'intense structures' makes the game laggy. This is absolutely completely your choice. The game is very moddable, which means that there are (possible) mods out htere that will just be too intensive. It's hardly like you can design for that kind of thing (Oh and btw, even in multi-core that one mod would still run in one core (unless the modder goes multi-core too, which is unlikely at best), and would still slow down the game to a crawl.)

As for the comment about Win10. If you remove UI elements and obsolete code, how is that a 'perceived' speed increase? Sounds to me like the speed increase is very real, you just don't like the way it's done.