Jump to content

[We need more posts! (Like seriously, a lot more)] Let's Make This the Megathread!

Misguided Kerbal

By Misguided Kerbal
in Forum Games!

 Share

Recommended Posts

Dat Kerbal Dude

Dat Kerbal Dude

Posted
Posted (edited)

1 Week Ago, i was Taking Some ScreenShots in KSP...

And they're Somewath Strange...

screenshot25.png

This Kerbal Above here is...

uhhh...

let's say he's Going to Eat that Capsule...

(I think i should make a Meme of that)

screenshot23.png

This Photo Up here is quite Hilariously Cringe... disgusting after all...

screenshot24.png

I Think i've Made a Bad Decision,This Photo up here shows a Maniatical Kerbal... Cringe After all...

BUT NOT THIS TIME KERBALS!

screenshot35.png

This Photo of Kerbin(which it was taken thanks to HullCam VDS mod) is...

Beautifull...

DISGUSTING.

I'M NOT HAPPY OF MY SCREENSHOTS AFTER ALL...

Edited by Kane Kerman
Fixed the Photos XD
Link to comment
Share on other sites
Lisias

Lisias

Posted
Posted (edited)
46 minutes ago, Commodoregamer118 said:

You want to kill my saves after all, right @Lisias?

Not even on my dreams! :D

 

40 minutes ago, Commodoregamer118 said:

eisMusR.png

37 minutes ago, Kane Kerman said:

whath's theh prohblehmh ofh thath?h

Thats this history: 

In order to reach the best performance possible, Unity allows you to split all the tasks you need in order to build a frame in many individual concurrent tasks. Since these tasks runs on every frame, and potentially uses some memory from the heap, Unity pre-allocated some memory just for them (and the code that allocs memory for is is called JobTempAlloc). Doing this way, these temporary jobs will not clutter the main heap (used by the c# scrips Squad and Authors usually wrote for the Add'Ons), and so we will have lesss stuttering related to memory garbage collection.

However, Unity has imposed a restriction on this "special" heap - your code can only keep memory allocated on it for 4 frames. This was made to ensure the remaining temp jobs will not run out of heap space, at the same time forces you to keep the use of that heap to the minimum (otherwise, why waste efforts on building it, if the aftermath is the need to continuously run the garbage collector on it, creating another source of stuttering?).

Well, KSP is a CPU intensive game. All that physics really makes the CPU sweat. When you set KSP to run on 120 frames per second, you force all that temp jobs to carry on all the tasks in 4 frames at 120 per second, or 4/120 = 0,033333333 seconds. Otherwise the WatchDog will bark on you.

But if you use 60 frames per second, that 4 frames become 4/60 = 0,066666667 seconds. Your temp jobs now have twice the time to run.

And with heavily loaded CPUs, having twice the time to run can be the difference between being able to carry on the task in time or not.

If you have this problem happening on you, set the Frame rate to 60 or even less. This should mitigate the problem on your machine.

I explained how to do it here.

 

Edited by Lisias
Of cuorse, tyops!
Link to comment
Share on other sites
Dat Kerbal Dude

Dat Kerbal Dude

Posted
Posted
2 minutes ago, Lisias said:

In order to reach the best performance possible, Unity allows you to split all the tasks you need in order to build a frame in many individual concurrent tasks. Since these tasks runs on every frame, and potentially uses some memory from the heap, Unity pre-allocated some memory just for them (and the code that allocs memory for is is called JobTempAlloc). Doing this way, these temporary jobs will not clutter the main heap (used by the c# scrips Squad and Authors usually wrote for the Add'Ons), and so we will have lesss stuttering related to memory garbage collection.

However, Unity has impose a restriction on this "special" help - your code can only keep memory allocated on it for 4 frames. This was made to ensure the remaining temp jobs will not run out of heap space, at the same time forces you to keep the use of that heap to the minimum (otherwise, why waste efforts on building it, if the aftermath is the need to continuously run the garbage collector on it, creating another source of stuttering?).

Well, KSP is a CPU intensive game. All that physics really makes the CPU sweat. When you set KSP to run on 120 frames per second, you force all that temp jobs to carry on all the tasks in 4 frames as 120 per second, or 4/120 = 0,033333333 seconds. Otherwise the WatchDog will bark on you.

But if you use 60 frames per second, that 4 frames become 4/60 = 0,066666667 seconds. Your temp jobs now have twice the time to run.

And with heavily loaded CPUs, having twice the time to run can be the difference between being able to carry on the on in time or not.

If you have this problem happening on you, set the Frame rate to 60 or even less. This should mitigate the problem on your machine.

I explained how to do it here.

mmmmmmm...

my KSP Average FPS are between 6-24.

maybe if i do that,my KSP will be Stable,Right?

Link to comment
Share on other sites
Lisias

Lisias

Posted
Posted (edited)
1 hour ago, Kane Kerman said:

mmmmmmm...

my KSP Average FPS are between 6-24.

maybe if i do that,my KSP will be Stable,Right?

Your mileage will vary a lot, but it (theoretically, and with a lot of luck) even improve a tiny bit your frame rate, as KSP will not try to match that 120 fps anymore.

There're 2 thingies on Add'Ons that are tied to that a cycle and affects heavily the gaming: Update and FixedUpdate.

FixedUpdate is tied to that Physics blah** thingy. You raise this value, KSP does less physics calculations per second (call FixedUpdate a little too less, I think) but the overall simulation will run "coarser". This value is the smaller discrete quantum of time between two events that KSP will be able to handle, from collisions to the PIDs it need to run the SAS. It's a trial and error effort, you change it until the load on the CPU is acceptable without screwing up the gaming. The effects are way more perceptible on space, because the velocities are a lot greater than and the effect will be more perceptible.

The Update is tied to the FPS. Changing the FrameRate will call this one less times per second, and other than having a less seamless animation, KSP physics will run the same - not to mention the JobTempAlloc stunt).

So, try to lower the Frame Rate first.

-- -- POST EDIT -- -- 

* Fired KSP and checked the real name of the "Physics Blah" : Max Physics Delta-Time per Frame. It's on the Main Menu/Settings/General, middle right of the screen. The default value is 0.04, I think this is 4/100 of a second.

Edited by Lisias
Physics Blah
Link to comment
Share on other sites
Dat Kerbal Dude

Dat Kerbal Dude

Posted
Posted
1 minute ago, Lisias said:

Your mileage will vary a lot, but it (theoretically, and with a lot of luck) even improve a tiny bit your frame rate, as KSP will not try to match that 120 fps anymore.

There're 2 thingies on Add'Ons that are tied to that a cycle and affects heavily the gaming: Update and FixedUpdate.

FixedUpdate is tied to that Physics blah thingy. You raise this value, KSP does less physics calculations per second (call FixedUpdate a little too less, I think) but the overall simulation will run "coarser". This value is the smaller discrete quantum of time between two events that KSP will be able to handle, from collisions to the PIDs it need to run the SAS. It's a trial and error effort, you change it until the load on the CPU is acceptable without screwing up the gaming. The effects are way more perceptible on space, because the velocities are a lot greater than and the effect will be more perceptible.

The Update is tied to the FPS. Changing the FrameRate will call this one less times per second, and other than having a less seamless animation, KSP physics will run the same - not to mention the JobTempAlloc stunt).

So, try to lower the Frame Rate first.

Thanks for that "A.I"(Additional Information,not Artificial Inteligence)!

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...