Earlier quoted context omitted.
Action Quake II is still the best I’ve ever been at FPS.
Nod. AQ2 was so damn fun!!
Let's compile Quake like it's 1997
51–60 of 91 posts
Re: Let's compile Quake like it's 1997
#52Earlier quoted context omitted.
Running your builds on a much larger, higher performance server — using a real, decent, stable multi-user OS with proper networking — is a huge advantage.
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 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 big iron ultrasparc machines because the performance difference was so huge — more CPUs, much faster disks, and lots more RAM.
That gap disappeared pretty quickly as we headed into the 2000s, but in 1997 it was still very large.
Re: Let's compile Quake like it's 1997
#53[flagged]
Re: Let's compile Quake like it's 1997
#54Quake book incoming from Fabien?
Re: Let's compile Quake like it's 1997
#55love software archaeology like this. there was another article where someone bootstrapped the very first version of gcc that had the i386 backend added to it, and it turns out there was a bug in the codegen. I'll try to find it... EDIT: Found in, infact there was a HN discussion about an article referencing the original article: https://miyuki.github.io/2017/10/04/gcc-archaeology-1.html https://news.ycombinator.com/i…
Re: Let's compile Quake like it's 1997
#56> 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…
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.
Re: Let's compile Quake like it's 1997
#57Earlier quoted context omitted.
Linux also used to have separate SMP kernels back when multi processor systems were rare.
I’m pretty sure that the SMP kernel would boot on UP and vice versa, though.
But even in the era of LILO you could switch kernels pretty easily.
Re: Let's compile Quake like it's 1997
#58Earlier 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.
Re: Let's compile Quake like it's 1997
#59Re: Let's compile Quake like it's 1997
#60Earlier quoted context omitted.
Could also just edit the old binary directly in a pinch?
Whilst I disapprove of your use of the word "just", which I am strongly of the opinion should be banned in engineering circles... I have done something similar, albeit in a different context, to fix the behaviour of a poorly performing SQL query embedded in a binary for which the source code was not easily available (as in: it turned out that the version in source control wasn't the version running in production and…
When I started at my work, a previous software dev with practices more like a mechanic than a software dev didn't use tags and all binaries deployed to production were always the default version 1.0.0.0 of the C# project templates in Visual Studio. To make matters worse, variants of the software were just copy pasted in CVS with their core code checked in as binaries and not their original C# projects. Fun times finding out what actually ran on production, and patching anything in it!