Live data from Hacker News

Let's compile Quake like it's 1997

fabiensanglard.net

61–70 of 91 posts

Re: Let's compile Quake like it's 1997

#61
I tried to capture that specific VS 6.0 vibe with a text editor color theme I made, Studio 98 (for Visual Studio Code and Vim/Neovim). I actually sampled the hex values from Fabien Sanglard’s Quake/NT 4.0 blog screenshots to update it.

Link: https://github.com/jnz/studio98

Can't fix the Electron sluggishness compared to VS6, but at least the syntax highlighting feels a bit like home.

Re: Let's compile Quake like it's 1997

#62
post #31
post #29

Earlier quoted context omitted.

With NT4, I'm pretty sure both HALs were on the CD-ROM (unless you had an exotic system with a custom HAL, which came with its own install media). Keep in mind your use case is approximately nobody, you either had a SMP system or you didn't.

It was really not that rare to want to move a disk from one system to another. Except that there was an obnoxiously high chance that Windows would refuse to boot.

Yeah, remember the primary disk controller was set in the registry. (And on an SMP system probably some specific SCSI.) You could fix that, but easier to reinstall. Of all the things to bitch about, this one seems strained.

Re: Let's compile Quake like it's 1997

#65

[flagged]

there is something to be said about old windows installation CDs being essentially modern-day equivalents of immutable docker layers - i don't think one could say that about modern windows, but then i'm not super clued in into ms stuff.

With all the problems that recent Windows updates are causing, and a blog post about how the Windows team are using Native React to deliver changes to the apps such as a part of Settings outside the usual updates I got to thinking how great it was back in the Windows 3.11, 95, and XP days when you got Windows and it mostly worked and it didn't get updated (aka more broken) every day. It was quick enough, it was yours, and it didn't tell you what to do.

You'd reinstall every year or two to clean out the disused DLLs etc, but it was mostly fine.

Of course it wasn't exposed to quite the same hostile environment it is today.

Re: Let's compile Quake like it's 1997

#66
post #63

I used Visual C in the early 90s and it was a dream compared to vi and whatever C compiler the various unices I was using had.

That was already the case when comparing the Borland compilers for MS-DOS, and Windows 3.x.

Hence why I eventually found refuge in XEmacs, and DDD, until IDEs like KDevelop and Sun Forte came to be.

Re: Let's compile Quake like it's 1997

#68
post #48
post #34

Earlier quoted context omitted.

Yes, but the gains may be lost in the logistics of shipping the build binary back to the PC for actual execution. An incremental build of C (not C++) code is pretty fast, and was pretty fast back then too. In q1source.zip this article links to is only 198k lines spread across 384 files. The largest file is 3391 lines. Though the linked q1source.zip is QW and WinQuake, so not exactly the DJGPP build. (quote the README…

"Shipping" wouldn't be a problem, they could just run it from a network drive. Their PCs were networked, they needed to test deathmatches after all ;) And the compilation speed difference wouldn't be small. The HP workstations they were using were "entry level" systems with (at max spec) a 100MHz CPU. Their Alpha server had four CPUs running at probably 275MHz. I know which system I would choose for compiles.

> "Shipping" wouldn't be a problem, they could just run it from a network drive.

This is exactly the shipping I'm talking about. The gains would be so miniscule (because, again, and incremental compile was never actually slow even on the PC) and the network overhead adds up. Especially back then.

> just run it from a network drive.

It still needs to be transferred to run.

> I know which system I would choose for compiles.

All else equal, perhaps. But were you actually a developer in the 90s?

Re: Let's compile Quake like it's 1997

#69
post #34

Earlier quoted context omitted.

Yes, but the gains may be lost in the logistics of shipping the build binary back to the PC for actual execution. An incremental build of C (not C++) code is pretty fast, and was pretty fast back then too. In q1source.zip this article links to is only 198k lines spread across 384 files. The largest file is 3391 lines. Though the linked q1source.zip is QW and WinQuake, so not exactly the DJGPP build. (quote the README…

> I mean correct me if you have actual data to prove me wrong, but my memory at the time is that build times were really not a problem. I never had cause to build quake, but my Linux kernel builds took something like 3-4 hours on an i486. It was a bit better on the dual socket pentium I had at work, but it was still painfully slow. I specifically remember setting up gcc cross toolchains to build Linux binaries on our…

> Linux kernel builds took something like 3-4 hours on an i486

From cold, or from modified config.h, sure. But also keep in mind that the Pentium came out in 1993.

Re: Let's compile Quake like it's 1997

#70
post #5

> The first batches of Quake executables, quake.exe and vquake.exe were programmed on HP 712-60 running NeXT and cross-compiled with DJGPP running on a DEC Alpha server 2100A. Is that accurate? I thought DJGPP only ran on and for PC compatible x86. ID had Alpha for things like running qbps and light and vis (these took for--ever to run, so the alpha SMP was really useful), but for building the actual DOS binaries, su…

I asked John Carmack and he told me they did. There is also an interview of Dave Tayor explicitly mentioning compiling Quake on the Alpha in 20s (source: https://www.gamers.org/dhs/usavisit/dallas.html#:~:text=comp... I don't think he meant running qbsp or vis or light.

> he told me they did.

This is when they (or at least Carmack) was doing development on Next? So were those the DOS builds?

Post reply on HN