New week, new Rust! What are you folks up to?
Still working on Von Neumann Defense Force. I missed last week's thread, so here are the highlights of the last two weeks:
- Making slow progress on the new wgpu/lyon/winit frontend. The main work is still separating ggez-specific code from frontend-agnostic code that can also be used by the new frontend.
- Cleaned up the physics code. All units are now based on meters (was arbitrary/undefined before), objects have actual mass (was implicitly assumed to be
1.0before), and the gravitational constant has been set to its actual value (used an arbitrary value before). - Simplified the orbital mechanics. Before, objects in the game were affected by all sources of gravity (although in practice, there was only the one planet). That complicated things a lot. I decided that I'm not going to invent an efficient solution for the n-body problem, and going forward, I'm going to use patched conic approximation.
- Always spawn ships in a circular orbit around the planet. Before, they spawned without any relative velocity in relation to the planet, so unless the player grasped their situation really quickly and used their knowledge of orbital mechanics to counteract, they would just plummet towards their death on the surface.
- Draw full orbit of a ship, instead of its projected path for the next minute or so (this was enabled by the orbital mechanics simplification).
- Changed the planet's mass and size to realistic values (those of Saturn, to be specific). This made the game a lot more boring, because nothing seems to move (trust me, it does, just wait 10 minutes or so). This will have to change again. It's a process.
- Changed controls to be a bit less immediate (before it was more liker Asteroids, now you press a key to enable the engine, another key to disable it).
- Switched from cgmath to euclid.
- Lots of other cleanups and fixes.
I've finally got the new storage layer in shape for FlowBetween, so I've moved the editing operations that were giving me trouble before from the tool layer to the actual animation layer.
This means I can move on to working on some UI things. One thing I want to add is a frame display, but the new design should also let me do some work to improve the fill tool and add the ability to group and ungroup paths.
The new storage format makes it easy to serialize and deserialize edits so debugging and testing is now hugely easier.
For instance, an important feature I want to get working is the idea of FlowBetween being a 'painterly' vector editor where it's not necessary to mess around with control points to reshape paths. So the brush tool has this icon: 
which indicates that brush strokes should be automatically added into a single path. For closed paths this has been filling in the interior for a while, so a circle with a cross in it winds up looking like this:
This was a pain to debug before because it really only occurred via an interactive part of the application. Now all the editing operations can be dumped out, I can debug this and re-run all of my original edits in a new file:
... well, now the bug is a raycasting bug in flo_curves, so I've got that to track down as well at some point. (These tend to be floating point precision issues so I'm really glad I can turn any buggy file into a reproduction)
I've been working on a little utility to split MKV files with FLAC audio track payloads by chapter breaks, since I've recently discovered that mkvtoolnix can't handle them properly. The basic idea is that - since mkvtoolnix can't split FLAC frames - I'll convert my files to raw PCM payloads, perform the split, then re-convert the split files back to FLAC payloads. PCM data is trivial to split and all the conversions are lossless.
My utility is mostly just gluing together other programs with Command calls so it's not much on its own. But it does involve a number of temporary files. By implementing the Drop trait to delete them when finished and making careful use of ownership, Rust has made it easy to ensure none of those big temporary files stick around any longer than necessary.
It's the sort of thing I might've reached for Python to solve in the past, but I'm now implementing in Rust instead.
I've been working on embedded Rust, in particular building a drone motor driver. Blog post with demo. There's much more to do and I'm finding Rust to be fun and productive on these tiny devices.
1 Like
I released the first version of Yew Prism it is a highlighter code component based in prismjs for yew
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.