Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's compile Quake like it's 1997

fabiensanglard.net

Post reply on HN
Print view View original

41–50 of 91 posts

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

#41

Post by reactordev »

direwolf20 wrote: post #16

Visual C++ 6 was the first C(++) compiler I used. I'm fairly certain it had auto completion (Intellisense). Casey Muratori would point out the debugger ran faster on hardware from the era than modern versions run on today's hardware, though I don't have a link to the side–by–side video comparison. Edit: Casey Muratori showing off the speed of visual studio 6 on a Pentium something after ranting about it: Jump to 36:0…

absolutely! When launching my editor today, it phones home, it checks location, it does everything that an editor SHOULDN'T DO. Not to mention the extensions...

Software today is a horrible bloated mess on top of horrible bloated messes.

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

#43

Post by mananaysiempre »

do_not_redeem wrote: post #25
kccqzy wrote: post #23

Earlier quoted context omitted.

I actually would love this to be built in to a language/compiler. A lot of times when I’m building a single-threaded program but I’m using libraries written by other people. These libraries don’t know whether they are being incorporated into programs with single thread or not. So they either take the performance penalty of assuming multi-threaded (the approach by std::shared_ptr) or they give callers choice by making…

Zig supports this. If you compile with -fsingle-threaded, operations on mutexes turn into nops, atomics become simple loads/stores, etc.

Glibc has a bunch of tests throughout the codebase where it checks if there have been any threads started besides the main one. I don’t really know how effective they are from a performance perspective. (In principle, turning fgetc into getc_unlocked, for instance, could be quite beneficial.) Microsoft used to have a single-threaded C runtime, but it was done away with some time ago, I’m guessing because they started putting things into the platform that would start and manage random threads outside the programmer’s control.

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

#44

Post by reactordev »

ethin wrote: post #38

It's really ironic that this appeared on the front page when it did, because I've spent the last couple days replacing the ZQuake sound system with FMOD and Atmoky TrueSpatial for HRTF and such. This was my first time ever working on a code base from 1996-2000. And in pure C no less. C feels so foreign to me since I'm so used to writing in C++ and Zig and such. But it was still really fun! And I mean it doesn't seem…

you could have chosen a far worse codebase than Quake from the 90s. Quake was pretty clean in comparison. Sensible use of macros for doing things. A type system that made sense.

Descent on the other hand...

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

#45

Post by gatane »

ErroneousBosh wrote: post #36
bombcar wrote: post #20

Earlier quoted context omitted.

Action Quake II is still the best I’ve ever been at FPS.

I'd kind of forgotten about AQ2. I wonder if I can get that going. I bet there are still servers out there, at that.

Last time I played, the servers were empty. Maybe you could have better luck by finding their discord server...

https://q2online.net/action

https://store.steampowered.com/app/1978800/AQtion/

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

#46

Post by ethin »

reactordev wrote: post #44
ethin wrote: post #38

It's really ironic that this appeared on the front page when it did, because I've spent the last couple days replacing the ZQuake sound system with FMOD and Atmoky TrueSpatial for HRTF and such. This was my first time ever working on a code base from 1996-2000. And in pure C no less. C feels so foreign to me since I'm so used to writing in C++ and Zig and such. But it was still really fun! And I mean it doesn't seem…

you could have chosen a far worse codebase than Quake from the 90s. Quake was pretty clean in comparison. Sensible use of macros for doing things. A type system that made sense. Descent on the other hand...

I mean... It's ugly from a modern standpoint. Zero encapsulation to speak of. Global state everywhere. But doing the modifications I did were pretty easy all things considered. So yeah, the code is clean, if "ugly" when viewed from a modern standpoint. It was definitely fun to do either way! Idk what other changes I'll make, we'll see. Especially since I don't know the architecture very well yet

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

#47

Post by billforsternz »

Neywiny wrote: post #27
boznz wrote: post #13

On one particular project from 1995 where the hardware was very cost optimised, the C program compiled to 1800 bytes which meant we could save nearly a dollar by buying micro-controllers with 2KB flash rather than 4KB flash. We manufactured 20,000 units with this cheaper chip. 2 years down the line we needed a simple code change to increase the UART baud rate to the host, a change that should have resulted in the sam…

Could also just edit the old binary directly in a pinch?

One of my best rescue jobs involved doing this in 1999, yes that 1999. The client had shuttered their development department years before but was expecting to continue happily supporting and selling their simple enough alarm system products indefinitely. Testing revealed that come 2000 the alarms would just fire continually. Whoops. Fortunately there was one dev PC they'd decided to keep and not touch. Found the offending .c code and the corresponding offending machine code after some disassembly. A little bit of creative assembly language was required to squeeze an extra check in but really no big deal and the day was saved. I remember the client manager being ridiculously happy and grateful.

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

#48

Post by pdw »

knorker wrote: post #34
frumplestlatz wrote: post #30

Earlier 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…

"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.

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

#49

Post by reactordev »

ethin wrote: post #46
reactordev wrote: post #44

Earlier quoted context omitted.

you could have chosen a far worse codebase than Quake from the 90s. Quake was pretty clean in comparison. Sensible use of macros for doing things. A type system that made sense. Descent on the other hand...

I mean... It's ugly from a modern standpoint. Zero encapsulation to speak of. Global state everywhere . But doing the modifications I did were pretty easy all things considered. So yeah, the code is clean, if "ugly" when viewed from a modern standpoint. It was definitely fun to do either way! Idk what other changes I'll make, we'll see. Especially since I don't know the architecture very well yet

Of course! Global state IS game state!

It definitely was an amazing codebase for the time. You didn’t need to get hung up on architecture because it is very singular… it’s just a level, you, and the entities that were created when the level loaded.

There’s no pre-caching, no virtual textures, no shaders (there are materials for later quake 3), it’s just pure load -> set -> loop. The “client” renders, the “server” has the state.

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

#50

Post by ack_complete »

direwolf20 wrote: post #16

Visual C++ 6 was the first C(++) compiler I used. I'm fairly certain it had auto completion (Intellisense). Casey Muratori would point out the debugger ran faster on hardware from the era than modern versions run on today's hardware, though I don't have a link to the side–by–side video comparison. Edit: Casey Muratori showing off the speed of visual studio 6 on a Pentium something after ranting about it: Jump to 36:0…

The VS debugger got an order of magnitude slower in the transition from VS6 to Visual Studio .NET. It's been sped up a bit but is still nowhere near as fast as the VS6 debugger at responding to step commands, debug output, or conditional breakpoints. In VS.NET you could be waiting as long as a full second on a contemporary dev machine for the debugger to finish stepping forward one line.

Funny thing is that at the time, I was lamenting how much slower VC6 was than VC4. Macro playback, for instance, got much slower in VC6. It's all relative.

Post reply on HN