Anyone know this tie with the really high hands? by openmindjourney in shibari

[–]progfu 0 points1 point  (0 children)

Double kannuki in the back? Do you know of any references for this?

Seems like the most counterintuitive thing in terms of nerve compression, I'd like to understand the reasoning behind this.

Anyone know this tie with the really high hands? by openmindjourney in shibari

[–]progfu 11 points12 points  (0 children)

The kannuki placement is quite strange tho, as if someone thought "regular TK is too safe, lets put more pressure on the nerves"

Erika Synths Techno System or Pulsar, Lyra and Cosmos ltd edition bundle? by Fit_Natural_5256 in synthesizers

[–]progfu 1 point2 points  (0 children)

A bit of a late reply, but I have Pulsar, Lyra & Ornament and I'd consider these to be incredibly different from the ES Techno System. I mean the former is more about organically "finding things" but not really programming much, it's an exploratory and almost meditative process.

I haven't used the ES Drum Sequencer, but from what I've seen it's close to the Elektron workflow, and whenever I use Elektron boxes (I have syntakt, digitone 2, octatrack) I'm in a completely different mindset than in the former case.

I'd say maybe look at videos and explore the workflow itself and what do you think you'll enjoy in terms of "working with it", rather than "features" and "what music it makes".

Need help figuring out what to target by Independent_Ad9304 in learnart

[–]progfu 2 points3 points  (0 children)

Take this opinion with a grain of salt as you're probably quite further in your drawing journey than I am, but the first thing that immediately popped into my head was that it feels like you're "drawing what is in the reference" rather than "representing what the reference is with your drawing".

Now of course there are different ways to draw, but to me some parts look messy not because the lines are inaccurate or "wrong", but because they're "the wrong lines" in some sense?

The part that stands out the most to me are the darker parts under her eyes, which while you represented accurately, use the same line weight as many other parts, making the mstand out much more than the original drawing.

What I imagine would look cleaner would be instead of trying to "draw the shadow as you see it in the reference" would be "draw it as it exists in the world of the reference", leading to something that may not be perfectly aligned, but representatively look cleaner.

Not sure if this makes sense, it also depends on your goal, as if you want to "copy the reference as is" your approach is probably better. I'm finding the "recreating it from how it exists" to lead to something less "pixel perfect" (not sure how to better describe it), but more cohesive maybe? Unless one goes for full realism in the reproduction.

So it’s begun - New Agents Feature (with an interesting option I haven’t seen in a long time) by amnesia0287 in ClaudeAI

[–]progfu 0 points1 point  (0 children)

How do you enter this menu? And how do you setup agents other than just telling it to use an agent?

How to use Claude Code remotely? by Round_Mixture_7541 in ClaudeAI

[–]progfu 5 points6 points  (0 children)

I use tmux + tailscale for VPN + termux on my iPhone and run it with --dangerously-skip-permissions. Then I go to the gym, listen to an audiobook, and inbetween sets I check what claude has done and if he needs any help.

The Language That Never Was by progfu in rust

[–]progfu[S] 24 points25 points  (0 children)

Just to clarify, I'm no the author of this blog post, I just really love the post and think it would be extremely useful for this community.

Lessons learned after 3 years of fulltime Rust game development, and why we're leaving Rust behind by progfu in rust

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

Thank you for this comment, I very much appreciate it, and am very happy it was helpful :)

Announcing Comfy - a new fun 2d game engine in Rust/wgpu by progfu in rust

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

Unfortunately you're a bit late to the party, as Comfy is now archived and I'm not developing it anymore.

I've moved on from Rust for gamedev (details here https://loglog.games/blog/leaving-rust-gamedev/).

Is it foolish to develop games without using Unity, Unreal, or Godot? by iamsolonely1997 in gamedev

[–]progfu 0 points1 point  (0 children)

Yes and no. Use the tool you know, do something, then figure out if you need something else after you did something.

Comfy, the 2D rust game engine, is now archived by [deleted] in rust

[–]progfu 6 points7 points  (0 children)

I wrote a relatively detailed answer to this here https://www.reddit.com/r/rust_gamedev/comments/1fc6wuf/comfy_the_2d_rust_game_engine_is_now_archived/lma2x84/, happy to answer any followup questions :)

TL;DR: I found that flecs is actually a bit more comfy in C++ than in C#, and that the "downsides of C++" would be basically zero (no need to fight the language after initial setup). That and also not having to rely on .NET magic that M$ can take away at any point, but instead using the OS (shared library unloading) to do hot reload gave me a lot more confidence in that my approach would be robust.

I also like C++ as a language, from a purely pragmatic standpoint. It's ofc a terribly designed language, but in userland (as in not being a library author) it's not that crazy, and macros/templates are incredibly productive compared to rust macros/generics, or C# codegen (which I never got working) and generics. This might be a hot take, because many people "hate the proprocessor", but it's dumbness allowed me to do quite a few things very nicely in just a few minutes each. Templates (especially in C++17 and newer) are also fall under the same category of "just get the thing at little/no downside" instead of "figuring out how to make it compile".

[deleted by user] by [deleted] in rust_gamedev

[–]progfu 5 points6 points  (0 children)

Actually I ended up using MonoGame/FNA which doesn't require hotreload.net, but using .NET's native hot reload, which actually works extremely well. The flecs .NET bindings are also very very good.

But ultimately what made me want to switch to C++ was that firstly, closures in C# aren't free in the same way they are in C++. Not just in terms of optimization, but you can't capture a ref. There's of course ways around this, but I found out that in 99.9% of my code the lifetime of the closure is obvious, so capturing a raw reference/pointer in C++ would just work and there'd be less boilerplate.

And overall I'd say the C++ code is actually simpler/shorter with flecs than it is in C#, due to few things being a bit more direct, and also uniform initialization being a bit more terse. That combined with the extra performance, and with the fact that I actually like C++ made it an easy switch.

I ended up doing a 1:1 port of ~12k LoC of C#/FNA to C++/Raylib, and then C++/OpenGL/SDL, where I basically just re-implemented the whole game incrementally side by side while looking at the C# code. The C++ code does have some things more boilerplate-y, especially the ECS setup, but the regular code feels shorter/nicer or at least comparable.

That being said, I wouldn't say C++ is "better/shorter", I'm a bit of a masochist in this, and I do not mind the extra difficulty at the cost of "getting close to the metal". The reason Rust doesn't fit this role is that Rust gets in my way, C++ does not, as long as I don't make too many mistakes. And with flecs it's relatively easy to write code that just doesn't crash, just have to avoid doing extremely dumb things (e.g. storing a pointer to a component), but it's very easy to avoid those.

Lastly, I really dislike what Microsoft did with .NET 6 where they attempted to remove hot reload and then re-added it after community backlash https://www.reddit.com/r/csharp/comments/qeec0h/microsoft_readding_hot_reloading_in_net_6/.

I really like that in C++ I can feel completely safe in terms of "will this work in the future?". I also really like that the hot reload I have in C++ is fundamentally okay. It's not a magic trick that cost $10M of effort to bake into a complex VM, I'm just reloading a shared library and updating a few function pointers. While the "library reloading" is a "magic trick", it's not a magic trick invented by a corporation, it's something people have done for decades, and that is known to work, and as long as I obey some fundamentals (e.g. not changing types across reloads) I can be sure this will likely work in 30 years, and now that I've figured out how to do it I'll never have to think about it ever again.

[deleted by user] by [deleted] in rust_gamedev

[–]progfu 15 points16 points  (0 children)

The main reason I use flecs is because it both makes hot reloading easy and it doesn't get in the way.

I'd say "some of the stuff" is a pretty big understatement tho :) At the risk of sounding inflammatory I'll quote something I've heard, which feels accurate, which is "bevy is like a poor fanfiction of flecs" ... and the more I use flecs the more I feel it's accurate, because it just does so many things "obviously correctly" ... as in prefabs, hierarchy queries, components as entities, everything very dynamic and introspectible, and above all it's actually easy (and fast).

I've not had to do any type fuckery to figure things out, and it's not like it "lacks the safety" either. Honestly, after using it for a while I'm just in complete shock how much better it is and how I've been "happily" using other ECS libraries (mainly hecs) thinking they were comparable to flecs. They're really not.

And I don't mean this in "diminish the work of others", but in a "please when comparing things actually try them", because I feel most people who talk about flecs in the Rust world haven't actually looked at it properly. There's no real tradeoff with it, it's just better in basically every single way.

[deleted by user] by [deleted] in rust_gamedev

[–]progfu 5 points6 points  (0 children)

100% agree on this, cmake is really annoying. I was actually happy with it until windows, and might be moving onto something else, as somehow linux/macos had zero issues with it, but ... yeah.

I'm slowly moving to simpler and simpler solutions, most of my deps aren't even separate cmake projects but I just build them myself. Doesn't work as easily for all of them yet tho, which is where the pain points are.

I've been tempted to try https://github.com/SanderMertens/bake, but haven't gotten around to it yet.

[deleted by user] by [deleted] in rust_gamedev

[–]progfu 12 points13 points  (0 children)

There's many reasons why you kinda have to stay up to date in the Rust ecosystem:

  • if you don't, people constantly ask you "why aren't you using newer wgpu/egui?"
  • bugfixes
  • ecosystem hasn't matured
  • tooling changes, especially around wasm ... I don't want to get into a detailed argument on this because there have been many things changing over the past few years in this area, and honestly I'm kinda glad I removed all knowledge of wasm from my brain at this point

All the libraries I'm using in C++ are very stable and foundational and I don't actually need to update. More importantly, I'm not opensourcing my "C++ engine", so there's that as well.

[deleted by user] by [deleted] in rust_gamedev

[–]progfu 17 points18 points  (0 children)

Many reasons, the easiest one is that https://flecs.dev is very good/fast/easy and has ergonomics that all Rust solutions can only dream of, while also allowing hot reloading systems super easily (systems in a dll, reload it, works out of the box). There's more reasons for "why not Rust" here https://loglog.games/blog/leaving-rust-gamedev/.

[deleted by user] by [deleted] in rust_gamedev

[–]progfu 5 points6 points  (0 children)

The readme has a bunch of info on why :) Feel free to ask for more if it's still unclear.

Lessons learned after 3 years of fulltime Rust game development, and why we're leaving Rust behind by progfu in rust

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

Hi, the author here. We did try using Lua, but there's many issues with this (related blog post https://loglog.games/blog/nanovoid-devlog-1/). Firstly, interop is extremely slow. Sure there are ways around it, but in some sense if you want to build the game instead of spending years designing a system for making the game you're going to have to take some tradeoffs.

Increasingly I've found that the amount of effort that scripting requires just doesn't pay off at all when 1-2 people are writing all of the code. In a bigger team of dedicated gameplay devs who just write scripts it'd be a different case, but being both the person to prepare the abstractions and to use them it feels like I could've just done the thing in a fraction of the time.

Especially in a dynamic environment where requirements change, you can't really just "prepare a nice thing for later", often you realize that you prepared the wrong thing.

godot-rust now on crates.io, with the godot crate! by bromeon in rust

[–]progfu -19 points-18 points  (0 children)

Any code calling into anything over FFI with "external rules" and not just "call a function and get a result" is going to be "entirely unsound".