4 ms·

A question from someone who has never seen a NeXT computer: How is it possible that Doom was developed on NeXT? As far as I know, Doom was first released for

A question from someone who has never seen a NeXT computer: How is it possible that Doom was developed on NeXT? As far as I know, Doom was first released for MS-DOS. Wouldn't be really hard to develop a MS-DOS game from another operative system and another CPU architecture? Specially at the time without engines abstracting platform details?

busterarm 8y ago
http://doom.wikia.com/wiki/NEXTSTEP http://doom.wikia.com/wiki/NEXTSTEP From my memory of reading Masters of Doom, they developed for where they expected the consumer PC hardware market to be at the time of release. If you wanted that hardware at the time they were developing, $10k Next workstations were your best bet. When Doom came out, I (and most other folks) needed a new PC. Ports to multiple platforms were pretty common in those days with games and that's something the team had a lot of experience with from their years at Softdisk. Having looked at the game code, it's not really terribly difficult.
- kyberias 8y ago
  I don't think so. It's just that the development environment was so much more productive on NeXT.
  - saagarjha 8y ago
    After having a very recent encounter with developing software on NeXTSTEP 3.3, I'll have to agree with you. For how old it is, it held up pretty well!
- rasz 8y ago
  Nah, it wasnt about raw speed, Doom doesnt even run all that well on next, its slower than 386DX40 on emulator trying to approximate NeXTcube Turbo speed.
jacquesm 8y ago
That's called porting. And whether or not it is a lot of work depends on how much foresight you had about doing that at some point in the future. If you didn't then it would be a very large amount of work because platform assumptions would be baked in all over the place. If you did - and you were a disciplined programmer - then it could be reasonably quick. I've written software that ported cleanly between Windows and SGI Irix, the original was built for the SGI and when windows capabilities caught up it was relatively straightforward to port, I tried very hard to keep all the platform dependent stuff in a single file so I knew exactly which bits to leave untouched and where to use the chainsaw.
outworlder 8y ago
It is not that big of a deal, although there was extra work required. You need to remember that Doom had a software renderer only. It only needed to be able to write to a color framebuffer for display. It also needed access to a keyboard, and sound. As long as you do it properly and carefully (and this is John Carmack we are talking about), it is not too difficult to abstract. You need to be careful not to paint yourself into a corner (endianness, pointer sizes, properly isolating platform-specific code, etc). That way you can develop most of the game without even touching the target hardware. Doom did have what would be nowadays called an "engine", only it was designed for that particular game. Id Software was probably one of the first (if not the first) company to sell a generic "3d Engine". In any case, the abstractions were there. They probably could not do the entire development using the NeXT workstations. At some point they would need real PCs to finish the port, and check how it worked on the target hardware. That was even more of an issue back then: although the C code could be cross-compiled (to solve the different CPU architecture problem), they did have lots of assembly code for performance. Nowadays, we are spoiled. iOS developers do exactly the same thing day to day as they did, only they don't even notice for the most part. Click a button on their Macbooks (which run amd64 arch), code get cross-compiled to ARM and linked with ARM-specific libraries. Android developers do the same, and they even have a fully emulated environment.
nbm 8y ago
If you're writing code in a language that compiles to multiple CPU architectures, it's not hard to get 90% of the way towards supporting all those CPU architectures without trying much. The remainder certainly requires some effort (much less if you think about it up-front) - this is where standard types like int, long, even char, and pointers, have different sizes - and where you can't just write out the memory format to a file if that's the same file you're loading on a different platform (even with the same type sizes, because of endianness). Writing cross-platform code, especially for early games where you're using a fairly restricted set of the platform code (and even less if you're doing a software renderer), is similarly not that hard in the common case if you've thought about it/have experience with it. There are a few different approaches, but even just having a single file that has POSIX and DOS compatibility functions (ie, above the stuff the C standard provides) and some macros could probably get you 90% of the way there. I don't mean to downplay how hard it is to, say, support multiple renderers, which is a problem that came later, or porting code that was written without any thought given to future portability. But given they knew they were supporting two platforms, it's not that hard to do (compared to the other, actually hard, stuff they did).
gameswithgo 8y ago
>Wouldn't be really hard to develop a MS-DOS game from another operative system and another CPU architecture? Nope, fortunately someone invented C!
kalleboo 8y ago
Probably just as important as developing the game engine, NeXT's programming environment also let them quickly and easily build tooling like level editors https://doomwiki.org/wiki/DoomEd https://doomwiki.org/wiki/DoomEd https://pbs.twimg.com/media/B3O6oJmCIAAGMi0.png:large https://pbs.twimg.com/media/B3O6oJmCIAAGMi0.png:large

busterarm 8y ago

http://doom.wikia.com/wiki/NEXTSTEP http://doom.wikia.com/wiki/NEXTSTEP From my memory of reading Masters of Doom, they developed for where they expected the consumer PC hardware market to be at the time of release. If you wanted that hardware at the time they were developing, $10k Next workstations were your best bet. When Doom came out, I (and most other folks) needed a new PC. Ports to multiple platforms were pretty common in those days with games and that's something the team had a lot of experience with from their years at Softdisk. Having looked at the game code, it's not really terribly difficult.

kyberias 8y ago
I don't think so. It's just that the development environment was so much more productive on NeXT.
- saagarjha 8y ago
  After having a very recent encounter with developing software on NeXTSTEP 3.3, I'll have to agree with you. For how old it is, it held up pretty well!
rasz 8y ago
Nah, it wasnt about raw speed, Doom doesnt even run all that well on next, its slower than 386DX40 on emulator trying to approximate NeXTcube Turbo speed.

jacquesm 8y ago

That's called porting. And whether or not it is a lot of work depends on how much foresight you had about doing that at some point in the future. If you didn't then it would be a very large amount of work because platform assumptions would be baked in all over the place. If you did - and you were a disciplined programmer - then it could be reasonably quick. I've written software that ported cleanly between Windows and SGI Irix, the original was built for the SGI and when windows capabilities caught up it was relatively straightforward to port, I tried very hard to keep all the platform dependent stuff in a single file so I knew exactly which bits to leave untouched and where to use the chainsaw.

outworlder 8y ago

It is not that big of a deal, although there was extra work required. You need to remember that Doom had a software renderer only. It only needed to be able to write to a color framebuffer for display. It also needed access to a keyboard, and sound. As long as you do it properly and carefully (and this is John Carmack we are talking about), it is not too difficult to abstract. You need to be careful not to paint yourself into a corner (endianness, pointer sizes, properly isolating platform-specific code, etc). That way you can develop most of the game without even touching the target hardware. Doom did have what would be nowadays called an "engine", only it was designed for that particular game. Id Software was probably one of the first (if not the first) company to sell a generic "3d Engine". In any case, the abstractions were there. They probably could not do the entire development using the NeXT workstations. At some point they would need real PCs to finish the port, and check how it worked on the target hardware. That was even more of an issue back then: although the C code could be cross-compiled (to solve the different CPU architecture problem), they did have lots of assembly code for performance. Nowadays, we are spoiled. iOS developers do exactly the same thing day to day as they did, only they don't even notice for the most part. Click a button on their Macbooks (which run amd64 arch), code get cross-compiled to ARM and linked with ARM-specific libraries. Android developers do the same, and they even have a fully emulated environment.

nbm 8y ago

If you're writing code in a language that compiles to multiple CPU architectures, it's not hard to get 90% of the way towards supporting all those CPU architectures without trying much. The remainder certainly requires some effort (much less if you think about it up-front) - this is where standard types like int, long, even char, and pointers, have different sizes - and where you can't just write out the memory format to a file if that's the same file you're loading on a different platform (even with the same type sizes, because of endianness). Writing cross-platform code, especially for early games where you're using a fairly restricted set of the platform code (and even less if you're doing a software renderer), is similarly not that hard in the common case if you've thought about it/have experience with it. There are a few different approaches, but even just having a single file that has POSIX and DOS compatibility functions (ie, above the stuff the C standard provides) and some macros could probably get you 90% of the way there. I don't mean to downplay how hard it is to, say, support multiple renderers, which is a problem that came later, or porting code that was written without any thought given to future portability. But given they knew they were supporting two platforms, it's not that hard to do (compared to the other, actually hard, stuff they did).

gameswithgo 8y ago

>Wouldn't be really hard to develop a MS-DOS game from another operative system and another CPU architecture? Nope, fortunately someone invented C!

kalleboo 8y ago

Probably just as important as developing the game engine, NeXT's programming environment also let them quickly and easily build tooling like level editors https://doomwiki.org/wiki/DoomEd https://doomwiki.org/wiki/DoomEd https://pbs.twimg.com/media/B3O6oJmCIAAGMi0.png:large https://pbs.twimg.com/media/B3O6oJmCIAAGMi0.png:large