New week, new Rust! What are you folks up to?
I'm working with piston on Android, and I'm going to port an old C++/SFML android snake game I made a while back to Rust/Piston
Here's a binary tree visualizer that I quickly ported for a test, note that text isn't working yet
2 Likes
A bit more game development:
-
Amethyst PR reviews: cgmath -> nalgebra, animation code ergonomics -
Hopefully get a collision proof-of-concept going in my game as well
1 Like
I'm working on an intermediary proxy for InfluxDB that will let you redirect metrics to different databases and modify fields and tags based on configuration, so you can make changes to how metrics are processed without needing to redeploy the actual apps and services generating them.
It's my first proper Rust project. Once it's working-ish I'll make the repo public and be hoping for some feedback.
Surveying some projects for their use of inline assembly. Hopefully soon Rust will have nicer inline assembly than the current "raw" semantics that's mostly exposed by LLVM.
Finally on the home stretch for flo_curves. The curve offsetting algorithm I was using was very buggy and was producing some very odd shapes as a result which was very handy for finding bugs.
I posted this sketch of Flo (flowbetween's mascot) a few weeks ago as my goal. It's a few hundred complicated paths and adding them together has always just resulted in a mess before due to random issues determining where rays enter or leave the shape, but this evening everything finally actually worked. The set of source paths are shown bottom-left, and the result of adding and subtracting them until there's only a single path is at the top-right:
I probably need to work on the performance a bit still, and there are still some configurations that produce bad rays, like this one resulting from a nonsense path from the old offsetting algorithm (ray is in red, though that's not a lot of help in spotting it in this mess. Other line colours indicate the current state of the algorithm):
I think it's the direct hit on the intersection near a point where the curve moves just barely above the ray that's caused an issue, but it's somewhat hard to tell as it's pretty hard to work out which lines are inside or outside even by hand. The circles here (indicating end points of curves) have a radius of 1px to give a sense of scale. I think it's in the nature of the algorithm that some configurations will cause issues like this, so I've added a heuristic that 'heals' any holes that might result in the boundary.
3 Likes
Currently building a web app with Gotham on the back end and VueJS on the front end with using Webpack to bundle assets. Blog to follow.
2 Likes
Naive collision:
Most of it will be rewritten though. Discovered how unoptimal my data is structured for ECS.
2 Likes
Well, it's something, I couldn't be bothered to dive into opengles_graphics again this week, so I implemented a binary score counter rather than an Arabic numeral one because text doesn't presently work, oh well.
2 Likes
Oh that sounds nice, please keep me updated on this!
I released imag in version 0.9.0
(announcement)
and am now off the grid again for another three months because I'm
traveling north america.