Speiger
patreon
Next Performance improvement
🕑 Added 2019-07-22 15:43:55 +0000 UTCWell this time I am kind a late on my 2 week post, yeah let's keep that as a one of.
Tile Ticket Changes:
Since the last Post where I was doing the Tile Change upgrades there were other improvements that I had to make.
So after the Render Ram Usage was Improved my next project was very clear.
Find the next big memory issue and solve it. The biggest issue that I found was the TicketSystem.
It was a Object that was containing a bit of data and was managing the Updates.
The System wasn't ideal because 16 Million Objects would take a lot of data and slow down because of that. So a solution had to be found.
The idea of the original TicketSystem was very simple: Only do updates when necessary so the CPU is not constantly checking everything on: "Hey do you need a update?"
Instead the Tile would say the world: I need in X amount of ticks a update, this would be indexed into the right position (via a map) and then executed when the right game tick was found.
Less stress for the CPU overall.
The new solution was a bit complex to find about but after thinking about it something at least showed up.
Here is the thought process. Usually update requests have only 3 variables.
- The Time when it should be executed.
- The X Position of the Tile
- The Z Position of the Tile.
Since the Time was not stored in the Update request itself but was just a indicator for where to place it in the map. I only had to deal with the X&Z coordinate which would fit into a 32Bit Integer.
My maximum capacity was 64Bit so half of it was used, I still needed to have some info about the "TicketID" and also some info about what processes the Ticket Itself.
A Ticket Registry was added, 4 Bits (16 processors) are now used that makes it 36Bit leaving enough room for metadata (28bit) and the Ticket itself could generate out of the data the TicketID.
So I have now a ticket system that only processes request. Each request is 8Byte big and has enough room that custom implementations can be added and it saves a lot of ram.
Around 2-3GB in the largest map were saved. Allowing the largest Map to be very close to the hardcoded limit.
Before it was 3-5GB of ram on 4096x4096 map with every tile being used and a ticket full of requests (16 Million) now thanks to that system we have the 5GB mark for a 8192x8192 Map.
Which will be never reached in the first place because not all tiles are being placed but this does not include GridEntities (Tiles with custom data like a inventory).
So overall a massive improvement.
Also the game can thanks to this improvement process around 130k simple tile tickets within 5 Milliseconds. (On normal speed you have 50ms per tick).
Render Cache rewrites:
After that there was one feature I needed to finalize since it was Tanking FPS massively.
That was how I was handling world changes.
Before the new version I was basically applying all changes to the world directly to the GPU, that means the GPU was aware of anything that would happen in a world. This allowed for a smooth moving without any issues since it was all prepared.
But massive spawning of Objects would kill the GPUs speed for the whole reason the changes were to big.
A new System was required.
And that was thanks to the Chunk Batch System pretty easy and confusing because I was thinking like a moron xD
The idea is now Dump all change requests if they are not within the view range of the Camera, and if the Camera runs into new areas just request the chunk to build its batches.
Then there is a Queue that priorities stuff that is near the camera or no longer valid (to dump it). And process around 1-2 Milliseconds of changes up to 3-4 times.
So if you are moving the nearby stuff is always up to date and the further you go the less priority it gets.
The system is so fast that it will support a 20 chunk radius even with fast movement quite easily. Even so you can see the renderer catching up.
Of course this had a massive effect on the Memory too because less stuff to track on the GPU, that meant no longer Garbage collection calls in 4096x4096 maps
So overall massive improvements.
What I have to decide is how I will do the camera in the end because right now it is somewhat of a free cam. Which forces me to support long distance rendering which basically maxes out the Geforce 1060 that I have to its limit quite easily.
But that is something for another time.
Other stuff:
Yeah this was about everything for right now. Though this was only 1 week worth of work. The second week I was working on another project which I should finish next week enough to finally continue on my game.
So do not expect to big of progress.
Thanks for reading Speiger.
