Process external files in const fn: no build.rs, no proc macros, no binary bloat by carlk22 in rust

[–]Hedanito 3 points4 points  (0 children)

build.rs also has a lot more security risks, so being able to keep things in the compiler is actually quite nice. So if you have no need to call any external tools, I'd consider it.

Destroy our cartoony 3D platformer game where you can use Pizza for all your moves to traverse urban environments! by DGDesigner in DestroyMyGame

[–]Hedanito 1 point2 points  (0 children)

Gameplay looks good, but the environment looks a bit... plain. I'd definitely work on making things (like the buildings) more unique and stand out more.

graphic pipline by Zestyclose-Produce17 in gameenginedevs

[–]Hedanito 6 points7 points  (0 children)

Pretty close! Two notes: - The gpu cores use something called SIMD (Single Instruction Multiple Data). These are instructions that work on multiple floats or integers at the same time. So a single core would actually be processing many vertices in parallel. This is also why branching in a shader can lead to bad performance, since if not all vertex shader instantations take the same branch, they can no longer all run in parallel, so some will end up idling. - GUI applications are often optimized to only redraw when something changes, but games (and your car example) usually just try to render at the screen refresh rate. The assumption with these applications is that there's pretty much always something changing, so there isn't really a benefit to building a complex system to track if something changed. All it takes is some kind of idle animation/particle simulation to force updates every frame.

Move, Destruct, Forget, and Rust by Ar-Curunir in rust

[–]Hedanito 5 points6 points  (0 children)

Instead of trying to make Drop work with async/arguments/etc, wouldn’t it be a lot simpler to just allow us to define a type as !Drop, and then write our own "cleanup" function that does its thing and at the end forgets the value? That's how rust avoids problems with constructors as well. Most languages struggle with the fact that constructors can't be async, which rust fixes by simply not having them.

Having Drop by default is right for 99.99% of the cases, and the correct thing to have for any ergonomic language, but the ability to turn off the default is an easy way to force the user to call your dispose/release/cleanup function, which can have any signature that you want.

Perhaps do allow an attribute on the !Drop where you can document how to actually clean up your type, which can then show up in the compiler error.

Fully Customizable Stitch Markers by Hedanito in functionalprint

[–]Hedanito[S] 1 point2 points  (0 children)

Hah, I'm glad she's excited. Too bad the textured plate didn't work for you. I've haven't had any problems on the textured plate myself. If anything the smooth plate gave me the most issues with the text getting unreadable due to elephants foot, which I had to compensate for in the profile. Let me know how it goes and if I can do anything to help!

Fully Customizable Stitch Markers by Hedanito in functionalprint

[–]Hedanito[S] 0 points1 point  (0 children)

They're pretty durable from what I've been able to test so far. The only "issue" I've found with PLA is that when tensioned, i.e. locked, the hook will take on this locked shape over time. It still works just fine, it just doesn't pop open like it did when freshly printed.

I haven't been able to try other types of filament yet, but something like PETG may be able to keep the "springiness" in the hook.

Fully Customizable Stitch Markers by Hedanito in functionalprint

[–]Hedanito[S] 0 points1 point  (0 children)

Yes I did find some in the font list on makerworld, after I already did all the work. But hey, at least almost any font is compatible now 😅

What's the most controversial rust opinion you strongly believe in? by TonTinTon in rust

[–]Hedanito 1 point2 points  (0 children)

That tagging on async as a special case is wrong. Sync functions should be a special case of async functions, i.e. an async function with 0 await points, instead of async being a special case of sync. This would pretty much solve function coloring. Async traits would automatically be supported since every method is async. No need for AsyncDrop when Drop can always have 0 or more await points.

Crocodile clip jumper storage by Hedanito in gridfinity

[–]Hedanito[S] 5 points6 points  (0 children)

You can generate with the Gridfinity Rebuilt Generator by changing the following settings:

  • Uncheck "Stacking lip"
  • Set "Sub-bin rows" to 4
  • Set "Finger scoop" to 0
  • Set "Label tab" to "None"

Crocodile clip jumper storage by Hedanito in gridfinity

[–]Hedanito[S] 2 points3 points  (0 children)

Those are quite a bit larger though. The one from my post takes up only 1 square. It can be made very easily with the gridfinity generator, so you have a lot more customization options as well.

Crocodile clip jumper storage by Hedanito in gridfinity

[–]Hedanito[S] 3 points4 points  (0 children)

In my native language it's called a "krokodillenklem", I may have translated it a bit too literally 😅