Comments by "Mikko Rantalainen" (@MikkoRantalainen) on "John Carmack: Doom, Quake, VR, AGI, Programming, Video Games, and Rockets | Lex Fridman Podcast #309" video.

  1. 1:35:00 Listening to this discussion is a bit nostalgic because my first proper computer programming langauge was Pascal (to be exact, the Turbo Pascal variant by Borland) and I wrote simple realtime 3D graphics using mode 13h graphics (named after the value you had to set for the AL register before executing int 10 software interrupt, the key point was that this graphics mode had linear memory layout and didn't need paging or any other tricks to make pixels to appear on screen after CPU wrote the bits). In that time I wrote most of the program in Pascal but it supported inline assembly and I wrote the inner loop in assembly. I had one physical paper book about assembly instruction timings (basically how many clock cycles each instruction took to execute) and tried to come up with a sequence that was fast enough. And yeah, I considered id software games marvellous because they seemed to be able to compute maybe 2-8 times more pixels per second than my code. The major problem that Pascal had was that it only supported real mode 16 bit programming and once I started to do texture mapping stuff, it quickly become clear that I had to switch to Watcom DOS4GW stuff to allow use of 32 bit linear memory mode to use megabytes of RAM without headache. Hence C programming. Watcom C compiler also allowed use of inline assembly which which was nice.
    1
  2. The biggest problem with Pascal was poorly designed system for strings. Different compilers interpreted strings differently and there were serious limitations such as Turbo Pascal having maximum string length of 256 bytes.
    1
  3. I remember writing stuff in Quake C after already knowing Pascal and some C. It was a bit weird but allowed to create bots to play in multiplayer game maps that I created for me and my brothers to play using two computers and null modem.
    1
  4. 1:03:00 There's nothing more permanent than a temporary solution that works. Alway assume that the program you're writing now is critical infrastructure of a bigger system in a decade.
    1
  5. Modern mobile apps are really wasteful hardware-wise because the hardware is paid by the end user. As such, low performance code will not hurt the developer or the company as long as the app seems interesting enough for the end user. It turns out that end users are willing to get over $1000 mobile devices just for entertainment. If that's your expected user base, you don't need to care if a web page requires one or two gigabytes of RAM to run. 20 years ago computers used to have 32 MB RAM and web sites worked just fine.
    1