I just add a tiny pinch when using it, so it acts as a chelating agent to prevent water spots from forming in the first place.

The reason anyone thinks it’s slow is that in the real world, people still ship* Python scripts/projects that don’t offload their performance-sensitive code to faster solutions.

Acting as glue isn’t unknown to anyone looking into Python either, problem being there are multiple different solutions that each have their own benefits/drawbacks that will differ based on the use-case. Fine if you can lean on an existing library, more complicated if you actually need to write the performance-sensitive code.

Similar to @Chais@sh.itjust.works, plus newer compile-to-C/C++/JS languages offer a lot of what Python does (glue, whitespace, style) plus more stuff like UFCS.

My preference is nim-lang, it has stuff like for i in 1..17: (or something like
for h in 0.uint8..<height:. Typing is a thing but doesn’t stop me, so either not a big hurdle or there’s something with my brain that makes it fine despite issues with other languages/styles). Nimscript is an option, and I like Clang with opt:size for an efficient testing option (Bellard’s TCC was an even better option for quick iteration in the past, not exactly supported now (as of 2023) though. Might work for other languages).

* my last experience with this was a piano thing (soundfonts for MIDI keyboard) that had choppy audio when played too quickly and would crash my Raspberry Pi 2B. The issue was closed as not planned.

They mean scripting, GDscript is also interpreted (and probably also not often parallelized) so it’s also not blazing fast (though I guess typing helps).

Though Godot has many options for languages (including bindings), so compiled is an option (you don’t have to go all in on one language either, so something like a generator or multiplayer code etc needing more performance can use a more capable language).

This probably depends on what CPU someone has, someone with a higher-end CPU (higher-IPC/higher clockspeed) probably will have a better experience.

On older/lower-end CPUs it is more common to see when something is single-threaded especially when it’s also interpreted. Particularly any type of generator/loader, filter, renderer, live audio. Which to be clear, is from a user perspective.

For Qt instead, there’s octoxbps.
(I haven’t tried Void though, so not sure if there are other functional differences)

Keeping it simple, have you tried to solve something on your own? Even in the case here, making something similar but not with the exact code from the book, but a “close enough” solution. And putting your own spin on it that makes sense for your structure.

I am not exactly a beginner (nor exactly experienced), but I had this moment with a minesweeper clone. I wasn’t quite sure on structure with first attempt. I waited a while and eventually figured out how to actually start and complete it.

I honestly wouldn’t be too concerned about the space used by Flatpak dependencies

Space is a concern but not the concern, it’s about download time. It’s a considerable price of admission (worse with updates, though maybe not so anymore with legacy). I actually tried Flatpak at one point for Krita, and that is part of why I switched back to native.

You won’t get the most bleeding-edge performance features
EndeavourOS has been noticeably snappier

Yeah, I’m more worried about backtracking from my current setup (a bit more than half-a-year out-of-date but still newer kernel than Debian stable EDIT: correction). Particularly snappiness, I expect optimizations are a big part of that (CPU is Ryzen 2700, might be more important for that).

I’m not sure about about using an older kernel.

I’ve already mentioned having issues with Flatpak’s redundancy*, but I also imagine sandboxing could potentially have other issues too. Specifically I use Godot 4.6+ with bindings for a compiled language. (I haven’t used it thus far, but Godot can potentially have a pipeline from Blender)

So, maybe something like that might be viable with a different package distribution system. I haven’t looked into it though.

* and this could be another nVidia thing with the size of the driver?

you don’t have to! Just install the package
and it will use your ad-hoc dotfiles like it would on any other distro

And changes will last on reboot, y’know with the whole immutable thing?

EDIT: I couldn’t find straightforward (to me) info on this even searching for stuff like ‘NixOS mutable home’, but after the reply to this I tried different terms and found the wiki page on impermanence. Specifically, the persisting+home managing sections:

Some files and folders should be persisted between reboots though (such as /etc/nixos/).
This can be accomplished through bind mounts or by using the NixOS Impermanence module, which will set up bind mounts and links as needed.

and

You can just make a home partition on a drive and mount it as normal, so everything in /home or /home/username will be persisted

However, then files are stored read-only in the Nix store. In order to persist files while still being writable, you can use the Home Manager Impermanence module

It’s annoying (compared to anything similar on Arch) and will reinstall things you’ve removed. There is conflicting information on the best way to deal with this, either way more complicated than ‘off’. It’s a problem that shouldn’t be a problem, and it seems to be a common issue people have.

and plain old dotfiles on top if you want

I’m not the type to put my dotfiles in git, though. A lot of things I just plan on starting fresh and configuring in-session.

Not sure what you mean by “non-packaged executables”

Pre-compiled, non-system binaries.Typically, stuff downloaded from GoG and itch without a client (also the odd thing like BrogueCE). I don’t know if this is always an issue, but it is for anything that uses dynamic linking (checking with ldd is a thing, though can be misleading with runner scripts).

Heroic works fine

I’ve never been interested in the Epic store even for free games. I’m sure there are 10 ways to “solve” this each with their own benefits/drawbacks, but I feel like this is a philosophy issue that creates more problems than it solves for me. And this is without the ability to create static binaries (out of the box) like I’d get with void-linux musl.

That, and seeing talk about how great Nix is but also people having trouble later on too (major updates? bleeding edge woes?).

I always do that and it still happened, probably because I had a drive as NTFS for compatibility. Last I checked (after failed attempts), the fix was “fix it with Windows” so I still have a borked external drive.

I’m a bit disappointed with packaging/updates. Specifically Arch, I have slow-ish shared internet and didn’t update frequently enough now my system is too outdated (1050Ti, them moving legacy nVidia drivers to AUR is another reason I haven’t updated in a while).

Looking at alternatives.

• Void (I still might want something more user-friendly) musl? (but optional and interesting for creating static binaries)

• Tumbleweed/Slowroll might be perfect if it weren’t for patterns (and I wish update structure were smarter* than just scheduling).

• NixOS is a fun idea but not with declarative desktop settings (I have my own XFWM window theme not uploaded anywhere) and extra mess when it comes to compiling/exporting also running non-packaged executables (especially if I decide to stop using Steam, running what library I can w/o client)

User packaging is also generally questionable, too. I know not to rely on it too much, but I’m also not going to be inspecting package scripts especially not every update.

Other package distribution is a neat idea, but needing to download another graphics driver for Flatpack sort of ruins the point for me (redundant data too). That, and less integration+more manual updates.

* it probably doesn’t exist, but I’d like something that has some sort of awareness of compatibility (be it simple/explicit versioning, build bot troubles, user reports etc). If I haven’t updated in a while, give me a safer update (hold more Major.Minor.newest packages to known-good). If I’m updating regularly, tell me if an update on tuesday might not be great and remind me on friday if it seems better. Let me mark software with some general issues (stability, rendering, features) and alert based on potential fixes.

13KiB is such a constraining limit, and extra funny considering modern events.

Hobbyist: I’ve deleted faces to use less bytes.

Console maker: We’re discontinuing discs. Worried about games being over 100GiB? Screw you, get faster internet.

EDIT: Also not exactly sure how they did the models. I could see precision being a grid/editor/export setting (or obj parser/optimizer?), though maybe they wrote them by hand or did it in Trenchbroom and thus handled by their own map loader. Controlling precision through scale too, maybe?

Yeah, size and weight aside I feel like the CRTs I’ve used in the past weren’t close to the quality of the ones people show on ‘CRTs are amazing’ videos.

I have no idea if it actually works for pixel effects, but the only CRT filter I like is triangular filter (offset rows gives honeycomb-ish pattern rather than lines/screen-door effect). Which would likely also make finding a CRT I actually like harder too.

EDIT: And I could take-or-leave the filter still (except for when it clashes with CRT effects in games), though I do like what it does for 2D (UI elements and pre-rendered stuff) plus toning down the brightness on full-white screens (like intros/logos especially).

I feel like I haven’t experienced enough games that look like tech demos… solid techniques (that more games should have) sure, but I always feel like gameplay is what feels more under-baked. That and texture-work is still pretty universal and safe (also pre-rendered stuff that will do well in their day but usually won’t age well).

What does this and ‘no making your own mods’ even do for the hypothetical? I’m pretty sure most people aren’t going to solo-dev (m)any additional top-10-worthy games that they’d also consistently enjoy. Maybe for some (simple) classics, but at that point I say so what?

Even accomplished solo-devs lose motivation (also constant reminder of room for improvement is sort of its own curse), if anything I’d say paying for mods to be created probably a less of a patient-gamers thing (and probably more exploitable).

I know it sounds pedantic, but stuff like this shouldn’t use the term cyborg. They are bio-robots at best (really it’s just a hijacked bug). Similar for dead bugs.

Scientifically and legally for usage of the term I think it should be clear that the organism controls and benefits from the technology, not the other way around (or anything that blurs the lines on autonomy).

I’d second that not being a community here likely didn’t help. Though a while ago I asked a question on the linked window manager community but my comment didn’t federate.

For me though, I actually finished the last thing I started but couldn’t share it (system issues still) so that sort of killed motivation. So I have more of a problem of not starting right now. I have a couple of ideas, but the start for either isn’t obvious to me. And I don’t expect semi-niche language help, though maybe general structure advice would’ve been possible.

Real time poly animations.

Just want to post this: This page allows to playback some cutscenes (higher-res than Genisis)

Not perfect, though I imagine it’s probably a fault of being designed 1:1*. Perhaps there is a better version (allowing modern res), though the Steam version uses an upscale filter instead (maybe because the maps aren’t polygonal?). Another World seems to have a better treatment (though Steam says 800MB, so not sure if they rastered it or if they just made the audio uncompressed).

* For a similar problem, some people (One being ‘Old Man Yells at Code’ on YT) have made newer videos about how classic Sierra games were actually polygons (…at least lines/fill) but don’t always properly connect when rendered at higher res (and attempts to re-interpret the data).