Jink Engine

[phibermon]

I just wrote a massive post all about progress, features, requests for like-minded individuals to join me and an internet error caused it all to be lost like socks in a washing machine.

I don't have time to write it all again so I'll do the brief version :

JinkClient, JinkServer, JinkEd - a collaborative editing engine for various game types.

It's pretty and it's got good stuff in it but it's not finished. If you want to help me make it production ready, talk to me.

I've not worked on it for a while but I am now. I'm making a game about space and stuff.

Hope you're all well, here are some screenshots.

http://www.pascalgamedevelopment.com/attachment.php?attachmentid=1423&stc=1 http://www.pascalgamedevelopment.com/attachment.php?attachmentid=1424&stc=1 http://www.pascalgamedevelopment.com/attachment.php?attachmentid=1425&stc=1

[SilverWarior]

Looking very nice. It is clear that you have put a lot of work into it.

I would like to say "Sure I'm interested in helping you out" but based on the fact that I spend very little time (too little) programing I'm afraid that I probably won't be of much help to you.

EDIT: As for internet screwing you on posting a massive post. In time I learned that whenever I'm writing a bigger post I usually copy the posts text into notepad before actually posting it. So if something goes wrong I can copy paste it back to browser when attempting to post it again.
This is crucial when you are posting on forums which have time limited login session (you are automatically logged out after certain time of inactivity) since writing a massive post would probably take you more than 15 minutes which is most often time interval after which you are automatically logged out in case of inactivity on such forum.
And yes PGD also uses such interval for logging you out unless you check "Remember me" checkbox when logging-in in which case a permanent login session is established.

[Ñuño Martínez]

That's very interesting. Tell us more. Delphi, Lazarus or both? How many platforms does it support? What license does it use? Is it integrated with Steam, GoG or some other platform?

And the more important thing: What do you need to finish it? May be I can help. :)

[farcodev]

I cannot help too, but I just wanted to say that your work is impressive! o.O

[phibermon]

I develop with FPC + Lazarus and don't own Delphi - to my current knowledge the only part that should cause problems with some Delphi versions is the FPC style operator overloading in the maths library - not a massive job if it needs changing but a bit monotonous.

It currently reliably supports Windows and Linux with slightly less reliable OSX support - I worked on Android and IOS support a couple of years ago but I've not touched these for a long time and are currently not in the framework/engine. The structure was in such a flux that maintaining GLES render-paths as I worked was slowing me down too much so I intended to re-implement but didn't get round to it.

Licence is undecided but it's my intention to provide it for free in one form or another at least in a capacity that lets people make and release games for free. I will seek recommendations or discuss / vote with any devs who decide to commit effort to the engine.

Games can be written and run without compilation via the high level game style abstractions and scripts (so it's more like modding existing games) but using the source directly yields less constraints and better performance (although adding pre-compiled code in with plugins/modules is a feasible option) so it has a use even closed source.

It has no game platform integration although that would be a great feature to have - working on my own given what's left to finish, such features are a low priority but I totally agree that it must be added at some point to make the engine truly viable.

The GUI can render in software mode (using graphics32 - Cocoa support on OSX has not been developed yet) as well as all GL versions from 2.1

The engine has a shader builder (working but not fully complete) that will generate shaders for 2.1 to GL 4.x - not all engine features are supported on all GL versions (Terrain + water use tesselation hardware on GL4 and do not have clip-mapping implementations for GL 2+3)

Shadows are current VSM but I will be adding a PCF scheme soon with an old school 2x2 filter for better performance on older hardware.

To be perfectly honest I really don't like supporting GL2.1 - the engine is heavily geared towards GL3 and up and I've been thinking of dropping 2.1 support all together in order to free up time for other tasks.

---

I'm currently working on the end game parts, spawn points, control schemes, input mapping etc so it's as easy as possible for somebody to get started making a game.

I'm also streamlining the server/client parts of the editor/engine and adding the last batch of messages (every single editing action is synced in realtime with all clients) and then cleanup and testing that will allow any client to play-test at any moment without effecting the editing state for the server or other clients (so some entities and things are dynamically spawned during play, these should not be spawned on other clients that are editing - you can probably guess from this statement the nature of the networking and messaging)

--

so what needs to be done? well it depends on what you define as 'finished' for this project - if it's an engine to make a FPS then it's nearly finished, if it's an engine to make a game like Skyrim then a bit more, if it's an engine to make a space simulator then a bit more still.

But it's currently all of these things (an abstracted 'Region' concept allows for BSP maps, terrain, planets, voxel grids)

And on top of all that there's a 2D renderer too which could be a game engine although it's currently just used for dynamic 2D content such as computer screens in games.

--

Yeah I need help. It could be brilliant but it needs more people and some more love.

[Ñuño Martínez]

Unfortunately I think that's a bit over my skills (i.e. OpenGL 1.1 without extensions nor shaders is my top skill right now). Also I'm quite focused in Allegro.pas that needs a lot of work too (I think it is limiting my skills, but I promised I'll do it, so I must do it).

Anyway I like to see a professional engine written in (Object) Pascal. We had Gamecask (https://www.youtube.com/channel/UCnh110GyNq7EWAdnZYPFVXw) but unfortunately it looks a bit dead now. :(

I really like to help but I don't know how. ::) Please let us know when you have something.

[phibermon]

Even opinions and moral support are welcome and most definitely Allegro.pas is a worthy project to maintain :) your commitment is recognized and admired! After all these years I think one of the most important skills to have when programming is dedication.

Gamecask looked great, GLScene based if I remember correctly - the level of integration with physics and the capability of the editor looked first class and the sheer amount of graphics resources available to the developers must of required some serious art skills too. I'd love to talk to the developers to understand their timetable - get any opinions or advice they might have.

I know that building my own engine and components was going to seriously slow me down rather than using GLScene but I had two motivating factors - firstly I wanted to learn how everything worked and the best way to do that is to code it yourself.

Secondly I wasn't happy with GLScene - no criticism at all - it's a great suite of components and a skilled developer can do a lot with it - I just didn't personally like the level of abstractions and general structure - I felt that that sacrificing some flexibility for higher level abstractions would of made it way more accessible and yield better performance/less class soup.

So Jink in terms of design and intent started out as a client/server focused alternative to GLScene that assumes you're going to be making games. Along with an editor and dedicated resource formats it lets you do that faster.

Let me stress that I highly recommend GLScene - it's absolutely brilliant and can do everything you want to do :)

Major kudos goes to the Cast II engine and its developer also - it was using and experimenting with Cast that gave birth to this engine and I owe much of my design to Cast - still fantastic and highly recommended (http://www.casteng.com/casteng/)

[de_jean_7777]

Quite impressive. I myself also develop my own engine. Good way to learn graphics APIs and to improve ones coding. Will use this as an example of what can be achieved with Pascal :D

[Ñuño Martínez]

Even opinions and moral support are welcome and most definitely Allegro.pas is a worthy project to maintain :) your commitment is recognized and admired! After all these years I think one of the most important skills to have when programming is dedication. :-[ You make me blush...

[phibermon]

Oh pshhh credit where credit is due :)


UPDATE :

I've setup my hackintosh again - ElCapitan has proven to be a nightmare to get working with my graphics card - in the end I had to create a custom NVCAP (a series of hex values that is queried at a low level to determine what outputs are available on a card and the priority of those outputs for use as the primary display) but now it's working. I've also setup a Mavericks install on another drive - worked instantly - go figure.

Anyway - the important point is that previous support was coded on Mountain Lion back when the maximum supported GL version was 3.2 and very buggy support at that!

Since Mavericks, OSX has supported GL4.1 (a rather laughable performance from Apple given they're still no further and they've JUST released the brand new 'Sierra') which means with the occasional alternate render-path, all engine functionality (heavy use of tessellation for Terrain rendering and my currently in development planet rendering) is working on OSX :)

I don't have ATI hardware except in a laptop and I'm not getting OSX running on an AMD chip any time soon so if anybody out there is running OSX with ATI hardware and would provide testing - I'd appriciate it!

Linux support is just fine with official Nvidia drivers for Linux as well as Mesa - not tried ATI or Intel cards on that platform however but can't see it being a problem - maybe some GLSL bugs that the more forgiving Nvidia drivers have allowed me to miss.

IOS and Android support are a complete mess - not really interested in spending a week or two researching the latest IOS hoops to jump through in order to support Iphones etc and I've only got GLES 2.0 support on my available android device which isn't all that great - but I've got some basic stuff compiled and running on Android 4.4 and 6.0.

For now I'm dropping IOS and Android support but will maintain the basics so it can be spun up at a later date.

Finally I've looked into Vulkan support and it's well within my grasp - unfortunately Nvidia have refused to support Fermi chips! so no way to test - lets hope ATI have been kinder and supported the chip in my laptop :)

---

All in all it's looking good - I've closed off all current bugs and I'm well on the way to having the planet renderer up and running - so many different techniques to experiment with!

I've massively improved the portal rendering - I'm using it to cheat rendering through windows and the such on my spaceship - from inside or outside - Basically rather than spend aaaaages creating an interior and exterior design and a performance sapping culling mechanism to support the sparse layout - I'm just using a BSP scheme for the ship internals, roughly matching the shape of a ship model in the space renderer - then I slap a portal in the BSP level and one on the exterior ship and BOOM - I avoid tons of work both performance wise and 3D modelling wise - so what if the inside is actually bigger than the outside? unless you've got a tape measure you can't tell - so I simply won't add one ;)

To test this I'm currently flying Quake1 deathmatch level 2 (the greatest map of all time) across a terrain while on the outside it's a cube - Dr Who eat your heart out.

---

Developing my game by using the Engine and tools as designed is helping to refine both for the task - really looking forward to releasing some stuff so I can finally get some feedback and hopefully see it used!

Stay frosty.

[SilverWarior]

I don't have ATI hardware except in a laptop and I'm not getting OSX running on an AMD chip any time soon so if anybody out there is running OSX with ATI hardware and would provide testing - I'd appriciate it!

I would love to try but the last time I tried installing OSX on my computer it field due the fact that I'm also using AMD based CPU and based on information I managed to find on the web OSX suposingly doesn't work on AMD based CPU's. Os if you have any information about how to set up OSX on my computer I'm willing to try.


Finally I've looked into Vulkan support and it's well within my grasp - unfortunately Nvidia have refused to support Fermi chips! so no way to test - lets hope ATI have been kinder and supported the chip in my laptop :)

Unless this is a newer laptop I wouldn't be so optimistic. Laptop graphics drivers are unfortunately always falling behind especially those from AMD. That is the reason why I have been using unofficial drivers for my laptop graphics card. I did recently revert back to official ones since I'm no longer gaming on laptop and thus I'm more concerned by stability than performance. And unofficial drivers weren't know for rock solid stability.


I've massively improved the portal rendering - I'm using it to cheat rendering through windows and the such on my spaceship - from inside or outside

That is a great idea. I have seen it in several games and I was amazed how good it works.
Now combine this with a multi-world physics and you can enjoy seeing havoc happening inside the ship when it is hit by a powerful weapon or collides with something. ;)

[phibermon]

I would love to try but the last time I tried installing OSX on my computer it field due the fact that I'm also using AMD based CPU and based on information I managed to find on the web OSX suposingly doesn't work on AMD based CPU's. Os if you have any information about how to set up OSX on my computer I'm willing to try.

It is definitely possible but there's a lot of factors - support for your hard disk controller, graphics etc etc - there's some kexts that disable or emulate Intel specific extensions on AMD chips but it doesn't look like a common method, if you make the attempt I recommend aiming for a 'mavericks' install - has the GL4.1 support of later releases but has been out longer so you're more likely to find maverick specific quirks/patches online.


Unless this is a newer laptop I wouldn't be so optimistic. Laptop graphics drivers are unfortunately always falling behind especially those from AMD. That is the reason why I have been using unofficial drivers for my laptop graphics card. I did recently revert back to official ones since I'm no longer gaming on laptop and thus I'm more concerned by stability than performance. And unofficial drivers weren't know for rock solid stability.

You're quite right - no Vulkan support from AMD on my hardware - GCN cards only (given the actual chip generations that fall either side of the line at least some of their restrictions are artificial rather than technical limitations of the hardware - but can't really blame them for pushing for newer gear - although 2+ years feels like a con on their part)



That is a great idea. I have seen it in several games and I was amazed how good it works.
Now combine this with a multi-world physics and you can enjoy seeing havoc happening inside the ship when it is hit by a powerful weapon or collides with something. ;)


I'm guessing it's a common approach as it seemed so obvious - I had already worked on culling from one region type into another as my original design allowed regions to be embedded into others (so voxels inside a terrain allowing you to dig into the ground etc) but I thought one day "Well BSP schemes call for totally closed geometry to generate the tree - so I'm going to need some kind of portal if I want to combine them with other regions"

Then I felt like a total idiot because I was a few steps away from portals for nearly everything - an excellent tool - no engine should be without!

I'm still having issues with culling from inside voxel regions, IE a random shaped cave mouth with multiple cavities looking out onto a planet. I'm currently using a stencil style approach combined with culling against the viewing frustum but it could be optimized more.

Games such as space engineers and star-made must have a technique for this but it's hard to find any information - I'm guessing an algorithm that constructs geometry from 'holes' in the voxel chunks that's used for more optimal culling or portal generation.

I'm guessing it's safe to rule out raster based techniques for constructing portals as we'd be dealing with some expensive image processing that will require a g-buffer to be rendered first.

camera frustum with a boost from stenciling is ok for now but I have to render things such as tesselated patches at full resolution as it would be too expensive to process the image for each patch to see if it's totally masked off (patches could be heavily deformed by height maps etc) so I only get to discard fragments :\

EDIT : oh yes sorry! :) I read up on star citizen how they had external forces applied to objects inside ships and they were raving about what an achievement this was. I mean stop me if I'm wrong but in my setup, I just take the force vector from my ship and apply it to objects 'inside' right? I mean that's around 20 seconds of work - not seeing why they were jumping up and down about it.

Or I could go one step further and take the ship axis into account or even 'sample' forces at several points and blend the applied force vector between these points for any given object - have some artificial artificial gravity on a ring space station for example.

Or a blasted hole in the side of the ship could generate forces to 'suck' objects through the hole portal into outer-space - which would be very cool - surely some game already does that by now.

[SilverWarior]

Games such as space engineers and star-made must have a technique for this but it's hard to find any information - I'm guessing an algorithm that constructs geometry from 'holes' in the voxel chunks that's used for more optimal culling or portal generation.

I guess you probably missed it but Ken Software actually decided to provide access to full source code of Space Engineers
http://blog.marekrosa.org/2015/05/space-engineers-full-source-code-access_40.html
http://www.spaceengineersgame.com/modding--source-code.html


EDIT : oh yes sorry! :) I read up on star citizen how they had external forces applied to objects inside ships and they were raving about what an achievement this was.

All to increase sales. They weren't the first to use such approach as I have seen it in an older game whose name I can't remember.
What is strange to me is that such feature is pretty rarely used in space sims.


I mean stop me if I'm wrong but in my setup, I just take the force vector from my ship and apply it to objects 'inside' right? I mean that's around 20 seconds of work - not seeing why they were jumping up and down about it.

Yes that is if you are using your own physics engine. But if you are using some other physics engine which does not support multi-world physics simulation like older versions of PhysX for instance then implementing of something like this can be quite difficult.
Also you need to consider the fact that inside your ship you would probably want to have much higher precision of physics simulation than for your ship.


Or a blasted hole in the side of the ship could generate forces to 'suck' objects through the hole portal into outer-space - which would be very cool - surely some game already does that by now.

In Space Engineers blasting hole or opening a door of a pressurized compartment will generate force that will push you outward if you are close but nothing dramatic. Not sure if it affects other items (don't play it a lot lately).
About a year ago I have seen a video of a tech demonstration for a game where opening and airlock could literally such things (characters, furniture, etc) out of it. Unfortunately I don't remember its name. I'm really interested to know about how much progress has been done on it since then.

[phibermon]

Sorry for the very late reply - went through a messy breakup and did a rocky style training montage.

Also got into Software Defined Radio and spent a couple of months designing a QPSK demodulator and LRPT decoder for Meteor M2 weather satellite images - that's all in the framework now and tied into the DSP parts of my JAM audio library - so that'll be used by precisely nobody which gives me a warm fuzzy feeling inside.

Anyway back to the mansion!! the engine sorry - back to the engine.

I've cleaned up all existing code, ripped out all testing - fixed a majority of compiler warnings etc

The planet Renderer is working now although development was slowed slightly as I decided to add full GIS style support so I could use what I'd written to create a satellite tracking system + Radio heat map direction finding, then I got lost in adding support for various open source data-sets of street maps - again something that'll be used by nobody - I guess you could make a pokemon Go style thing if you really wanted to.

Back to procedural generation of planets! I'm using a cube-map style technique combined with a tessellation paradigm to render my planets so along with some 3D perlin noise and GPU based hydraulic erosion - the implementation has been quite a breeze.

I've expanded upon the Rayleigh/Mie atmospheric scattering implementation I was using for planar terrains to render atmospheres for planets - things are looking really pretty - I'm also playing around with some volumetric shadow and 'godray' techniques to try and get some sexy atmospheric projections of things like clouds and high mountain peaks - efficient and quirk free implementation is very tricky!

I'm currently brainstorming abstractions for generation parameters for planets - trying to come up with a fairly small set that will give rise to everything from rocky barren moons to lush vegetation filled oceananic worlds - I freely admit that I'm stealing heavily from concepts in 'Spore' here.

My game will involve a single planet and a couple of moons or maybe a large goldilocks moon orbiting a gas giant (which would look pretty damn epic through the filtered atmosphere) but for the sake of the engine it will of course be logically structured and capable of handling a large procedural universe.

I'll post some screenshots soon - planets and associated physics are the very last part of the engine to create - I've taken out the low res voxel implementation as mixing it with the other regions is aesthetically weird and for a pure voxel game you're always going to out perform my abstractions by coding for that style directly - one day all engines will be voxels only and it'll make everything in the engine redundant - when that day dawns I'll likely be working on a pure voxel engine.

Since it's so close to completion I'm now creating a website with documentation, examples, tutorials and all the usual gubbins that will get used be roughly nobody.

I'll be posting screenshots and videos soon and binary demos soon after that.

How long have I been working on this and posting about it now? like 8 years here? it's like duke nukem forever but hopefully it'll go down a bit better.

[SilverWarior]

I'm currently brainstorming abstractions for generation parameters for planets - trying to come up with a fairly small set that will give rise to everything from rocky barren moons to lush vegetation filled oceananic worlds - I freely admit that I'm stealing heavily from concepts in 'Spore' here.

Are you generating planets in one go or are you also using some post-processing?
When I was tinkering around the idea of procedural planet generation I never managed to generate a planet that would have so much diversity as earth does.
For instance if you go look at our "little blue marble" you can find areas with high peaked mountains and also areas with high but smooth sided mountains. You can find areas with smooth sores areas with cliffed coasts.
I never managed to convince any of the algorithms that I tried to be able to generate such diversity. I either got all mountains to be spiky or smooth but not both at the same time.

So I started doing some post-processing to smoothen or roughen different regions. For this I created another texture/height map which would control smoothing/roughing process.
And it performed quite well. The only problem was that this smoothing/roughing effect was also applied to the regions where it wasn't desired (it could roughen the valleys which would then become all spiky and ugly.

Because of that I started thinking of doing this post-processing in multiple stages for areas of different elevations. F
or instance all areas with elevation between 20 and 40 were considered as costal regions (sea level is at 30). All areas with elevation between 40 and 100 were considered as valleys. All regions with elevation between 100 and 150 were considered as hill regions. And all areas with elevation above 150 were considered as mountain regions.
Now this has been producing much more desirable results but the planet generation time has been increased greatly (even up to 15 minutes). Now this became a little concerning.
While it wasn't great concern since my plan was to be generating planets in neighboring solar systems in the background during the gameplay and you probably would not be able to reach those neighboring solar system before the planets are already generated (traveling between solar systems would take time - no warping between them).

Any way in the end I realized that wile my terrain generation algorithm can make very detailed 2D height maps with all the above mentioned variations projecting such height map onto a sphere actually screws up lots of that details especially when you are getting closer to the poles.
So I put this algorithm of mine aside and started thinking about creating a new one which would be working with spherical coordinates instead of a 2D coordinates from the very beginning. But I never got it implemented as I could not wrap my head around on how to actually make a 3D sphere from these spherical coordinates :(


planets and associated physics are the very last part of the engine to create

What is your plan for doing planetary physics? Are you planning to implement multi-body physics or will you use SOI (sphere of influence) approach as KSP (Kerbal Space Program) does?


Since it's so close to completion I'm now creating a website with documentation, examples, tutorials and all the usual gubbins that will get used be roughly nobody.


How long have I been working on this and posting about it now? like 8 years here? it's like duke nukem forever but hopefully it'll go down a bit better.

Aren't you a bit grim about all this?
Good things take time to be built. Yes you are working on this project for 8 years which actually isn't so long especially when you take into account that you are basically working on this alone. Even a half dozen sized team of experienced AAA game developers would probably spend at least a couple of years working on similar project.
So don't be too hard on yourself. Instead be very proud of yourself for this.

[phibermon]

Are you generating planets in one go or are you also using some post-processing?
When I was tinkering around the idea of procedural planet generation I never managed to generate a planet that would have so much diversity as earth does.
For instance if you go look at our "little blue marble" you can find areas with high peaked mountains and also areas with high but smooth sided mountains. You can find areas with smooth sores areas with cliffed coasts.
I never managed to convince any of the algorithms that I tried to be able to generate such diversity. I either got all mountains to be spiky or smooth but not both at the same time.

My current design is an attempt to generate successive levels of detail that are deterministic based upon the previous level of detail - this would go hand in hand with mip-map levels in a way and allow for distant planets to be rendered in low detail before moving onto generating the next level of detail.


In terms of variation of terrain I'm using concepts from the terrain generation tool L3TD - where the lowest level of detail is like a a patchwork of 'biomes' (to use minecraft terminology) which are used at the inputs for detail generation - then to make things more realistic I could have pre-rendered heightmap templates for mountain ridges and the such that are 'stamped' onto the heightmap.


Then to make the terrain more seemless I was going to use hydraulic and/or thermal erosion passes to blend things together.


There's lots of problems here of course - even with my GPU implementation of hydraulic erosion I'm very limited in the number of passes I can process on a planetary scale to keep things 'real-time'


I was thinking one cool hack would be to not process erosion on certain flat plain style areas - perhaps blending the generated heightmap with raster techniques as seen in the impressive lithosphere tool (http://lithosphere.codeflow.org/)


The key goal here is to not have to rely on generating the entire planet at any given detail level just to see one part of it while still ensuring the end result is identical for any given seed.


it's really difficult - possible of course but of those systems that do this well already? the developers are not very forthcoming on their approaches.


What is your plan for doing planetary physics? Are you planning to implement multi-body physics or will you use SOI (sphere of influence) approach as KSP (Kerbal Space Program) does?

You know I honestly don't know - KSP seems to function well at the large scales but performance isn't great (although I attribute a lot of that to unity) if you've got thoughts on the matter then I welcome them


Aren't you a bit grim about all this?
Good things take time to be built. Yes you are working on this project for 8 years which actually isn't so long especially when you take into account that you are basically working on this alone. Even a half dozen sized team of experienced AAA game developers would probably spend at least a couple of years working on similar project.
So don't be too hard on yourself. Instead be very proud of yourself for this.

I guess my confidence isn't very high of late - thank you very much for your kind words, they're very much appreciated :)

[SilverWarior]

My current design is an attempt to generate successive levels of detail that are deterministic based upon the previous level of detail - this would go hand in hand with mip-map levels in a way and allow for distant planets to be rendered in low detail before moving onto generating the next level of detail.

That was also my goal when I started thinking about creating my own algorithm that would use spherical coordinates and actually store all the data in a tree based fashion. But I haven't got far enough with implementation as I switched to other more pressing ideas like my Silver GUI library that unfortunately hasn't seen any progress for the past six months or my texture making program which needs a major core rewrite in order to allow myself to include few more desired features that can't be implemented at current state.


There's lots of problems here of course - even with my GPU implementation of hydraulic erosion I'm very limited in the number of passes I can process on a planetary scale to keep things 'real-time'


The key goal here is to not have to rely on generating the entire planet at any given detail level just to see one part of it while still ensuring the end result is identical for any given seed.

Yes doing things in real time can become quite difficult due to the large amount of processing required. That is why initially I wasn't even thinking about trying it. But my latest design idea is moving in this direction. I figured that until I put this idea into implementation the computer would probably be strong enough for it to work :D


You know I honestly don't know - KSP seems to function well at the large scales but performance isn't great (although I attribute a lot of that to unity) if you've got thoughts on the matter then I welcome them

The main problem with KSP is that it is using PhysicsX engine in software mode. Why?
Main problem is that PhysicsX uses single stage physical simulation. What does this means? Since in KSP all ships are made from connected parts physics are calculated in a way that you first calculate new position of root object based on the forces applied to it and then proceed calculating new position for other objects in a tree like manner. This is limiting the processing of any such ship to a single thread. Also until the latest versions KSP only used single world physics simulation (all ships were simulated in a single thread) while in latest version of KSP it is possible to simulate separate ships in separate threads.

Now it KSP would be perhaps using some different physics engine that uses two stage simulation there would not be so much performance issues. Why?
Because with two stage physics simulation you use first stage to just calculate new objects position and store that information without moving of those objects right away. Because of this there is no need for your to calculate physics for multiple connected objects in any specific order so you can easily spread the work across multiple threads. And once you have calculated new position for all object you actually move all those objects to their new position but you do this in the second stage.

So as noted above the main advantage of two stage physical simulation is the ability to spread the work across multiple threads.
But it does come with its own disadvantages. Main disadvantage is the increased memory requirements as you need to be able to store both old and new position at the same time.
And the second disadvantage is that second stage also requires some processing time so that the cumulated time to simulate physics and move one part/object to new location is actually higher than in one stage physical simulation. But with clever implementation of double buffering it is possible to reduce that to minimum.

And even if you could not reduce the additional time needed by the second stage so that processing physics and moving one part/object to new position would take twice as long you could still get almost 50% better overall performance if you can spread all that physics simulation to four separate threads.
Frankly I'm guite surprised why there aren't many physics engine that actually utilize this two stage physics simulation approach.

If I would be better at math I would probably try and make Pascal based two stage physics engine but I'm actually pretty bad at math :(
But if you are interested I'm prepared to work with you on implementing one provided that you take care about math and I'll try to take care about logical part of implementation ;)


I guess my confidence isn't very high of late - thank you very much for your kind words, they're very much appreciated :)

That is understandable due to recent events in your life that you mentioned before. But stay strong.

[laggyluk]

Since it's so close to completion I'm now creating a website with documentation, examples, tutorials and all the usual gubbins that will get used be roughly nobody.

if you don't expect much audience then why not release it already? at least here, for fellow programmers :P
tutorials and documentation can be added over time and user feedback can be valuable.

[Akira13]

I say let the man work in peace for as long as he needs to... by the looks of it he's actually onto something worthwhile here! :) As opposed to, you know, yet another ​horrible useless CPU-killing immediate mode 2D "sprite engine" that really just calls glBegin(GL_QUADS) followed by twenty million or so glVertex2Fs over and over and over again, even though immediate mode has been outdated since the late 90s! :p Not calling out anyone specific here, it's just a rather unfortunate "trope" of Delphi/Lazarus game engines...

[farcodev]

Yep, keep up the good work! :)