Feature Upgrade Environment Mechanic - Optimizing Dwelvers (Work in progress)
Time to get technical Tongue

If anyone is wondering why I am being a little inactive here at the forum it is because I am in the progress of doing some FPS optimizations to Dwelvers.

This is usually a little bit tricky because it is easy to put down huge amount of work on something that I think will make the game run faster even if it don't.

What I have been doing the last two days is to get the game to render the static models (like rocks and so on) in chunks like (5x5x5), this is not a new idea and it is widely used in Minecraft for example, the thing is that when coding game I want to keep the CPU from making too many rendercalls to the graphiccard because this is expensive. And being able to render a (5x5x5) chunk instead of one chunk at a time will lower the rendercalls with 1/125. This is a a optimistic viewpoint as there are always models in the dungeon that are in constant movement and can't be rendered in a chunk with other models.

Well, the result of this is that I got the rendercalls down with at least 1/4, which is really good, bear in mind that these chunks only affected static building models and items. Then we have all the rendercalls to the creatures, their equipment, 2D rendering and so on that also plays its part. So a better way to look at it is that I got the rendercalls from 25% of the models being rendered to 1/125.

So how did this affect the FPS?
Almost nothing...
This was very frustrating as I know that the rendering plays a part of at least 80% of the frame rendering time while the update only takes up 20%.

So what went wrong?
After doing some profiling I realized that even if these chunk models lower the number of rendercalls, they did increase the amount of data sent to the graphic card. Each chunk consists of several wall models made into one model, this means that if a wall model is 10kb in size and I render a chunk I may have to send over 20 wall model = 200kb to the graphiccard, while if I don't render it in chunks I just send one wall model over and moves it around 20 times. So when the number of rendercalls got lowered so did also the FPS, but then the FPS got higher because I had to send over a larger amount of data with each rendercall to the graphiccard... Argh...


With each failure comes new ideas. Right now I am working on having the amount of data sent to the graphiccard lowered, I came up with a way to have all the models sent to the graphiccard in loading time and never be sent again. It is like the dungeon color texture in the media folder where I had all the textures for all the buildings collected into one bigger texture to avoid to much texture swapping in runtime. It works the same with the models, I create one big model out of all the models in the game (about 36mb) and load it into the graphiccard in loading time, then when I render them I just point at the memory address where one model starts and one model ends. If this goes well it should lower the amount of data sent to the graphiccard a lot, at least 15mb less data sent each frame. But I don't know until I have tried it, I still have a couple of hours left of work before I can see it in action.

When it comes to rendering in chunks I will still keep it when it comes to rendering items on storage tables etc. These are usually lowpoly and get rendered a lot, so this did give it some performance boost.

Stats right now (needs to be looked in relations to eachother, when I do the profiling there are some functions involved that forces the GPU and the CPU to sync, therefore the FPS is lowered while I do this):

Total time: 0,05523 sec.
Rendering time: 0,05066 sec (91,7%)
Updating time: 0,00457 sec (8,3%)

I will post the new stats as soon as I get this new thing in, hold your thumbs for me Smile
I am finally finished optimizing the game (for this time), it took some time and there was a lot of things to do.

I first fixed it so that all the models got uploaded to the GPU in the loading process instead of having them uploaded in real time.
Then I fixed so that all the models got instanced better, meaning that the GPU rendered a lot more buildings and models at once with one rendercall.
Then I sorted the building models after their textures, so that buildings with the same texture got rendered after each other so that there will be less texture swapping.
Then I organized the skinned models (animated creatures and so on), so that their textures got packed with other textures, also to lessen the texture swapping.
And finally I fixed with the camera frustum culling so that it worked in 3D as well. Previously it only checked if a a tile with all its layers was visible for the camera, now it checks the layers as well.

All these changes to some time to do as you can imagine, but I did manage to get the FPS up quite a bit.

The new stats is:

Total time: 0,04549 sec.
Rendering time: 0,04082 sec (91,7%)
Updating time: 0,00467 sec (8,3%)

Witch is a 21% increase in FPS.

Then I tried it out without all the debugging parameters on and found that the FPS had increased a lot more than I first though.
Previously when running a specific level that was pretty large and packed with items and creatures I had 35 fps.

Now I have 57 fps, and that is an increase with 63% witch I find quite good Smile

Well that is all for now, I hope you will notice the boost with the next version, there are still ways to optimize the game even more as there are a lot of unused threading possibilities to take advantage of, and a lot of options to add that could decrease the graphics quality for a higher fps.

One more thing that is already sort of implemented but will require a lot of tedious work is to create lower poly versions of all the current buildings in the dungeon that will be rendered at far distance instead of the higher poly models, this is already done with the walls in the dungeon, but as the polygon count can go up to 2 million I know there are a lot of other buildings that could need this treatment as well.

Next up I will take care of the current bugs, then I wills start implementing the equipment system.
This sounds really promising. I'm interested to see how much this impacts the performance of the game when I do really large excavations. I have a pretty strong PC so I don't really experience many performance issues except when large excavations are concerned. I have a feeling that issue relates more to how job assignments work, but with all the materials on the ground, the improvements in render calls should make some visible improvement to performance. Can't wait to check it out.
I have no idea what you said in either of your posts, Rasmus Tongue
But, if it means any boost in performance for Dwelvers, I say carry on with your nonsense mumbo-jumbo
The time of Titans is over... now, the throne of the World is ours for the taking... and I intend to be the next one to look out over the mountains and oceans from that crystalline perch. Stand with me, and a million times a million souls will know you as one of the Great Lords and Ladies of ancient legend... or stand against me, and be left as little more than a smear of ash amidst the dust of history...
That's why this thread is not in news. :p
People complained about fps optimization, but if you want to talk about it, well.. it has to be said in technical terms. Anyway I think that's enough to said everything goes well:

Rasmus Wrote:Witch is a 21% increase in FPS.

Then I tried it out without all the debugging parameters on and found that the FPS had increased a lot more than I first though.
Previously when running a specific level that was pretty large and packed with items and creatures I had 35 fps.

Now I have 57 fps, and that is an increase with 63% witch I find quite good Smile
Spec: Win 10, ATI 7800 HD, res: 1280x1024x75. I support The Venus Project & Resource-Based Economy
I am sorry, but I really got hooked on this. I am still optimizing Dwelvers.

Something that have bothered me a lot lately is the laggy mouse cursor. The reason for this is that the graphic card always is about three frames behind the CPU, so when I give the graphic card the current cursor location it will not render it in that location until three frames has passed, and this is very obvious when the framerate goes down.

I could do it so that I just change the windows cursor icon graphic, but for some reason I can't get it to work in fullscreen.

So I went down another lane...

I was able to thread the GPU so that one part only have a hand in rendering the mouse cursor and one thread only rendering the game. This worked surprisingly well Smile So in the next update, even if the game is down on lets say 10fps, then cursor will still be updated in 60 fps without any lag, it gives the player a lot more control and the game feels much less heavy.

I am not quite finished yet, this got me really motivated in trying something else. So right now I am doing the same to all the menus as I did with the mouse cursor, if all the menus gets rendered separately from the game, then we could have these running at 60fps as well without any lag, that would enhance the feeling of control for the player even more. I am trying to get this finished up as soon as possible and after that I will get back to fixing the current bugs.
Do you think you'll post a revision update before working out the current bugs, or after? Maybe your optimizations have cleared some of the current bugs already? That would be cool if it did.
I will try to get a "sneak" version out there before continuing with the bugs. I am a little worried that all the changes I've made could be incompatible on some computers. The faster I get it confirmed the better.
Yeah, well I play on 3 different computers so I could get a good run through for compatibility purposes. Each runs a different brand of video card: Intel integrated, ATI, and nVidia. You could post it to the member's page so we could get a run through before it gets pushed to Steam.
I just have to ask, have anyone noticed any performance boost in the 0.8g version? Tongue
I think it is running much better, but there is still a big performance hit during large excavations. Workers really need to prioritize delivering goods to rooms over delivering items to storage. This causes food stuffs not to be delivered to tables, starvation, and a lot of pissed off minions. You end up with a lot of bones and leather tho which is cool. I can always rebuild the population...

Forum Jump:

Users browsing this thread: 1 Guest(s)