But the draw distance was too close and too laggy. The game would still freeze when the player loaded in new chunks and the player couldn't see further than about 200 blocks. This was not acceptable.
The reason the engine even ran as well as it did was that of me adding Multi-Threading support which I talked about in the previous post, however, there were still many problems the engine had since it wasn't originally built with multi-threading in mind. So I rewrote almost the entire engine (important scripts like ones containing math carried over since formulas are universal and didn't need to be rewritten), but as for calculating the position of blocks, what color's they should be, how to render them, etc. I rewrote entirely.
In previous versions of my game the water had been a block type, however, I've removed it and instead added water as being a universal transparent plane so that way I could support underwater areas, which even if you didn't go into still give the world a much more lively 3D feel which is worth sacrificing the extra RAM & Graphics that rendering such blocks takes up.
After rewriting the result was this:
The sky is likely to change in the future and become a solid color due to fog implementation but for now, it looks good. The engine is able to calculate chunks in small sections on separate threads now which means the game's FPS is now more determined by graphics than chunk processing & initial rendering. I do not know if this good FPS system will remain after infinite worlds are implemented again (Because since this is a rewrite previous things like floating islands, player controller, and infinite worlds still have to be redone).
But as far as I can tell this is about as optimized as you can get, which is great! I can finally get to making things look and feel good and stop worrying so much about the processing & graphics costs of those features.
Sincerely,
Blake Gillman
No comments:
Post a Comment