Commenting as a radio amateur. Carr is a proponent of handing over any and all public use frequency bands to corporations. This may not be relevant to most people, but it’s one more little “fuck you” to the American public.

Sleep - Sonic Titan. Put some headphones on and listen to the incredible bass lines.

Or anything else in their discography really

Pretty much anything from the Hitman games sountracks. Mostly Contracts or Blood Money.

It’s basically corporate anti-virus software. Intended to detect and prevent malware.

Most large instances have a support community. That seems like the suitable place to raise a moderation issue with specific a community on the instance.

From the Faroe Islands in the North Atlantic: Týr - Regin Smiður

Hollow Knight 112% completion is what I’m most proud of. It was hard!

I enjoy opamps. Texas Instruments LME49723 is one of my favorites :P

By asking this question you’re already ahead.

Be your genuine self. Share your wisdom. Love your child.

I doubt doing it in software like that outperforms sqrtss/sqrtsd. Modern CPUs can do the conversions and the floating point sqrt in approximately 20-30 cycles total. That’s comparable to one integer division. But I wouldn’t mind being proven wrong.

Well, yeah, but you asked why they didn’t use integer sqrt. It’s something many programming languages just don’t have. Or if they do, it’s internally implemented as a sqrt(f64) anyway, like C++ does.

Most CPUs AFAIK don’t have integer sqrt instructions so you either do it manually in some kind of loop, or you use floating point…

The builtin u64.isqrt seems to be available in nightly only, and additionally I guess the author didn’t want to use any external crates as part of their self-imposed challenge. Though I think there may be an off-by-one result with f64.sqrt I don’t think this functionally breaks their u64 code because they loop to root_n + 1.

https://doc.rust-lang.org/std/primitive.u64.html#method.isqrt

There isn’t even any memory management in their code. And arguably the most interesting part of the article is implementing a bignum type from scratch.

The author pointed out they also could’ve just called openssl prime -generate -bits 1024 if they weren’t trying to learn anything. Rebuilding something from scratch and sharing the experience is valuable.

It’s not like Rust is the first language which requires you to reason about ownership. People still write tons and tons of C++. Rust is much faster to write than C++ in my experience, because ownership is checked by the compiler instead of requiring the human programmer to constantly think and reason about.

I wouldn’t write gameplay code in Rust like I posted above, but most of the complaints about the borrow checker making Rust somehow exceptionally hard to write are overblown imo. There’s a learning curve but then it makes sense.

Completely agree with all those points.

The author seems to be a enthusiastic coder and made several game engines in Rust. I’m not sure why they didn’t hook up some hot-reloadable scripting to their engine, call it good, and build games. Probably less work than writing this very long article :)

Yeah I would probably not use Bevy either if the only option is to write all gameplay code in Rust. It doesn’t seem like the best tool for the job.

I’ll grant C# is easier to iterate with. But C/C++, i don’t think so. You still have to carefully consider ownership with those, just like Rust, and refactoring can be laborious. Except with Rust once it compiles your code is probably correct, ownership-wise, which iterates considerably faster than running C++ code and getting segfaults (or data races)…

I helped ship multiple games. All of them used scripting languages, like Lua or in-house, for gameplay code. It makes sense for iteration.

Oh and C# and Java come at a cost, of course. It’s easy to write them, I’m a big fan of C#’s design, but its overuse is also how we ended up with so many relatively simple indie games which consume gigabytes of memory and constantly drop frames stalling for GC. Nothing is without tradeoffs.

For me the biggest difference between Rust and C++, for things like scripting, is cargo. Being able to just add an awesome parser, or support for a particular file-format, to my “script” with a single line in cargo.toml is awesome. In this particular way cargo is better than Python even. The amount of time spent on acquiring, setting up, and linking libraries in other languages cannot be understated.

TLDR: “I picked a systems programming language to write and iterate on a bunch of gameplay scripting. Why does Rust not meet the needs of a gameplay scripting language like . Hmm yes, the problem must lie with Rust, not with the choices I made in my project.”

Just try to write a complete game with nothing but open source libraries in C++, or C#, or Java. Good luck with that. The author is switching to Unity for a very good reason. It turns out a commercial product made by 6000 people delivers value…

You use a systems programming language to write your engine. And then a scripting language to write your game. Everybody in gamedev knows this, I thought.

It is a general purpose language for me. I wrote lots of little (or not so little) scripts in Rust. I wrote high performance GPU kernels in Rust. I wrote web services in Rust. It’s less hard to read and write Rust than is often claimed. Imo.