Live data from Hacker News

Let's compile Quake like it's 1997

fabiensanglard.net

81–90 of 91 posts

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

#82
post #76

Earlier quoted context omitted.

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…

Again, I have no idea what you mean by networking being a "problem".

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

#83
post #82

Earlier quoted context omitted.

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…

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

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

#84
post #82

Earlier quoted context omitted.

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

Ok that's not what I said. So we'll just leave it there.

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

#85
post #84

Earlier quoted context omitted.

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

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.

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

#86
post #84

Earlier quoted context omitted.

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.

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

#87
post #86

Earlier quoted context omitted.

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?

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

#88
post #72

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…

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.

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.

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

#90
post #67
post #64

Earlier quoted context omitted.

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.

Post reply on HN