I've been working on something similar [0] also running in the terminal as a TUI. It's made in Rust with a quite novel architecture described in my blog [1].
There's still a performance issue with posts having a large amount of comments but it's quite there yet.
I've been working on a Hacker News TUI reader written in Rust [0].
I'm very proud of the way the architecture turned out - with most notably a components-driven architecture [1].
There's just a major performance roadblock in posts with many comments that I should be able to clear with some more multithreading. Then I just need to make it available in brew and other distribution solutions.
My go-to editor was Paint.Net on Windows too, it's really good. When I switched to macOS, I found Krita which is pretty nice. I have really basic needs and Krita is free, so your mileage may vary. It's presented as a painting app on the official website (and the specialized UI looks really good), but you shouldn't be lost on the default GUI configuration. It's available on Windows and Linux too (and I just saw there's a Steam version, but it's not free).
This is an excellent link, well known in the "community" around this.
To add to it, here's a famous and really clear sub-2 minutes representation of the scales involved if it helps make things clearer, for those who've never seen the scales involved: https://www.youtube.com/watch?v=xP5-iIeKXE8 (and that's "just" the Game of Life in the Game of Life).
I think I would enjoy helping push the state of the art in this field, but it's far beyond my abilities for the moment - which may never change without years of research in my free time, which I cannot realistically do before I'm retired basically.
If it wasn't, I would love to work on a new library specifically built for the kind of things like your idea, with the API aimed at working with metapixels-based "hardware", but with the lowest-level constructs (maybe by far) being thinks like RAM or CPU caches as building blocks - while still being able to zoom to the lowest level of cells in the renderer. But it's basically R&D and HPC combined if one wants to offer an interesting alternative to the established libraries.
From what I know of upcoming hardware, such a library may have to wait a couple of years and basically target (as in, full buy-in, maybe at the programming language-level, certainly in tooling) the next Apple Silicon-like (or beyond) breakthough in commonly accessible hardware for a nice, "free" performance boost. Maybe GPUs are next?
That's really interesting, I did not know about that, thanks for the link ! It's highly specific but could make a lot of cool "wow-effect" products or software suddenly viable, especially if it percolates to your average consumer hardware some way or another.
If you want to know more about the hardware side of the Game Boy (Color), have a look at the Pan Docs: https://gbdev.io/pandocs/
It's been revamped in the recent years, in terms of presentation. I do kind of miss the old version which had a refreshing "old-school" UI like the RFCs of the IETF, but the newest version is IMHO much more usable when developing an emulator.
"Old" gaming systems are so interesting in their architecture, and consequently tricks that game developers had to do to eke out the necessary performance out of the hardware! I feel like since PS3's Cell processor (regardless of what you think of it), game consoles have been increasingly following more classic (desktop-like) architecture in the entire hardware stack, which has been to be honest great for cross-platform game engines and applications.
That is why I love implementing emulators of older systems for fun. I recommend the classic CHIP-8 for starting, it's well documented and can be written to play practically any game ROM in a couple of days.
I personally then graduated to a Game Boy (Color) emulator, and in particular the PPU (graphics part) was really tricky to get right but I felt like the tile maps, as described in this video, were such a great solution for the time and it was a real joy to implement.
Subscribing to this channel, hope it will one day get into some details about the Audio Processing Unit which has so little resources (even in the reference Pan Docs [0]) that I fear I would need to straight up port code from reference open-source emulators (so probably C) to get it working with no major bugs.
> I feel like since PS3's Cell processor (regardless of what you think of it), game consoles have been increasingly following more classic (desktop-like) architecture in the entire hardware stack, which has been to be honest great for cross-platform game engines and applications.
The current and last generation consoles from Microsoft and Sony are literally PC components. They're not just off-the-shelf PCs but they have definitely converged on PC technologies. The original Xbox might as well have just been a PC. So you're definitely not wrong there.
This is incredibly cool, thanks to Don Hopkins for open-sourcing the original (C, C++ or Java implementations) micropolis codebase [1] !
As a shameless plug, I've been for the last few years re-implementing on and off this exact same project (based on the C++ codebase) in Rust, WebAssembly and Svelte! [2] Quite a bunch of buzzwords I know, but it's specifically made for me to have fun.
The map generation is working (or at least it was properly rendered when I was using React) and about ~50% of the codebase has been ported over to Rust, but there's still a lot of work to be done if anyone wants to help!
The end goal is notably to have tons of slick data visualisations with d3.js.
