1,863 karma · joined May 16, 2018
It might well result in less repetitive background chatter & stock comments from side characters without taking focus away from the primary content. Especially if those background characters could react a bit better to progression in the plot.
(edited to expand)
I want plot/character driven games like RPGs to be a curated & carefully designed, plotted, and paced experience.
I want speech & narrative to be scripted! It means someone sat down and thought about the experience it produces for the player. It means a real voice actor has performed it, putting the right emotion and pacing into the line.
I don't want AI generated stilted dialogue, uncanny valley speech, etc.
And I also don't want an extra few hundred watts of power draw on gaming PCs - they're already high and in modern games the CPU is under pretty substantial load, the GPU is maxed out, and the GPU's AI/NPU style cores are being used for things like DLSS too.
Bringing in more compute resource for running speech to text, LLMs, text to speech, etc fast enough to not feel horrible is going to come at substantial power and financial cost.
I don't see any issue with using SD or microSD for that usecase?
edit: I don't think I/O performance for reads should be a big issue either - for most retro games you're going to be able to have the whole ROM in memory as even a 16 or 32MB GBA ROM is still tiny! For PS1 and newer, microSD read speeds are certainly faster than CD/DVD read speeds, too?
I've been running a m.2 drive on a Pi5 for a few months now (using the Pimoroni HAT), and it's a game changer for how well it performs at just about any task that uses disk I/O at all - even just opening applications, and it massively helps reliability.
You might not get amazing headline sequential I/O speeds because it's only a PCIe 2.0 x1 connection (you can run it at 3.0, but it's unsupported), but the difference in random I/O is huge.
It makes whole classes of usecases practical as a result - you can now use a Pi5 for databases, CI, etc - especially paired with the fact that the Pi5 is another decent step in CPU performance.
My Pi5 is now running a GitLab CI arm64 runner building Docker containers using a Samsung 980 Pro as the SSD... and it just works.
It's a bit slower than building the x86_64 version on a modern Xeon, but not excessively so - a docker container build that is mostly installing .deb packages with one compilation step that takes about 90s on 4 cores/8 threads of Intel Xeon Silver 4410T with also a Samsung 980 Pro for storage takes about 120s on the Pi5.
For the one-off price of a Pi5 + NVMe HAT compared to say something like an Apple Mac Mini or the ongoing cost of cloud arm64 rental, I think that's very reasonable!
edit: I still think microSD has it's place - but it should be as removable/transient storage - not as storage for your root fs.
I had a PC that was having inexplicable game crashes, but only in stressful games - swapping the power supply from an existing ~10 year old one (which was still rated as enough capacity for my hardware) to a brand new ATX 3.0 unit resolved it.
Lots of people’s gaming PCs (self built and otherwise) are very crashy - there’s a surprising number of people who get regular BSODs who just accept it as “normal”.
I’ve used a few different ISPs but I’ve gone back to A&A every time
But if you're going to manage your own servers, you need to do it right. This article is a perfect example of what I've seen in the past with not doing it right. It's inconsistent, it doesn't take backup seriously, and it doesn't take availability seriously.
Postgres is installed from their repo. Caddy is installed via & managed via ansible (instead of using something like caddy-docker-proxy). Actual backends are managed via docker compose. Backups are via a hacky script instead of something maintained & that another developer will be able to find docs on like borgmatic. Nothing is thought about for making sure the database state is consistent during backups (eg barman). Monitoring is an afterthought. Firewalling isn't even mentioned.
This setup is one hardware failure away from spending days or weeks trying to recover.
Most people don’t need kubernetes, and ECS + Terraform is very approachable and easy to get started with, especially with Fargate for compute.
It is a case of personal preference. Removing or having creature comforts like easy refactoring, being able to do code aware search like go to definition, etc won't make you a better or worse programmer.
It might make things more frustrating to get around. It might make you slower. Or for some people it might remove distractions instead.
Try both using more of a 'just a text editor', and full fat IDEs - and use what you prefer.
I expect it helps a lot that AMD can easily provide competitive x86 and GPU cores in one SoC, as they’re already building similar APUs - just with smaller graphics segments?
My home internet gets ~7ms to London (I'm in the UK, London is the important IXP. My test is to one of my ISP's routers at LINX). 5G is about 40ms.
When you add load, my home internet stays at about 7/8ms (CAKE is wonderful!), but my 5G goes to 200-600ms.
I make it a personal mission to eat somewhere different every time I visit.
They often have some kind of proof-of-ownership (like a license ticket) required to download game data or updates, too.
If a day1 patch is required, then it can’t leak until that patch is available?
For Linux support you need a very recent kernel - I forget how recent, but some reporting on it: https://www.phoronix.com/news/AMD-EDAC-Ryzen-7000-Series
I wish more motherboards bothered to validate ECC working - it's a nice benefit in an affordable platform.
I think “emulation” fits as a reasonable description of this, personally - at least as something an average person will understand.
But... for an app running multiple instances, the article suggests a lot of extra complexity. Managing that complexity makes less sense to me than just firing up a managed database server (RDS, or whatever).
Even if you're self hosting, I think running a MySQL/Postgres cluster is a lot less complex than the options this article calls out.
edit: and more to the point - MySQL / Postgres replication is boring. It's done by a ton of deployments, and isn't going to surprise you, at least at smaller scale.