New week, new Rust! What are you folks up to?
We’re only two issues away from our v0.1.0 MVP release for Evoli, an official showcase game for Amethyst.
Only wall avoidance and a basic feeding system remains (beginner friendly).
1 Like
Adding segmentation faults sound to my game. Unfortunately automated tests trip a segfault on Windows, haven't checked on Linux yet. Please feel free to help 
:
1 Like
After commit 5bae010 we see for the first time some structure in the rendered cloud, but it's still very different from the C++ version:
See issue #92 for details and updates. That's what I'm working on this week ...
1 Like
I've been working on improving the performance of the path arithmetic functions in flo_curves. It seems there was a lot of book-keeping, in particular allocating and freeing vectors: I got a lot of mileage by using smallvec in the various inner parts of the loop. It also seems that although Rust inlines .map and friends, it's still much faster to use a for loop than construct an iterator using the functional methods.
Apart from that, I got a big performance boost by adding a method to add many paths all in one go, which moves the bulk of the work to the bezier curve collision detector from the ray casting algorithm (adding paths one at a time duplicates work by finding the same edges multiple times). One problem with this is that it makes the ray casting algorithm work on a much more complicated scene, which finds edge cases (literal edge cases, being what the algorithm is...):
(Rendered as multiple paths on the left and as a single path on the right)
There's a missing collision somewhere in the tail here, and a similar one affecting subtracting the erased areas from the head. Hopefully they're the same issue, and hopefully not too dependent on floating point precision issues... I'll be spending some time this week tracking these down. I think I can get even more performance by combining the add and the subtraction operations into a single ray-casting action (right now, subtractions are still single actions). So far the whole thing is around 6 times faster than it was a couple of weeks ago, and there's definitely still room for improvement.
I finished the task/issue and was about to release a new version when I was bothered by the performance (in comparison to C++). Using perf I figured out that changing a couple of lines made a huge difference, now the render times allow me to use 2048 pixel samples with a realistic render time (about 1h):
I think the grid (100x100x40) is too low res, which is responsible for visible voxel boundaries, but I might post some other results with a higher grid resolution. The resulting image matches the C++ code though.
Added Forge support to my Minecraft-compatible client, Stevenarella:
It has some support for custom modded blocks (picture in this screenshot is "rockwool") and can connect to Feed the Beast servers. Still a long ways to becoming usable for normal gameplay, but it was a fun exercise implementing the network handshake and custom block in Rust (makes use of a huge macro to define all the blocks and their metadata):
https://github.com/iceiix/stevenarella/commit/e9b336192a238f89f5da122982a6802d77379e32
I am looking forward to Amethyst and WASM developments, hoping their work will help allow me to port this glutin/winit/OpenGL-based project to the web.
2 Likes
Playing around with ideas towards a special-purpose cousin of std::time dedicated to the unusual needs of task scheduling (fast manipulation, high precision, low timestamp memory footprint)
EDIT: Published a first draft, feel free to share comments on it!
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.