Are you saying it might be a crime for a President to unilaterally invent a new law and make the federal government enforce it? Well, you see…

It’s so good. And also one of my most treasured 90s records I have on vinyl. Wish I had a pressing of Death’s Design too.

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

The best free one is probably Pitchproof. It’s alright but it doesn’t handle chords well. I gave up using pitch shifting and got another guitar and put thick strings on it for low tunings.

The DSL40 sounds very appealing indeed, and not too pricey. I’ll go around and look for it at the local guitar store. I’ve also frequently seen those Katanas mentioned above which I’ll have to try. Thanks.

Thanks. Hoping to figure this out around $500. I don’t need loads of power so that should help the budget.

I don’t have experience with amp modellers in the FX loop. This works differently from multi-fx pedals with preamp simulations? I plug my guitar into my GT-1, which goes into the instrument input of my amp (a Rumble 100). No matter what I tweak with this setup, I fail to get it to sound believably “classic rock” so far.

Ah yes I should’ve specified. It’s a Rumble 100. Yeah, that’s a bass amp as I was primarily playing bass when I bought it. It does sound surprisingly excellent when I play clean-ish guitar through it, but with the GT-1 I can’t quite get a satisfying overdrive tone, no matter what pre-amp simulation I select on the GT1. With the amp set to clean, 0 gain. The master volume is plenty to make it loud. But yeah, I just can’t get this combination to reproduce what I’m looking for.

Perhaps it’s the speaker cone itself which is holding it back. I hadn’t considered that yet. Thanks.

Do you do poison?

According to the article this system also detects power outages and shuts off when they happen. Just like full-scale solar power systems. But yeah, no physical kill switch.

I’m guessing regular non-LP DDR works fine socketed in desktops because power is nearly a non-issue. Need to burn a few watts to guarantee signal integrity? We’ve got a chonky PSU, so no problem. On mobile devices however every watt matters…

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…

California somehow never fails to do the wrong thing when it comes to utilities.

The problem isn’t people with a few solar panels on their houses, the problem is climate change and poorly maintained infrastructure leading to wildfires and massive liabilities. Perhaps if these liabilities would come out of PG&Es absurdly high profits they’ll be motivated to rethink how maintenance and wildfire risk is mitigated.

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.

Star Wars making the 40k universe look fun.

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.