How Id built Wolfenstein 3D using Commander Keen tech

How did you become the current owner? I'm very curious about how you went about obtaining the rights.

>Fabien's Game Engine Black Book

>Hovertank and Catacomb

One omission from that book that would have been nice to have been included is an explanation of how the 3D scenes are drawn in those games. In one of the quoted passages, Carmack states that it is something other than the raycasting used in Wolf3D, with the added disadvantage of not being correct in every case.

From personal observation, the perspective looks strange in those games (no consistent single vanishing point). However, maybe this can be fixed by tweaking a few variables. Supposedly Catacomb and Hovertank have much higher frame rates that Wolf3D on old computers.

(another omission is that it doesn't completely explain the theory behind linear feedback shift registers, necessitating further research on the part of the reader to understand them).

I wish the owner of the Keen Dreams IP was as dedicated and resourceful as you are. I have a feeling we've lost that one for good.

I have really fond memories of buying Catacomb Abyss by mail order in the early 90s when I was 11 years old. We used to play — my brother and sister were younger than me — with the lights turned off, terrifying!

> It can’t be understated how much impact Wolfenstein 3D and Doom had. Commander Keen was already quite the tech demo, with scrolling on a PC without dedicated hardware

But ... the PC did have hardware supported scrolling? CGA, EGA, VGA and the various SVGAs all had a register for "address of beginning of screen". It was not well documented, and nontrivial to use especially because of the banked memory setup -- but it WAS there even on the first ever CGA, Hercules and Monochrome adapter which were all based on the 6845 - and also available on EGA, VGA etc - the latter made things even less usable by practically requiring Mode-X plane memory addressing to use.

And IIRC, that's what commander keen had used.

[0] https://en.wikipedia.org/wiki/Motorola_6845#Tricks

Looking back, it is hard to believe so much famous games were released in such a short amount of time, in the early 90s. 1991 was the year of Civilization, Lemmings, Street Fighter II and the first SNES Zelda.

The classics of gaming were laid during these years.

I've played much "better" games than Doom in many ways, but never one so revolutionary for its time, and I've never been so genuinely afraid when playing.

But seriously: Overstated! You mean overstated!

We debate so much about feature creep in our relatively simple apps. Doom came around and gave us features we didn’t even know were possible.

VGA has pixel perfect hardware scrolling in unchained mode "Mode-X".

Databases?

Many times in programming, someone has given a name to something long after a segment of the population had already discovered it for themselves. This can lead to a weird effect where people who in fact approve of a technique end up sounding dismissive because of course everyone already does this it's no big deal. Not everyone is doing this and it can be a big deal.

To date myself a bit, the first time for me was Refactoring, and one of the most recent was the Mikado method (a technique for top-down refactoring). The reason I'm book-ended this way, and the point of my response, is that Mikado requires you to be very comfortable both with version control and throwing away a big chunk of code you just wrote.

I don't think I would have ever sussed out Mikado if I were trying to do Poor Man's version control. I think the cost-benefit analysis would fail.

The thing is, the Mikado method, at its best, makes you look like some sort of coding god, because you've accomplished some gigantic change to the system behavior with fifty lines of terribly reasonable code. Instead of five hundred lines of error-prone nightmare.

Version control software was a lot more primitive and less fun to use in the 90s. On Unix you had CVS, on Windows just VSS. SVN, Mercurial and Git all came post 2000.

> Impressive id went through development of Quake 3 with no version control.

I'd say that taking a backup of the code at the end of the day and sticking it all in a directory on a server somewhere constitutes version control. Especially as Id documented everything they did so thoroughly (based on Carmack's .plan files etc).

When SVN and Git came along they basically just streamlined and improved practices that a lot of devs were already following - and added some useful features like merging with proper conflict resolution and whatnot.

Where could I find his code to take a look at? Is there a reputable source or should I just Google it?

There was a transition from the 80s to late 90s: until you had some kind of network, the important thing was to backup your machine. Daily if you can. Even if you had been running a local revision control on your local machine, you wouldn't be protected enough, so backups were more important.

Once networking and servers became more prevalent, it slowly made sense that backups turned into revision control. If your machine crashes, there is a remote repo you can connect to and get back to where you were.

Their one NeXT computer cost even more, $6500 base price.

Interestingly that's the exact PC my dad bought us when we were kids. I loved how computers back then had a turbo button, but I could never figure out why anyone would turn off turbo! :P

I remember Doom pushing a much higher frame rate than that with those specs. The real issue was that you needed L2 cache!

Ummm.... I remember my father gifting me a 386DX 40Mhz with 4 MiB of RAM, 200MiB IDE hard disk and one of the first X2 CD-ROM that support all CD-ROM formats. All this on 1990 or 1991. Before, I had a ZX Spectrum +3. I really have good memories from these two computers.

I remember running wolf3d.exe on my 386SX/16MHz in the mid-1990s, and it wouldn't run worth a damn unless the game display size was reduced to the lowest possible setting, about the size of a business card on the ol' VGA CRT. I spent many hours squinting at pixel-Nazis.

Now, some 25 years later, I have been playing through Wolfenstein II: The New Colossus, and I had nostalgic good fun playing several levels of the original Wolfenstein via an in-game arcade machine.

I like stories.

That price seems a little high. I was selling these from a custom shop in 1994 and a pretty well equipped 486 and then Pentium was about $2,000 to $2,500. You could spend a bit more and get better audio and video cards, but the base models at the time ran Doom and Quake pretty well. Computers seem like they have stayed in that range all my life. Back then I had a $2k desktop and today I have a $2k MacBook. There were always cheaper options for budget conscious buyers and the sky has always been the limit if you want to go crazy.

I've tried using that book to explain to people how "real" software development works. How the inception of the real cool shit, the stuff that spawns a company, is almost always 2, 3 or a small handful of people working late, night after night, living on pizzas and cola, churning code. And how that apparent anarchy is a more productive environment that ten pointy headed bosses plugging away at their gantt charts and a hundred 9 to 5 developers carrying out their orders.

It's a bit hagiographic, but it's overall a very good book.

> as recent as Rise of the Triad

Released December 21, 1994

John talks about Id's Software Principles, one of the YouTube commenters (Sean Ramey) summarized them below:

1. No prototypes. Just make the game. Polish as you go. Don't depend on polish happening later. Always maintain constantly shippable code. (Large teams require more planning though.)

2. It's incredibly important that your game can always be run by your team. Bulletproof your engine by providing defaults (for input data) upon load failure.

3. Keep your code absolutely simple. Keep looking at your functions and figure out how you can simplify further.

4. Great tools help make great games. Spend as much time on tools as possible.

5. We are our own best testing team and should never allow anyone else to experience bugs or see the game crash. Don't waste others' time. Test thoroughly before checking in your code.

6. As soon as you see a bug, you fix it. Do not continue on. If you don't fix your bugs your new code will be built on a buggy codebase and ensure an unstable foundation.

7. Use a development system that is superior to your target.

8. Write your code for this game only - not for a future game. You're going to be writing new code later because you'll be smarter.

9. Encapsulate functionality to ensure design consistency. This minimizes mistakes and saves design time.

10. Try to code transparently. Tell your lead and peers exactly how you are going to solve your current task and get feedback and advice. Do not treat game programming like each coder is a black box. The project could go off the rails and cause delays.

11. Programming is a creative art form based in logic. Every programmer is different and will code differently. It's the output that matters.

Extra advice:

1. Only program for a few minutes and test code immediately. Try not to code for even as long as 30 minutes. This is will help to avoid debugging because you will catch bugs sooner, and won't have as wide an area of code to look through for the bug.

You are not making an equal comparison. DOS at the time didn't have multiple windows or multitasking. People that don't use IDEs these days still use multiple terminals or windows.

Using the Borland C++ IDE in 1991 is way more similar to using Emacs these days, than Visual Studio Code.

FWIW, I've had an account here for 5 years (last month in fact) and am typically here for an hour or so every day and have never seen anyone make this claim.

They didn't use IDEs that consumed all of their RAM though.

Yep, I started with Apple II and UCSD Pascal and kept using IDE since then... I can dive in the terminal and use make if needed but it feels unnatural to me.

I loved a recent quote from James Gosling regarding his love for IDEs.

He just wants to get work done, doesn't feel the need to prove anything.

Specially interesting, given XEmacs.

Used to get severe motion sickness too until I figured out it went away at high FPS. At least for well made games with low input latency.

With a good 1000Hz wired mouse and games I where I get at least 100fps, preferably >144fps, I don't feel anything at all when I play. Still can't watch others play though.

"Borland’s solution was an all-in-one package. The IDE, BC.EXE, despite some instabilities allowed crude multi-windows code editing with pleasant syntax highlights. The compiler and linker were also part of the package under BCC.EXE and TLINK.EXE."

It is quite clear on the figure captions, Borland C++ 3.1.

Others have said that. I remember playing with BC.exe and the free DJGPP + Allegro library to make games at that time... oh man those were the days to make games, it was romantic (and I was in secondary school). Too bad I was not in an environment to be nurtured.