3 ms·

> DOOM was still bound to DOS AFAIK, so it's not portable without significant changes DOOM was always extremely portable, the DOS and PC specific parts are wel

> DOOM was still bound to DOS AFAIK, so it's not portable without significant changes DOOM was always extremely portable, the DOS and PC specific parts are well separated from the other code (DOOM was actually developed on NeXT machines, so separating the platform specific parts probably came naturally).

pizza234 4y ago
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:doomgeneric:master https://github.com/maximevince/fbDOOM/compare/master...ozkl:...) - the above is based on fbDOOM, which is quite simple (https://github.com/maximevince/fbDOOM 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-adding-machines:DOOM:master https://github.com/id-Software/DOOM/compare/master...insane-...) The SDL port itself (https://github.com/AlexOberhofer/sdl2-doom 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 4y ago
  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 4y ago
    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 4y ago
      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.

pizza234 4y ago

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:doomgeneric:master https://github.com/maximevince/fbDOOM/compare/master...ozkl:...) - the above is based on fbDOOM, which is quite simple (https://github.com/maximevince/fbDOOM 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-adding-machines:DOOM:master https://github.com/id-Software/DOOM/compare/master...insane-...) The SDL port itself (https://github.com/AlexOberhofer/sdl2-doom 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 4y ago
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 4y ago
  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 4y ago
    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.