n06.jpg
[Hide] (88.7KB, 728x1074) Reverse >>316842
The moral of that story wasn't "some desires cannot be fulfilled", but "some desires come at too great a cost". Especially taking alkahestry into account. There is no cost to using AI, except perhaps for code that's much more than a dispensable build artifact, which must be periodically refactored for maintainability, same as spaghetti prevention on any evolving codebase with multiple authors.
>>316843
>Proofs??
The accelerating flood of native ports that are blowing emulators out of the water one game at a time
>raw assembler
That is what all binaries are, regardless of origin. Granted the amount of symbol names, comments, and debug info are often less than what a compiler spits out from a high-level language, but software handwritten in ASM also tends to be much smaller and less complex, not to mention there is much less handwritten ASM in the world than high-level code.
>a generic emulator [...] still has its uses
So do cycle-accurate emulators, analog circuit simulators, and FPGAs. Very, very, extremely niche uses.
>the post-7th gen globohomogenization of >console hardware
Nah, that only reduces ISA overhead. What you're actually thinking of was the effect of constraints for console/arcade (even PC!) hardware on the most optimization heavy software such as games loosening enough that devs could use reuse code (engines, middleware, libraries, frameworks, OSs, and drivers, microcode, etc.) more intact between projects instead of remaking everything from scratch each time. That's exactly the principle behind why WINE is more efficient than DOSBox, because typically newer Windows apps reuse code from Windows that was easier to port than emulate, whereas typically older DOS apps have a much higher proportion of bespoke code that was less work to emulate than port.