New week, new Rust! What are you folks up to?
This week I’m going to implement some basic campaign menu and nerf the AI a little bit.
Working on Part 2 of my gfx-hal tutorials - this time on vertex buffers.
The code for it is already (I think) done: part02-vertex-buffer.rs - and I'll be writing it up this week.
On crates.rs I’ve added information by removing information.
When I list dependencies I don’t show the required version, if that’s the latest version and at least 75% of all crates require that version too. This hides all “boring” version numbers, leaving visible both cutting-edge updates (like futures 0.2) and outdated dependencies (example).
Working on the DW1000 driver. Spent some time on design work last week (and trying to implement wrong approaches, which I guess is design work, too ), but now I’ve mostly figured it out (for now) and am back on implementation work.
So far I’ve worked on extending the macro that generates the low-level register interface, so it generates a type-safe low-level interface, similar to what svd2rust does. I have another upcoming project this week, so I don’t think I’ll make much more progress until next week.
Finishing touches on the cgroups (https://crates.io/crates/cgroups) crate I released last week. There’s still plenty of stuff that remains to be parsed properly and my aim for this week is to get that done into a nice, Rust-y interface.
Besides this, I have a bunch of ARM boards that I will set some networking gig up. As part of the Networking WG’s embedded efforts I’d like to explore what can we do to make baremetal networking better.
Finally, some work on a secret advent project!
I’m in the early stages of a roguelike. https://github.com/Axelderan/zolnoa
The menu system is pretty much the only thing with any design permanence. I’d be grateful for an early code review of just that.
Again, it’s very early in. However, this is the first time I’ve written a curses application.
I’m still plugging away on the bughunt project, specifically experimenting with combining a fuzzer with quickcheck techniques: ongoing discussion. I’ve made a fork of arbitrary to introduce a finite source of bytes – the only source now is a ring of bytes – which I hope will simplify introducing a shrink step into the fuzzer/QC combo.
I've just replaced the textarea with the experimental text-editor I've been working on last week.
I have published my first proper crate (vk-sync)!
In an effort to make Vulkan synchronization more accessible, this library provides an efficient simplification of core synchronization mechanisms such as pipeline barriers and events. Additionally, these usage types provide an easier mapping to other graphics APIs like DirectX 12.
Currently, this library just maps over to types in the
ash crate, but I plan to add other ffi bindings to it as time goes on.
Updating the ID types of assets in my game, so that I can reference them by “namepace/name” instead of
u32s. That’ll make it easier for automated testing, and saving/loading games wouldn’t depend on when this object was loaded.
It’s a step towards controlling state transition and characters using stdin, so in the future I can do something like:
./game < test_menu_navigation ./game < test_multiplayer_local ./game < test_multiplayer_network_win_linux ./game < test_multiplayer_network_linux_osx
Automated testing looks fun, the first few times you see it:
I'm going to work on issue 56 which aims at rendering this scene:
I might split the work into several tasks/issues to document the progress ...
I’m planning to release a new version of
uom (type-safe zero-cost dimensional analysis) after doing a final review of the changes and writing up release notes!
Some progress on the VW scene:
Plan to make some webcomponent that utilize Rust on it
Creating an API binding for messagebird SMS sending service: http://github.com/drahnr/messagebird-async
That looks amazing! I love games like that. I’ll definitely look into this from Time to Time