I haven't kept up with anime much for many years now, but I can easily imagine that this is the case. There had been mecha anime with angsty pilots and behind-the-scenes politics before, but Evangelion pushed it all to a whole new level by adding mysticism, massively flawed characters, and existential dread into the mix. I know that almost immediately following the initial release of Evangelion we got Gasaraki and RahXephon, both of which bear obvious influences from Evangelion.

When all you have (or you try to convince others that all they need) is a hammer, everything looks like a nail. I guess this shows that it isn't.

As a handheld console, the GBA hardware was explicitly designed to support exactly one player. To play multiplayer GBA games on real hardware, either the game must have some kind of "hotseat" mode, or you need to have multiple consoles connected via link cables.

A "hotseat" game should run just fine on an emulator without any tweaking, so I'm guessing that's not what you want.

That means you're wanting to emulate multiple GBAs at once. But RetroArch is designed to run only one instance of one emulator at a time. I'm somewhat surprised to learn (although I suppose I shouldn't have been) that someone has created a RetroArch core that emulates two Gameboys/Gameboy Colors at once. But it doesn't look like anyone's done the same for the GBA. So AFAIK your only option is to have two separate Batocera devices (one for each GBA) connected over a network (if that's possible with your Pi and the emulator supports it).

I haven't done it myself, but briefly flirted with the idea a while ago. This seems to be a solid guide, including tips specifically for the Surface Pro 8:

https://github.com/linux-surface/linux-surface/wiki/Installation-and-Setup

I don't think that even C++ is that bad. Like a lot of shows and music acts, I think it's more the toxic fan base than the thing itself that really sucks. I've had the same feeling with a certain kind of JavaScript programmer.

*Edit for clarity: I'm not saying that the entire C++ community is toxic, just a vocal segment of it, in line with the other examples I gave.

The added difficulty with this in programming is that it can be much harder simply to ignore them, because you may be forced to work with them, or stuck needing to learn something from them (shudder).

Tail recursion in particular is usually just turned back into a loop at the compiler, and typical modern architectures implement a call stack at the hardware level, which allows you to do limited-depth recursion, but breaks like in OP if you try to go too deep.

Yes, in my experience this is what the term "recursion" means in a programming context; it doesn't usually refer to a mathematical ideal. That was what tripped me up.

AFAIK the overall execution speed of the old consoles was always intimately tied to the video refresh rate, not audio. I don't have much experience programming the SNES specifically, but from what I do know about it and my experience with other retro consoles, I don't imagine that the sound processor running ever so slightly faster will change the speed of the game overall. Not even to the degree of "less than one second over an entire playthrough" as suggested by the article.

If the oscillator goes far enough out of spec, it may lead to audio glitches and possibly even complete crashes, but I doubt that many games -- frankly, any games at all -- are busy-waiting on the sound processor as their main way of keeping time.

...

OK, I just took a short break. I've done a little reading about the potential issue from first sources, and brushed up on the SNES hardware. To reiterate, I still don't believe that any game will run even one frame faster due to this issue. However, what does seem to be at stake is tool-assisted spreedruns on original hardware. If this oscillator speeds up just a little, but not enough to cause software issues, there's a chance that controller inputs may be read slightly earlier than otherwise expected (due to the slightly faster audio system finishing earlier), potentially causing a desynchronization with sub-frame accurate hardware input tools, meaning that a TAS may run correctly on one console but not another.

While this is an important issue in the TAS community, I don't see how this could result in an otherwise "correct" run finishing even one frame faster, as the inputs will still only be read by the game once (or however many times the game normally reads them) per field ("frame"), and the game will still be using the video vertical blank for main timing.

You can run games directly over Ethernet, which I believe can run at close to full speed. Some people have made dedicated little server devices for this out of cheap single-board computers like a Raspberry Pi; I think one guy may even have been selling a finished product like this for a while.

And to be really picky, the first version of the slim actually has IDE HDD support onboard like the original network adapter, just no physical connector (you have to solder one on yourself).

In communities for the Murderbot Diaries series of books, I sometimes see this game mentioned as a good fit for the feel of that universe. What I've seen in clips of playthroughs bears that out; I bought the game a while ago but haven't gotten around to actually installing it yet.

Anyway, I just wanted to shout out the Murderbot series as something that folks may be interested in if they enjoyed this game's world and are looking for something to read.

I think I was kinda in the same boat as you.

In theory, I loved the fact that if you wanted to check, the game would tell you when you theoretically had enough information to identify one of the crew or passengers, so you knew where to focus your thinking. But I got stuck on some characters who seemed to me to be implied or hinted, but for whom I didn't think I had positive proof.

I eventually got tired of continuously reviewing the same scenes over and over, looking for some detail that I had overlooked, and read a walkthrough to find out what I was missing. It seems that I hadn't missed anything, and "an educated guess" was the standard expected by the game, not "definitive proof". But I was burnt out with the game by that point and stopped playing.

How about "top-down maze game"?