New week, new Rust! What are you folks up to?
Still focused on the DW1000 driver. Made a bunch of improvements to the API (1, 2, 3) and added support for more registers (1, 2). I expect more of the same this week, until Iām capable of wirelessly communicating between two modules.
Trying to get acpi
into a useful state by parsing some more AML. This library is meant to fulfil a similar role to Intelās ACPICA and can be dropped into a Rust kernel to provide ACPI support, but it needs far more work to be feature-complete.
An aside: we have a couple of easy issues (1, 2) if people wanted to get their feet wet with some kernel library development!
Iām still working on my weather station. Recently I have been trying to reduce the power consumption in idle. I managed to get it down from 150 mA to 2-3 mA with 150 mA bursts. This week, I might try to reduce it further by putting the CPU in STOP mode.
I would also like to improve the way I handle timer interrupts right now. My current strategy requires a static mut
variable and a bit of unsafe.
Working on my rendering engine and adding features. My top priority is to include the weighted screened Poisson reconstruction for my gradient-domain path tracer (G-PT). At the same time, I need to correct my G-PT as the direct light seems incorrect.
If I have a bit more time, I would like to look at how rs_rust load PBRT files to render more complex scenes.
Iāve started introducing another one of my colleagues to Rust (R.E.S.F. take note!), so he can use zlib (via zlib-sys) to write a bioinformatics tool to split fastq files.
This is harder than it sounds, because itās a multiline format, thereās two files you need to split in sync, and you can introduce downstream biases if you do the splitting naively/on the sorted data.
Itās so much fun too show him all the wonderful resources Iāve gotten to know over the years of being active here
Heās immediately dived into the whole FFI corner of the problem, and as such, his questions are also challenging me in a corner of Rust Iāve avoided so far.
New Rustacean here, learning Rust one step at a time!
Iām at chapter 9.3 in the book right now, while also working on āsm ā a static State Machine libraryā, to apply what Iāve learned from the book.
This week Iām porting the library over to procedural macros, which is a lot of fun to experiment with (especially while using the syn
library), it helps me understand Rustās structure better, which in turn helps me better reason about my code.
Iām also experimenting with the structure of my Rust open-source projects, what should be in the code of conduct, how to best use CI together with Rust, how to do testing and benchmarking, what to document where, how to set up Bors, release management, etc. Not always code-related, but equally (if not more) important for any open-source project in my opinion, and also fun to figure out.
All of this is part of a 2-3 year long project Iāve started a month or so ago, towards building an open-source game about space engineering and exploration, written in Rust (working title: Rusty Rockets). Not much to share on that front yet (except for many pages of wiki-like documentation that Iāll also open up a few months from now), but my intention is to use all of the tools/experiments I build while learning Rust towards building the final game(-engine).
Making a map selection UI for my game, which happens to be refactoring code to an emerging pattern that supports:
- toggling optional view crates (in terms of MVC). View crates can be UI, stdin, or some other connector
- do that in ECS
I may have a few answers although Iām nowhere near the expert level of many Rust developers (contact: 6ftdan on Twitter). My FFI experience stems mostly from my Rutie project hooking Rust directly into the Rubyās language C bindings. Rutie is a fork of Ruru and Iām not the original author but have contributed much over the past year.
What Iām working on this week is porting over the AEScrypt.com command line tool over to Rust as a library. Seeing as Iāve learned most of C merely by reading Ruby source code Iām having fun writing the Rust code with the same pointer logic that the C code in aescrypt
is using such as using pointer addition. Once the program is ported over Iāll be refactoring away from pointer logic⦠that is the plan anyways. Of course working with raw pointers this way is new to me so Iām very much enjoying learning from this experience.
I am still working on JNI binding for Zbox (a privacy-focused in-app file system). My goal is to make it to be able to run on Android. Java things are so tedious, luckily with help of jni crate, JNI binding for rust became easy.
Iām interested in contributing with FFI bindings for datrs/hypercore, specially for Java/Android.
This week Iām trying to get started with a JNA (instead of JNI) library for Java and Android using Gradle and multi-projects and it is not being quite simple so far.
Iāll definitely want to check how your integration is doing and learn from
Still working on my roguelike when I can spare the hours. Itās not yet all that cool to play with.
Right now Iāve implemented menu systems (but I want to make them a little nicer). I have designed the framework and interface for the World
component and the WorldChunk
s that it manages.
Iām looking at examples of how people have used entity-component systems in games. Itās at once familiar and different. Iām exploring what the best way to implement one is in Rust and for my purposes (not necessarily needing to be some super abstract and portable library. maybe I can benefit from trait monomorphization?).
Have you looked at the specs crate? I'm not at a point yet where I can use the crate, but it's definitely on my list of things to check out.
Fixing up a few minor issues that I skipped for my cgroups crate. By the end of the week, Iāll add a builder pattern so that itās even easier (and more ergonomic as a result) to use control groups.
Other than this, Iām working on a network bridging crate. Hopefully, we will be able to use bridges in rust networking code soon.
Thatās all for this week, Iām travelling the whole next week, so most of my week is preparingā¦
I definitely will, but part of my objective is to get some solid Rust experience. I think this is a fun thing to experiment with.
There also might be facets of my particular game that would lend to a more optimal fit if rolled myself. This is a hobby project, so I can microoptimize any silly thing I want (and ignore things I find tedious).
In the end, using libraries instead of implementing everything is generally a good idea. Iām using pancurses and serde-cbor already (those are the tedious things I donāt want to bother with).
Iām looking forward to seeing your work come to fruition as well! Good to see others with similar goals.
And itās also good to see such a wide variety of work going on. This is a diverse set of things people are working on.
I agree, and a big part of the fun of learning Rust while developing a game is the freedom to do whatever you want with your piece of software and the time you invest in it. Like I said in my "what have you been working on" post, I've spend the last two weeks working on, and refining my static state machine library, not because there are none available, but because I want to learn, and try to get as much performance out of it while fully utilising Rust's type system.
So yeah, perhaps when the time comes, and there's Specs, and you've written your ECS library, I'll go forth and write my own as well it's all in good fun, and writing these small units of code certainly improves and refines your Rust skills, which is exactly what you want, as you build up to the more complex layers of your game.
Still working on Bezier curve algorithms for FlowBetween. Iāve got 60% of a GraphPath
type implemented (representing the intersections between two paths), but Iād originally written a curve-curve intersection algorithm based on bounding boxes expecting the problems to be mainly around performance but found that accuracy is a big issue too, so Iām adding the classic Bezier clipping algorithm to flo_curves.
To put things in context, hereās a sketch of FlowBetweenās mascot, made in FlowBetween:
This is a good test for me because itās around the level of complexity of things that I want to work well in FlowBetween.
As itās a sketch, itās made up of a lot of Bezier curves and right now renders too slowly. Iād like to be able to render things of this complexity at 60fps ideally but around 12fps is the minimum target. Right now, this gets around 3fps. Partly thatās due to the line offsetting algorithm Iām using, but also even though chromeās canvas is pretty fast itās not really happy with rendering several hundred paths (incidentally the performance is about the same in Safari on an iPad Pro as it is in Chrome on an iMac, which is impressive). The fix Iām working on is to add all of the curves together and generate more complex but fewer paths so the renderer can do everything at once (which also provides a way to bypass the slow offsetting algorithm if the result is cached)
This is also something that would be useful for the final SVG output as even after a sketch like this is cleaned up itās usually necessary to simplify the vectors and this is a way to do that automatically. Even though itās a vector tool, I want it to be usable in as āpainterlyā way as possible.
Watch this Video https://youtu.be/aKLntZcp27M I think this will help you a lot as the Talker is from Chucklefish
Here we go, itās the end of the week (in NZ):
perhaps next time Iāll just post at the end of the week