[pizza234]

Well, extremely portable, I wouldn't say so.

If you look at the ancestry of SDL2-Doom, for example, there are three ancestors:

- doomgeneric, which seems not simple (https://github.com/maximevince/fbDOOM/compare/master...ozkl:...)

- the above is based on fbDOOM, which is quite simple (https://github.com/maximevince/fbDOOM)

- the above is based on insane-adding-machines/DOOM, which is also not simple (https://github.com/id-Software/DOOM/compare/master...insane-...)

The SDL port itself (https://github.com/AlexOberhofer/sdl2-doom) is definitely not simple.

Porting something that it's not based on a multiplatform library (which is commonly SDL for old game ports) is not an easy task in general.

[anthk]

On SDL, there's an SDL2+minimal ANSI C environment for plan9/9front called NPE.

The SDL2 audio and video libraries are just shims against 9front drawing/audio functions, and often they just work.

[pizza234]

Plugging a DOS game to an SDL(2) library won't "just work".

Some concepts are inherent to the hardware and the O/S.

Hardware example: EGA (not the case of doom, but of other, slightly older games) uses bitplanes, it's not just an array of byes; audio cards used specific drivers.

O/S: timers may need to be emulated, as the game may not have a straightforward game loop; due to this, even exiting cleanly may not be trivial to implement.

[anthk]

Not an issue for Q1, it wasn't for neither EGA or VGA for DOS exclusivelly, they had DOS, Windows and Unix versions since day 1.