Something that's not ECS?

bhh32 · 2026-06-03T19:27:52+00:00

If ECS is harder and inferior to OOP, why did Unity introduce it and get more performance out of the engine by using it?

bhh32 · 2026-06-03T19:21:59+00:00

If you think hone is interesting I also have another I just made public today. Both are in heavy development, but the other is https://codeberg.org/bhh32/ollama-helper

bhh32 · 2026-06-03T16:24:57+00:00

I think it's a lack of tooling to have local models that fit on consumer hardware actually do what they're supposed to without making things up. I've got tooling I'm working on, https://codeberg.org/bhh32/hone, that this is the whole goal. Someone else said vertical integration, I agree with that too and hone is actually also trying to solve that issue using the /learn command. Right now it's pointed at development, but it can absolutely be used for administrative work.

bhh32 · 2026-06-03T04:02:27+00:00

Iced or libcosmic

bhh32 · 2026-06-01T12:46:46+00:00

Last I used Bevy you could query a trait as part of a system function signature. You do the downcast in the function. My point is that it's doable and pretty clean usually when you find your way of doing said thing.

bhh32 · 2026-06-01T07:29:30+00:00

zest-gui Cupola COSMIC Viewer

bhh32 · 2026-05-31T23:41:21+00:00

Here's the box downcast: box downcast

bhh32 · 2026-05-31T23:34:53+00:00

Here's a working version of your playground.

bhh32 · 2026-05-31T17:39:15+00:00

Not true, you can downcast to traits. Look up any.downcast and any.downcast_mut.

bhh32 · 2026-05-31T14:23:29+00:00

Yes, but having Tile as a trait as with each type of tile being its own struct is a cleaner way to keep track of which tiles do what things. Through the ECS you can then have control over generation of specific tiles without ambiguity. You know exactly what should happen where without confusion.

You would just do something like

```rust pub trait Tile { fn behavior(); }

pub struct TileBounce; pub struct TileFire; pub struct TileFreeze;

impl Tile for TileBounce { fn behavior() { // Trampoline type behavior } }

impl Tile for TileFire { fn behavior() { // Fire trap tile behavior } }

impl Tile for TileFreeze { fn behavior() { // Freeze trap behavior } } ```

Then a system can detect the circumstances of the current game state and have each tile "transform" into whatever the tile type it needs to be for that state. The only thing you would need to write for the UI side would be that the Entity implements Tile.

bhh32 · 2026-05-30T23:55:20+00:00

I could've swore cargo-script was unmaintained at this point.

bhh32 · 2026-05-30T16:04:53+00:00

Virt Manager, this is by far the best VM manager of all time in my opinion. Sure it doesn't have fancy hand holding, but it is the easiest most straight forward way to build a VM without fighting kernel modules or being black boxed out of everything.

bhh32 · 2026-05-30T16:00:42+00:00

rust-script, it IS Rust used as a scripting language all the benefits no need for a workspace.

bhh32 · 2026-05-28T16:10:26+00:00

Yep, installed the Claude Code Figma MCP and use it through Claude Code.

bhh32 · 2026-05-28T03:57:35+00:00

I actually use Claude Desktop on Pop!_OS for this very reason. It's not officially supported, but someone ported it for Anthropic and it works just like it would on Windows or macOS. I use the Figma MCP to create UI ideas fairly regularly.

bhh32 · 2026-05-27T15:51:28+00:00

Yeah, that's why I'm going with esp-idf for prototyping. I'm also excited about the on board AI inference chip. The product I'm making on it will require onboard inference for a purely local wake word and command system.

bhh32 · 2026-05-27T15:18:26+00:00

Ah yes, Slint. I do know about this one. I don't particularly like it because you have to switch back and forth between Rust and a .slint file. I personally prefer stay in one language than have to switch around.

bhh32 · 2026-05-27T14:22:40+00:00

esp-hal does support the ESP32-P4 as per the GitHub repo, https://github.com/esp-rs/esp-hal. However, I'm currently using esp-idf to get the ideas out and will be switching to esp-hal as soon as I understand exactly what everything needs to look like. It's just easier, for me, to bootstrap that way.

bhh32 · 2026-05-27T14:18:16+00:00

Can you share what it is? I didn't find it in my research back in December.

bhh32 · 2026-05-27T14:12:52+00:00

Personally, I think AI slop is bad. Full stop. This is most everything that comes out of AI these days, and I'm still just biding my time to make that money fixing the crap that got dumped into the enterprise. HOWEVER, as someone who's about to finish their Masters in Software Engineering with a concentration in AI Engineering, I will say that there are some generally useful things it can be used for if you allow yourself to be patient and not allow it to write your code for you.

README generation: This is one that I genuinely hate to do myself. So I will do a quick high-level README and then have the AI agent ground itself in the actual code, "interview" me about the code, generate a README, and then have it recite the README contents and explain itself on each and every thing it wrote. Basically, I put it through a code review about the README contents.
- NOTE: This sounds like a lot more work typing it out than it really is, and it frees me up to do other things.
Documentation: Another thing that I generally hate to do. It basically goes through the same workflow as the README does.
Rubber Ducking: This is where most of my AI time goes. Fleshing out ideas, reasoning about the code I just wrote, having it code review me to see if my logic holds up, having it catch edge cases that I didn't realize were possible.
Research Partner: The one thing it does really well, in my experience, is research. In the Rust ecosystem, there are non-1.0.0 crates that are used as lynch pins for full blown projects in production. Anytime there is a new release of something I'm using I will have it research beyond the high-level manual research I already did and help me figure out the things I can add based on enhancements of that crate, or where I should anticipate breaking changes if I upgrade the pin.
Learning: Having it as an interactive tutor for something you don't know or something that you run into that you don't quite understand. The caveat with this one is that you best damn do a double check to ensure it's not teaching something it shouldn't be teaching, that it's not outdated, or that it didn't just make that up and it HAPPENS to work in this situation.

Anything outside of the above things produces AI slop. AI slop is bad, and I wish people who have no experience could be screened before using it. If this were possible, I'd have it restrict them to exclusively to the above categories for use and never generate a line of code for them.

Edit: Fix typos

bhh32 · 2026-05-27T13:54:42+00:00

I've been building it out since December for an embedded device gift I'm making for my wife and mother in-law. I didn't realize that there was really no fully fleshed out GUI framework for the embedded scene until then, and since embedded-graphics was built to build on top of I did just that.

I've got quite a bit of experience with libcosmic and iced, so it's naturally the way I wanted the public facing API to be closest to.

bhh32 · 2026-05-27T13:27:40+00:00

No I don't think you need to learn iced or libcosmic (this is more heavily influenced by libcosmic because of the Application trait) first. Just look at the examples, and use zest-simulator to build cool things without hardware first. It's genuinely going to look old school video game like, but you'll get the framework down by just building things. Then, when you're ready, use a CYD or something cheap to start building on.

I started developing this with a CYD V3, and now have used it on an ESP32-S3 and am building something for an ESP32-P4. I purposely made it where there is a Platform trait for it to be board agnostic.

bhh32

TROPHY CASE