It's amusing to me that in the 90s you could easily play Quake or Doom with your friends by calling their phone number over the modem whereas now setting up any sort of multiplayer essentially requires a server unless you use some very user-unfriendly NAT busting.
I wonder if there is a way to use tailscale to make it easy again?
How Quake.exe got its TCP/IP stack
61–70 of 158 posts
Re: How Quake.exe got its TCP/IP stack
#62It's amusing to me that in the 90s you could easily play Quake or Doom with your friends by calling their phone number over the modem whereas now setting up any sort of multiplayer essentially requires a server unless you use some very user-unfriendly NAT busting.
Glad you mentioned DOOM! Sometimes people forget that DOOM supported multiplayer as early as December 1993, via a serial line and February 1994 for IPX networking. 4 player games on a LAN in 1994! On release, TCP/IP wasn't supported at all, but as the Internet took off, that was solved as well. I remember testing an early-ish version of the 3rd party iDOOM TCP setup driver from my dorm room (10 base T connection) whe…
Downside is that your framerate was capped to the person with the slowest computer, and there was always that guy with the 486sx25 who got invited to play.
Re: How Quake.exe got its TCP/IP stack
#63Earlier quoted context omitted.
Yeah, but dial-up was slow, laggy, and what 95% of people used to access the internet in those days. Real-time gaming was not fun with anything that used it. I grew up in a rural area in the 1990s and was no match for people that started to get cable modems as time went on.
Dial-up, has better latency, since their is no packet-switching. So it is slow, but not laggy.
What the GP comment was talking about was dial-up Internet being most people's exposure to TCP/IP gaming in the 90s. That was most assuredly laggy. Even the best dial-up Internet connections had at least 100ms of latency just from buffering in the modems.
The QuakeWorld network stack was built to handle the high latency and jitter of dial-up Internet connections. The original Quake's network was fine on a LAN or fast Internet connection (e.g. a dorm ResNet) but was sub-par on dial-up.
Re: How Quake.exe got its TCP/IP stack
#64Random drive-by nitpick: > From the beginning of the development, id had requested from djgpp engineers that their DPMI client would be able to run on djgpp's DPMI server but also Windows 95 DPMI server. I'm pretty sure that "DJGPP engineers" is just one guy, DJ Delorie. DJGPP was always open source so I bet he got some contributors, but if the rest of this sentence is true that "id has requested from djgpp engineers…
Would love to see some interviews etc with DJ if he's up for it
Re: How Quake.exe got its TCP/IP stack
#65Re: How Quake.exe got its TCP/IP stack
#66Random drive-by nitpick: > From the beginning of the development, id had requested from djgpp engineers that their DPMI client would be able to run on djgpp's DPMI server but also Windows 95 DPMI server. I'm pretty sure that "DJGPP engineers" is just one guy, DJ Delorie. DJGPP was always open source so I bet he got some contributors, but if the rest of this sentence is true that "id has requested from djgpp engineers…
Amen to that! I think I remember there was some communication between ID and Charles Sandmann about CWSDPMI, so even though it's worded a bit strange for an open source project there's probably some thruth in it? Also a bit strange how the author is surprised about Quake running in a 'VM', apparently they don't really know about VM86 mode in x86 processors...
However, the difference between a DOS VM under Windows 9x and a Windows command prompt and a w32 program started from DOS is all very esoteric and complicated (even Raymond Chen has been confused about implementation details at times).
Re: How Quake.exe got its TCP/IP stack
#67Is this the sign that Fabian is beginning his look and research at Quake (ie, in slow preparation for another Game Engine Black Book)?
Re: How Quake.exe got its TCP/IP stack
#68Earlier quoted context omitted.
Glad you mentioned DOOM! Sometimes people forget that DOOM supported multiplayer as early as December 1993, via a serial line and February 1994 for IPX networking. 4 player games on a LAN in 1994! On release, TCP/IP wasn't supported at all, but as the Internet took off, that was solved as well. I remember testing an early-ish version of the 3rd party iDOOM TCP setup driver from my dorm room (10 base T connection) whe…
What was even more amazing is you could daisy chain serial ports on computers to get multiplayer Doom running. One or more of those links could even be a phone modem. Downside is that your framerate was capped to the person with the slowest computer, and there was always that guy with the 486sx25 who got invited to play.
Re: How Quake.exe got its TCP/IP stack
#69Earlier quoted context omitted.
Would love to see some interviews etc with DJ if he's up for it
Same. I only have experience from M.U.G.E.N fighting engine with respect to DJGPP.
You can still play the little game I made in under 10K for the Allegro SizeHack competition in 2000: https://web.archive.org/web/20250118231553/https://www.oocit...
Back then I was also writing a bunch of articles on game development: https://www.flipcode.com/archives/Theory_Practice-Issue_00_I...
Anyone on HN was active around that time? :) Fun time to be hacking!
Re: How Quake.exe got its TCP/IP stack
#70” It is impressive to see Quake run at full speed knowing that Windows 95 runs DOS executable in a virtual machine. My guess is that, in full screen, memory writes and reads to the VGA are given direct access to the hardware to preserve performances” Virtual x86 mode had little to do with what we nowadays think of when someone says ”virtual machine”
Virtual 8086 remapped all opcodes and memory accesses to let a program pretend to be on a single, real-mode 8086 when in reality it was one of many programs running in protected mode on a newer chip
AMD-V and whatever the Intel counterpart is do the almost exactly the same thing: re-map all ia32 and amd64 instructions and memory accesses to let a program pretend to be doing ring 0 stuff on an x86 box, when in reality it is one of many programs running with fewer privileges on a newer chip
There are a few more wrinkles in the latter case -- nested page tables, TLB, etc -- but it is the same idea from the viewpoint of the guest.