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...
Let's compile Quake like it's 1997
71–80 of 91 posts
Re: Let's compile Quake like it's 1997
#72Visual 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.
Re: Let's compile Quake like it's 1997
#73Earlier quoted context omitted.
"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 comp…
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..
Re: Let's compile Quake like it's 1997
#74Earlier 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…
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.
Re: Let's compile Quake like it's 1997
#75Earlier quoted context omitted.
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…
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?
Re: Let's compile Quake like it's 1997
#76Earlier quoted context omitted.
> "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 comp…
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.
Re: Let's compile Quake like it's 1997
#77Re: Let's compile Quake like it's 1997
#78On 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…
"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...
It's end-of-life.
If it it still running out there, it's runningin zombie state.
Re: Let's compile Quake like it's 1997
#79Earlier quoted context omitted.
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.
Re: Let's compile Quake like it's 1997
#80Visual 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.
Nope!