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 same sized binary, but instead increased it to 2300 bytes due to a newer C compiler. We ended up tweaking the assembly file and running an assembler, then praying there would be no more changes!
I have always over specified the micro-controllers a little from that point, and kept a copy of the original dev environment, luckily all my projects are now EOL as I am retired.
Correct, I have thousands of tank temperature controllers still out there, still working fine where the End Of Life was 3 years ago. EOL just means support for spares and software updates cannot be guaranteed past that point, and is mainly tied to the EOL of the specific micro-controller used.
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 it would have been quite a lot of work to reverse engineer the production version and retrofit its changes back to the source - and, yes, this is as bad as you think it is).
When I initially suggesting monkey patching the binary there was all manner of screaming and objections from my colleagues but they were eventually forced to concede that it was the pragmatic and sensible thing to do.
> it turned out that the version in source control wasn't the version running in production and it would have been quite a lot of work to reverse engineer the production version
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!
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.
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:08 in https://youtu.be/GC-0tCy4P1U — earlier section of the video is how it is today (or when the video was made)
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.
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.
Visual Assist provided much better completion especially for (then brand-new) C++98 if you used templates, STL etc heavily, but VC had its own completion out of the box that was actually pretty good for plain C code like Quake. AFAIR the "IntelliSense" branding was also in place already.
> 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, surely this was DJGPP on x86 PC?
Was DJGPP able to run on Alpha for cross compilation? I'm skeptical, but I could be wrong.
I thought the same thing. There wouldn't be a huge advantage to cross-compiling in this instance since the target platform can happily run the compiler?
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: "The original dos version of Quake should also be buildable from these
sources, but we didn't bother trying").
It's just not that big a codebase, even by 1990s standards. It was written by just a small team of amazing coders.
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. C is just really fast to build. Even back in, was it 1997, when the source code was found laying around on an ftp server or something: https://www.wired.com/1997/01/hackers-hack-crack-steal-quake...
"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?
Whats the problem? 1997? They were probably using 10BaseTX network, its 10Mbit...
Using Novel Netware would allow you to trasnfer data at 1MB/s.. quake.exe is < 0.5MB.. so trasnfer will take around 1 sec..
Networking in that era was not a problem. I also don’t know why you’re so steadfast in claiming that builds on local PCs were anything but painfully slow.
It’s also not just a question of local builds for development — people wanted centralized build servers to produce canonical regular builds. Given the choice between a PC and large Sun, DEC, or SGI hardware, the only rational choice was the big iron.
To think that local builds were fast, and that networking was a problem, leads me to question either your memory, whether you were there, or if you simply had an extremely non-representative developer experience in the 90s.
You keep claiming it somehow incurred substantial overhead relative to the potential gains from building on a large server.
Networking was a solved problem by the mid 90s, and moving the game executable and assets across the wire would have taken ~45 seconds on 10BaseT, and ~4 seconds on 100BaseT. Between Samba, NFS, and Netware, supporting DOS clients was trivial.
Large, multi-CPU systems — with PCI, gigabytes of RAM, and fast SCSI disks (often in striped RAID-0 configurations) — were not marginally faster than a desktop PC. The difference was night and day.
Did you actively work with big iron servers and ethernet deployments in the 90s? I ask because your recollection just does not remotely match my experience of that decade. My first job was deploying a campus-wide 10Base-T network and dual ISDN uplink in ~1993; by 1995 I was working as a software engineer at companies shipping for Solaris/IRIX/HP-UX/OpenServer/UnixWare/Digital UNIX/Windows NT/et al (and by the late 90s, Linux and FreeBSD).
That's exactly what you said, and it was incorrect:
> 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.
The network overhead was negligible. The gains were enormous.
> 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 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.
I remember two huge speedups back in the day: `gcc -pipe` and `make -j`.
`gcc -pipe` worked best when you had gobs of RAM. Disk I/O was so slow, especially compared to DRAM, that the ability to bypass all those temp file steps was a god-send. So you'd always opt for the pipeline if you could fill memory.
`make -j` was the easiest parallel processing hack ever. As long as you had multiple CPUs or cores, `make -j` would fill them up and keep them all busy as much as possible. Now, you could place artificial limits such as `-j4` or `-j8` if you wanted to hold back some resources or keep interactivity. But the parallelism was another god-send when you had a big compile job.
It was often a standard but informal benchmark to see how fast your system could rebuild a Linux kernel, or a distro of XFree86.
> (Visual Studio 6) I never used it but it must have felt like a dream at the time.
I used it in the mid-90's and yes, it was eye opening. On the other hand, I was an Emacs user in uni, and by studying a bit the history of Emacs (especially Lucid Emacs) I came to understand that the concepts in Visual Studio were nothing new.
On the third hand, I hated customizing Emacs, which did not have "batteries included" for things like "jump to definition", not to mention a package manager. So the only times in the late-90s I got all the power of modern IDEs was when I was doing something that needed Windows and Visual Studio.
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 super impressive, but it's something. Lol
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.
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
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.
Honestly I've been wondering if I could do this with Ezquake or similar (and how hard it would be). Problem is that Ezquake has VoIP too and a bunch of other things (and is for whatever reason stuck on SDL2 (?)), so that might be quite annoying to do. And I don't know if they'd accept my contributions. Worth a try though I suppose?
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.
This was my (hopeful) first thought on seeing this; his recent posts have been Quake-related. I do hope this is a harbinger of another installment. His others have been excellent.
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:
I like the font of old school IDEs like this. At one point I used Fixedsys Excelsior and Consolas exclusively, until I needed to run IDEs on Linux. I still love those blocky fonts but the lack of CJK alignment is quite annoying.
I've only played Quake I (and a modified version of it at that which had accessibility features). I did purchase quake II and III from Steam a few years ago, but it's much harder to play them because they have no accessibility to speak of (and I'm not entirely certain where to begin to try to replicate what was done with my version of Quake I). Quake in general has always been an insanely fun game for me, and I started playing it in like 2010. I still love playing it even now because it's got something to it that most other games I have just lack. Don't ask me to explain what it is because I can't really put it into words but...
> Exactly, VSCode is done by well known people from the GoF book, Visual Age and Eclipse IDEs.
That doesn't mean it's any good - which I admit is subjective. I'm sure they've put good devs doing a ton of work into making an IDE they believe in but having used it for a couple of years I don't enjoy the experience.
Nothing feels obvious or simple, and trying to work in Python or embedded C++ compared to using Jetbrains tools feels like I'm missing so much. I've gone back to pycharm community edition because IMO it's light-years ahead of vscode in usability.
I guess people say the same about emacs.
I maintain VC++ was a better experience than vscode; whoever is working on it.
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 same sized binary, but instead increased it to 2300 bytes due to a newer C compiler. We ended up tweaking the assembly file and running an assembler, then praying there would be no more changes!
I have always over specified the micro-controllers a little from that point, and kept a copy of the original dev environment, luckily all my projects are now EOL as I am retired.
"luckily all my projects are now EOL as I am retired."
I doubt that everything you ever worked on is end-of-life. Some of it is still out there...
Better have kept those environments.
Correct, I have thousands of tank temperature controllers still out there, still working fine where the End Of Life was 3 years ago. EOL just means support for spares and software updates cannot be guaranteed past that point, and is mainly tied to the EOL of the specific micro-controller used.
It's end-of-life.
If it it still running out there, it's runningin zombie state.
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 it would have been quite a lot of work to reverse engineer the production version and retrofit its changes back to the source - and, yes, this is as bad as you think it is).
When I initially suggesting monkey patching the binary there was all manner of screaming and objections from my colleagues but they were eventually forced to concede that it was the pragmatic and sensible thing to do.
> it turned out that the version in source control wasn't the version running in production and it would have been quite a lot of work to reverse engineer the production version
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!
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.
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:08 in https://youtu.be/GC-0tCy4P1U — earlier section of the video is how it is today (or when the video was made)
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.
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.
I think you were using some 3th party software for auto completion. There was project called Visual Assist with was pretty popular and powerfull tool.
Nope!
Visual Assist provided much better completion especially for (then brand-new) C++98 if you used templates, STL etc heavily, but VC had its own completion out of the box that was actually pretty good for plain C code like Quake. AFAIR the "IntelliSense" branding was also in place already.
> 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, surely this was DJGPP on x86 PC?
Was DJGPP able to run on Alpha for cross compilation? I'm skeptical, but I could be wrong.
Edit: Actually it looks like you could. But did they? https://www.delorie.com/djgpp/v2faq/faq22_9.html
I thought the same thing. There wouldn't be a huge advantage to cross-compiling in this instance since the target platform can happily run the compiler?
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: "The original dos version of Quake should also be buildable from these sources, but we didn't bother trying").
It's just not that big a codebase, even by 1990s standards. It was written by just a small team of amazing coders.
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. C is just really fast to build. Even back in, was it 1997, when the source code was found laying around on an ftp server or something: https://www.wired.com/1997/01/hackers-hack-crack-steal-quake...
"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?
Whats the problem? 1997? They were probably using 10BaseTX network, its 10Mbit... Using Novel Netware would allow you to trasnfer data at 1MB/s.. quake.exe is < 0.5MB.. so trasnfer will take around 1 sec..
Not sure what you mean by "problem". I said miniscule cancels out miniscule.
Networking in that era was not a problem. I also don’t know why you’re so steadfast in claiming that builds on local PCs were anything but painfully slow.
It’s also not just a question of local builds for development — people wanted centralized build servers to produce canonical regular builds. Given the choice between a PC and large Sun, DEC, or SGI hardware, the only rational choice was the big iron.
To think that local builds were fast, and that networking was a problem, leads me to question either your memory, whether you were there, or if you simply had an extremely non-representative developer experience in the 90s.
Again, I have no idea what you mean by networking being a "problem".
You keep claiming it somehow incurred substantial overhead relative to the potential gains from building on a large server.
Networking was a solved problem by the mid 90s, and moving the game executable and assets across the wire would have taken ~45 seconds on 10BaseT, and ~4 seconds on 100BaseT. Between Samba, NFS, and Netware, supporting DOS clients was trivial.
Large, multi-CPU systems — with PCI, gigabytes of RAM, and fast SCSI disks (often in striped RAID-0 configurations) — were not marginally faster than a desktop PC. The difference was night and day.
Did you actively work with big iron servers and ethernet deployments in the 90s? I ask because your recollection just does not remotely match my experience of that decade. My first job was deploying a campus-wide 10Base-T network and dual ISDN uplink in ~1993; by 1995 I was working as a software engineer at companies shipping for Solaris/IRIX/HP-UX/OpenServer/UnixWare/Digital UNIX/Windows NT/et al (and by the late 90s, Linux and FreeBSD).
Ok that's not what I said. So we'll just leave it there.
That's exactly what you said, and it was incorrect:
> 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.
The network overhead was negligible. The gains were enormous.
>> I said miniscule cancels out miniscule.
> You keep claiming it somehow incurred substantial overhead
This is going nowhere. You keep putting words in my mouth. Final message.
Jesus Christ. Networking was cheap. Local builds on a PC were expensive. You are pedantic, foolish, and wrong.
Were you even a developer in the 90s? Are you trying to annoy people?
> 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 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.
> 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.
I remember two huge speedups back in the day: `gcc -pipe` and `make -j`.
`gcc -pipe` worked best when you had gobs of RAM. Disk I/O was so slow, especially compared to DRAM, that the ability to bypass all those temp file steps was a god-send. So you'd always opt for the pipeline if you could fill memory.
`make -j` was the easiest parallel processing hack ever. As long as you had multiple CPUs or cores, `make -j` would fill them up and keep them all busy as much as possible. Now, you could place artificial limits such as `-j4` or `-j8` if you wanted to hold back some resources or keep interactivity. But the parallelism was another god-send when you had a big compile job.
It was often a standard but informal benchmark to see how fast your system could rebuild a Linux kernel, or a distro of XFree86.
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?
> (Visual Studio 6) I never used it but it must have felt like a dream at the time.
I used it in the mid-90's and yes, it was eye opening. On the other hand, I was an Emacs user in uni, and by studying a bit the history of Emacs (especially Lucid Emacs) I came to understand that the concepts in Visual Studio were nothing new.
On the third hand, I hated customizing Emacs, which did not have "batteries included" for things like "jump to definition", not to mention a package manager. So the only times in the late-90s I got all the power of modern IDEs was when I was doing something that needed Windows and Visual Studio.
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 super impressive, but it's something. Lol
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.
Honestly I've been wondering if I could do this with Ezquake or similar (and how hard it would be). Problem is that Ezquake has VoIP too and a bunch of other things (and is for whatever reason stuck on SDL2 (?)), so that might be quite annoying to do. And I don't know if they'd accept my contributions. Worth a try though I suppose?
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.
Quake book incoming from Fabien?
I hope so. The other books have been great fun to read, with the detour of CP-SYSTEM as a nice surprise.
Almost certainly - every other of his books has been telegraphed by articles about the work he’s doing to get the original setup built and running.
This was my (hopeful) first thought on seeing this; his recent posts have been Quake-related. I do hope this is a harbinger of another installment. His others have been excellent.
love 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/item?id=39901290
If you're into that kind of thing, May I strongly suggest https://virtuallyfun.com/ ? It's an absolute gold mine of amazing stuff along these lines
The part messing up the workspace files (dsw) is very important for anyone that plans to use Visual C++ 6.0 with git!
There's also an easy fix: https://github.com/krystalgamer/spidey-decomp/blob/ad49c0f5f...
I'd like to see someone build the Linux source code leak that came out not to far after Quake was released.
What do you mean, "leak"? Linux would have been developed in the open?
I think OP means leak of linux quake port source
I think they are referring to the 1997 hack/leak: https://www.wired.com/1997/01/hackers-hack-crack-steal-quake...
I like the font of old school IDEs like this. At one point I used Fixedsys Excelsior and Consolas exclusively, until I needed to run IDEs on Linux. I still love those blocky fonts but the lack of CJK alignment is quite annoying.
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.
I never used the Turbo stuff, but I know they were very good for the time by reading about people using them in Dr. Dobbs.
I started with C on the Amiga and then went to UNIX and only later starting doing Windows coding on Windows 3.1.
It needs to be Visual C++ 5.0, since 6.0 came out in 1998.
Funny, I've just been (re-)playing Quake 2 recently.
Action Quake II is still the best I’ve ever been at FPS.
Nod. AQ2 was so damn fun!!
I've only played Quake I (and a modified version of it at that which had accessibility features). I did purchase quake II and III from Steam a few years ago, but it's much harder to play them because they have no accessibility to speak of (and I'm not entirely certain where to begin to try to replicate what was done with my version of Quake I). Quake in general has always been an insanely fun game for me, and I started playing it in like 2010. I still love playing it even now because it's got something to it that most other games I have just lack. Don't ask me to explain what it is because I can't really put it into words but...
qpong, generations mod, catch the chicken, red rover, weapons of mass destruction, 4 way ctf, freeze tag....so many good mods
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/
Yes, such a good game! :)
Gonna warm that up when the kids get a bit older and we start doing LAN parties.
That and Quake World Team Fortress.
Same here. Clan wars on the ESL, visiting people for LAN parties, all around a good time.
VC++ 6 was made by the same company that made VS Code.
But not the same people or culture.
Exactly, VSCode is done by well known people from the GoF book, Visual Age and Eclipse IDEs.
> Exactly, VSCode is done by well known people from the GoF book, Visual Age and Eclipse IDEs.
That doesn't mean it's any good - which I admit is subjective. I'm sure they've put good devs doing a ton of work into making an IDE they believe in but having used it for a couple of years I don't enjoy the experience.
Nothing feels obvious or simple, and trying to work in Python or embedded C++ compared to using Jetbrains tools feels like I'm missing so much. I've gone back to pycharm community edition because IMO it's light-years ahead of vscode in usability.
I guess people say the same about emacs.
I maintain VC++ was a better experience than vscode; whoever is working on it.