Comment Well, Now I Have to Read The Thing... (Score 1) 323
I worked for NTG/3DO for just under five years, so I know (knew) the machine inside and out. It will be interesting to go through this code and see what kind of tradeoffs were made.
Some comments on the README:
My friends at 3DO were begging for DOOM to be on their platform and with christmas 1995 coming soon (I took this job in August of 1995, with a mid October golden master date), I literally lived in my office, only taking breaks to take a nap and got this port completed.
*snerk* I could have told you at the time that a ten-week dev cycle was crazy talk.
Shortcuts made...
3DO's operating system was designed around running an app and purging, there was numerous bugs caused by memory leaks. So when I wanted to load the Logicware and id software logos on startup, the 3DO leaked the memory so to solve that, I created two apps, one to draw the 3do logo and the other to show the logicware logo. After they executed, they were purged from memory and the main game could run without loss of memory.
An interesting and valid approach (3DO's OS had full memory tracking). I'd be interested to know which of the 3DO libs was leaking memory on you.
The verticle walls were drawn with strips using the cell engine. However, the cell engine can't handle 3D perspective so the floors and ceilings were drawn with software rendering. I simply ran out of time to translate the code to use the cell engine because the implementation I had caused texture tearing.
Were the floor/ceiling textures not power-of-two dimensions on each side? As I recall, you only got texture cracking when the dimensions were not power-of-two.
You could have decomposed the floor/ceiling textures into strips as well, but ultimately the lack of perspective correction meant you were going to have to do some heavy lifting somewhere.
I had to write my own string.h ANSI C library because the one 3DO supplied with their compiler had bugs! string.h??? How can you screw that up!?!?! They did! I spent a day writing all of the functions I needed in ARM 6 assembly.
Ah, yes, the Norcroft compiler (or, as I always called it, Norcruft). It was a piece of shit. It was also the only thing available that would run on the Mac. It was never anything but a C compiler, but kept throwing unblockable warnings about constructs that C++ would have problems with (such as implicit cast from void*). There was no MacOS port of GCC, and there were no usable ARM backends for GCC available at the time, anyway. (Bear in mind, this was before the Web existed in any familiar form, and you had to go trawling through USENET for clues -- not even AltaVista existed yet).
I hope that everyone who looks at this code, learns something from it, and I'd be happy to answer questions about the hell I went through to make this game. I only wished I had more time to actually polish this back in 1995 so instead of being the worst port of DOOM, it would have been the best one.
I'm sure many memories will come flooding back.
