This Week In Veloren 4
The netcode was merged into the refactor! Lots of concept art has been worked on, with lots of interesting new creatures. We also discuss the weird benchmark results from last week's blog, and the refactoring of Veloren's GitLab CI.
The netcode has been merged into the main codebase of Veloren. This opens lots of new doors for development on Veloren, as it was a pre-requisite for many other tasks. The first steps now are to get the netcode working in the
client modules. Then Veloren can get a nice proof of concept working with a simple chat server.
In last week's blog, you might have seen the odd menu benchmark results that @YuriMomo got. The CPU was running at 35%, and the GPU at 40%. This is much higher than in-game, which uses 2% CPU and 10% GPU while idling. It was determined that it was this high as there was nothing capping the game to a maximum frames per second (FPS). Therefore, it was running at around 800-1100 FPS, which is as much 35% CPU is able to do.
The fix is quite simple, as @imbris showed with a simple line of code.
clock.tick(Duration::from_millis(1000 / FPS));
This tells the engine to wait until time has passed before rendering the next frame.
@AngelOnFira is working on getting automatic builds ready with GitLab CI. This gives multiple benefits to the refactor. First, it allows easy night builds of the game. Second, it allows for quick testing of new code, and better development practices. Although this pipeline has already been thoroughly written by @xMAC94x, @AngelOnFira has some improvements to add to the old system.
As code is added to the codebase, it should be tested. This helps prevent many issues, like regression. This means having code that worked in a previous version of the engine, but doesn't anymore. Well designed testing pipelines prevent this issue. By simply writing tests for different functions, we can easily detect when an anomaly occurs. Writing tests while you write the code is known as test driven development. It requires a bit more work while writing functions for the first time, but prevents many issues from occurring in the future. These tests will be automatically run by GitLab CI.
Another benefit of the GitLab-CI pipeline is building nightly versions of Veloren. A version will be compiled every day for people that want to try the latest features of Veloren, but don't want to compile the engine themselves. Note that these versions are bound to be bug-ridden, and are by no means official versions of Veloren.
One of the main changes @AngelOnFira hopes to implement is the switch to using Docker for the builds. Docker is a tool that allows each build to run in its own unique container. This prevents issues like files from old builds that stick around and affect new builds. It also allows people who want to volunteer their computer the Veloren GitLab Runner pool to do so much more easily. All they have to do is install Docker, and our image will automatically be downloaded for them. There are still some problems with @AngelOnFira's method, which are being discussed. One of the main ones is how compile time will be affected, as it is still unclear how to build the Docker images efficiently.
Lots of concept designs were worked on this week.
Essence Of Nature