Have to hand it out to Fabien, he's not just an amazing developer with baffling skills to understand code and graphical routines, his dedication to understanding old games of yore is second to none.
Maybe off-topic, but the rest of the website is a trove of knowledge. As a long-time developer who is now trying to pick up graphics/gaming side of coding ... I'm so glad there are folks generous enough to spend time writing and sharing. Thank you!
Its nice that they made it public domain. There are 1000 more games from that era whose code will simply dissapear despite being simply bits and bytes that may be perfectly preserved for ever.
Only the engine is open, though, not the data files. EDIT: And it's not "public domain" either. Look at the license.doc in the github repository, there are tons of restrictions as to what you can do with the code. https://github.com/id-Software/wolf3d
It is like when Microsoft released the source code for MS-DOS 2.0 and MS-Word 1.1C not open sourced but some kind of commercial license that limits use and derivatives.
It kind of reminds me of that old Borland Museum that had the old Turbo languages for free download.
http://edn.embarcadero.com/museum
Sadly they stopped releasing old versions in 2005. I had hoped there to be a Delphi 1.0 release. I actually got Delphi 1.0 on a magazine CD-ROM from some UK magazine I bought, and then forgot where I placed it. I used to program in Delphi 1.0 and 2.0 I still got my 2.0 book and how to make code Y2K compatible in it.
I got old Visual BASIC versions as well.
It seems this is the Wolf3D source code without the data files so you have to use the shareware version of Wolf3D or Spear or buy the commercial versions.
It is written for 16 bit code for DOS, so converting it to 32 bits won't work. They had to use a lot of tricks for 386 and under machines just to get it to work in 3D mode. 486+ machines run it better but at a certain level it does not scale very well.
Basically it was a f*-it by ID, just release the code for the LULZ, throw on a commercial license to limit use, and then see what happens to it.
Turbo C 1.0 was actually pre-ANSI C. Turbo C 2.0 was compatible with a draft of the ANSI C standard, and I recall having some trouble getting Lua 5.0 to compile with it due to locale stuff.
The video actually features Turbo C++ 1.0, though, which was a different product, so the title is misleading.
Regardless, I agree that standards are very nice to have.
Borland 3.1 also came as a graphical IDE. For a while Borland was ahead of Microsoft's character-based Programmer's Workbench. Borland had a great IDE.
My company stuck with Borland until 4.5. We parted ways when the compiler generated code that GPF'ed when calling 'new' in a DLL, or declared some global variables undefined that had successfully compiled a few modules earlier. Also, Borland couldn't step through 32-bit code in debug mode. Visual Studio 6 could.
I remember getting the Borland C compiler as a ten or eleven year old and thinking, twenty megabytes! What in the world could they need twenty megabytes for? That was like, my entire hard drive.
Does anyone else find it sorta ironically odd that one of the masterminds behind this great stuff is now a .... gasp Facebook ... employee?? my heart kinda aches.
An Aug 2nd tweet from John Carmack started "Onboarding at Facebook went well...". My thought was "nobody onboards that guy?!?! he onboards YOU!!" I just hope talent like John Carmack can still spread their wings in that environment and do the things that got them to that point.
> Does anyone else find it sorta ironically odd that one of the masterminds behind this great stuff is now a .... gasp Facebook ... employee??
Would you be referring to the business morals or technical requirements of Facebook? You need a lot of good hacks to deal with large bulks of data. For example: https://github.com/facebook/warp
I heard Goooogle developed Go partially because they were fed up with the time taken up compiling massive C programs.
Nice trip down memory lane (and a good counter-example to those who claim that web development today is soooo much more complicated and tedious than desktop development was back in the day...).
Well, that's true but it could still technically "build", I suppose, what you describe are runtime issues, not build issues. I assume there are other reasons that prevent building with modern compilers?
I would assume that the first problem would be to find a modern compiler that could target 16bit DOS in the first place...
Looks like the code has inline x86 assembly in the Borland format, so that would probably need to be converted for a different C compiler. There are likely to be other, not so obvious dependencies on compiler-specific features.
Nice job, Fabien!