Windows GOG DOS Games on M-Series Macs

GUI config, load games from zip and image files, controller support, save states, various sound, graphics, and network enhancements etc.

There is more to this than simply being a DOS emulator.

Quality of life improvements? Expanded (experimental) hardware support?

Also the forks add some additional niceties, e.g. DOSBox Staging has some very nice CRT filters that basically make games look almost like the real thing (i have some actual CRTs to compare). DOSBox-X has a GUI to setup options while the emulator is running which is very convenient.

[0] https://bad-sector.itch.io/post-apocalyptic-petra

1. Running games that only ran at 10FPS on original hardware at a smooth 60+FPS, by calling the game's own rendering logic more frequently than the original hardware could "afford" to, but without breaking game logic (i.e. by forcibly decoupling the game's physics ticks from its presentation ticks);

2. Using out-of-viewport but in-{tile/frame}buffer data to expand the viewport to fill my screen (which can be very janky under some rendering paradigms, due to offscreen parts of tile/frame buffers being dynamically partial-updated with a loading seam; but which can work very well under other rendering paradigms, like the SNES's mode 7 where the tilemap was usually just fully populated once at mode-switch time);

3. Making games that used vector-graphics for at least part of their display, and soft- or hard-rasterized those vector graphics into the native low-resolution framebuffer, instead rasterize those graphics at my display's native resolution;

4. having the emulator recognize particular bitmap assets (tiles, sprites, 3D meshes/textures) the game is telling it to render, and swap these out for hand-crafted HiDPI / high-poly versions of those assets from an asset-pack file (as opposed to relying on the caprices of a DLSS-like upscaling model.)

Mind you, to have features like this work well, they often leave the realm of "interpreting the control-register pokes from the game differently", and enter the realm of "the game being patched to take advantage of the capabilities of the emulator." Then, as with these GOG games, you're no longer just shipping a ROM "and an emulator configured to run it well"; rather, you're shipping a co-designed product: an emulator tuned to run that ROM, and a ROM tuned to run in that emulator.

---

By doing this, you technically leave the realm that MAME-like "archival preservation" emulation usually aims for, of "faithful emulation" of both a game's logic and its presentation.

However! "Faithful emulation" folks shouldn't despair. The nice thing about this technique, is that this is all done by wrapping the original ROM in an emulator + shipping runtime-applied IPS patches.

In other words, the original game ROM is still there, unmodified, under an "isolation layer"; and everything being done to modify it is done using "reversible, conservation-grade" techniques.

Which means the emulator can provide a launcher UI to turn any of those presentation "enhancement" features on-and-off. If you're the "faithful emulation" type, you can just turn them off!

(And, under this paradigm, even with the "enhanced emulation" features on, the game logic is still preserved as-is; you're only modifying the presentation. The original game engine is still running; the original instructions are still executing cycle-accurately to how they should. So the "game feel" is preserved perfectly. If you were good at the original game, you'll still be good at playing an "enhanced emulation" of the game; nothing will be "off" about it. Even input movies recorded against the un-enhanced game should replay unmodified against the enhanced game!)

Contrast this to the average "HD remaster", where the game is at the very least recompiled for a new platform (with different timing guarantees), if not entirely rewritten atop a new engine. In that process, there's no "isolation layer"; no way to guarantee a preservation of any part of the original game logic in the remastered artifact. And like George Lucas, game developers coming back to their own works 20–40 years later, just can't help but want to tweak things. So these HD remasters end up breaking "game feel" in all sorts of ways.

If true, that implies development is on life support at best, since any actively-developed project targeting Mac OS would likely have shipped an ARM version within 6 years of the ARM transition.

So anyone who wants to ever run Mac OS 27 or buy a Mac after next year will probably have to find an alternative (or port DOSBox mainline to ARM themselves!)

What they say is "we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks" which sounds like OS X games. But even if it is all-inclusive "retro" games, that means the 1,000s of contemporary games runnable via Crossover through Steam for Windows are being shut out.

They relented under pressure to continue allowing Linux virtual machines, so hopefully they continue to revisit this decision.

https://developer.apple.com/documentation/apple-silicon/abou...

As my sibling post says, it's more likely to work only for some older mac os native games.

If you want to continue to run older software, do what you would do in Windows 11 and spin up VM with an older version of the OS.

I keep a Windows 2000 VM with no network access around just to occasionally play Heroes of Might and Magic 3.

Their attitude has been "we built new hardware, we built new software, we have the tools to develop for these new systems, adapt or die".

This Rosetta 2 transition is actually a couple years longer that their first PPC -> Intel transition. There's more time to adapt this go around.

https://github.com/Solid7s/Boxer-Plus

https://www.macsourceports.com/utility/extractor