Live data from Hacker News

Let's compile Quake like it's 1997

fabiensanglard.net

41–50 of 82 posts

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

#41
> DO NOT get it from github or transfer the files via FTP.

I bet the author doesn't know about FTP's ASCII mode, and especially doesn't know that it is the default.

ASCII mode was a nifty feature, but it never should have been the default. Especially when you consider that most text files are small and easy to re-download if you forget, while binary files are often quite large and the damage done by the line ending conversion is close to impossible to repair. Also, if you forget to convert a text file you can trivially do it on the host afterward.

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

#44

"VC++6 is remarkably powerful for 1996. It has features such as "Go to definition", breakpoints, stacktrace, and variable inspections (but no Intellisense auto-completion yet). I never used it but it must have felt like a dream at the time." And here we are, in a generation of people writing blogs that never used VS6. I am now officially old. I was still using VS6 as late as 2009 btw...also it's from 1998. If you mad…

Didn't Smalltalk environments have those features ages ago already?

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

#45
post #36

Earlier quoted context omitted.

Many of those features were already available in MS-DOS and Windows 3.x IDEs from Borland for Turbo Pascal and C++. Which is why when I got into UNIX development felt like going into the stone age of development tools, thankfully XEmacs was already there. Which by the way, it was born for Energize C++, in 1993! https://www.youtube.com/watch?v=pQQTScuApWk Also here is what NeXTSTEP development environment looked like,…

>Which is why, I usually assert I cannot understand the nostalgia of CLI and TUI Elitism

sometimes you wanna do debugging on a device that has no screen or ethernet port too

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

#46
> In June of 1996, having shipped their title but concerned with NeXT stagnation, id Software switched their development stack.

id also decided no more DOS games around that time (well, maybe a year later)

> For Id Software to develop a game, a dll will be most efficient. We have more cpu power, and we can debug it more easily. We are directing significant effort towards making Quake 2 a better GAME, as well as just a better mutliplayer virtual world. Quake 1 was pretty messed up from a game standpoint, and we don't plan on doing that again.

> Speaking of portability, to remove the guesswork that goes on, here are my current opinions on the various platforms:

> Win32 > Win32 rules the world. You are sticking your head in the sand if you think otherwise. The upside is that windows really doesn't suck nowdays. Win 95 / NT 4.0 are pretty decent systems for what they are targeted at. I currently develop mostly on NT, and Quake 2 will almost certainly be delivered on win32 first. Our games should run as well as possible in NT, we won't require any '95 only features.

> DOS > We are not going to do another dos game. No amount of flaming hate mail is going to change my mind on this (PLEASE don't!). The advantages of good TCP/IP support, dynamic linking, powerfull virtual memory, device drivers, etc, are just too much to overcome. Yes, all of those can be provided under dos in various ways, but it just isn't worth it.

> Linux > I consider linux the second most important platform after win32 for id. From a biz standpoint it would be ludicrous to place it even on par with mac or os/2, but for our types of games that are designed to be hacked, linux has a big plus: the highest hacker to user ratio of any os. I don't personally develop on linux, because I do my unixy things with NEXTSTEP, but I have a lot of technical respect for it.

> NeXTStep > My favorite environment. NT and linux both have advantages in some areas, but if they were on equal footing I would choose NEXTSTEP hands down. It has all the power of unix (there are lots of things I miss in NT), the best UI (IMHO, of cource), and it just makes sense on so many more levels than windows. Yes, you can make windows do anything you want to if you have enough time to beat on it, but you can come out of it feeling like you just walked through a sewer.

> In the real world, things aren't on equal footing, and I do most of my work on NT now. I hold out hope that it may not stay that way. If apple Does The Right Thing with rhapsody, I will be behind them as much as I can. NEXTSTEP needs a couple things to support games properly (video mode changing and low level sound access). If apple/next will provide them, I will personally port our current win32 products over.

> If I can convince apple to do a good hardware accelerated OpenGL in rhapsody, I would be very likely to give my win NT machine the cold shoulder and do future development on rhapsody. (I really don't need Quickdraw3D evangelists preaching to me right now, thank you)

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

#48
post #28

Earlier quoted context omitted.

In the storm of Doom-Quake mania of the mid 90s there was Chasm: The Rift by a small Ukrainian company Action Forms. And if memory serves me right, it was created in Turbo Pascal. It was late in development and came out in 1997 after Quake, so it didn't get much traction. But the engine, though pretty limited, could produce 3D enemies with interesting effects not found even in Quake. So Turbo Pascal (with a whole bun…

> Chasm: The Rift I might be misremembering but I thought it was more of a Doom-style engine with 3d models instead of sprites for the entities, rather than a full 3d engine like Quake.

It was definitely something unorthodox - I remember being confused about how it actually worked.

The first time I played, I thought "It is just like Quake". Then you start to notice that the levels are pretty limited - it is all narrow corridors with rare small chambers and open spaces, no steep elevation changes, no rooms above rooms... Kinda like Doom. But then, father's examination shows sloped surfaces, shelves and bridges - stuff the Doom engine can't do.

Maybe, for level geometry, it is closer to portal rendering engines like Build. Still looks pretty claustrophobic even compared to Doom and Duke Nukem 3D. I feel the Chasm level designers could've got more variety from that technology, but again, maybe that was some fundamental limitation. Or maybe it is just like FPS were designed in the mid 90s.

Monsters, items and weapons are fully 3D, though. With dynamic lighting!

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

#49

"VC++6 is remarkably powerful for 1996. It has features such as "Go to definition", breakpoints, stacktrace, and variable inspections (but no Intellisense auto-completion yet). I never used it but it must have felt like a dream at the time." And here we are, in a generation of people writing blogs that never used VS6. I am now officially old. I was still using VS6 as late as 2009 btw...also it's from 1998. If you mad…

100% agree. Not only was VC++6 a stand-out product overall, but it was easily the better IDE out of the crop of options at the time. Sadly, the product line got worse before VSCode came out. Things are much better now.

The load times of VC6 versus VSCode... yeah. I would bet you can load a VC6 project faster in OP's environment faster than VSCode could load the same project in a current environment.

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

#50

"VC++6 is remarkably powerful for 1996. It has features such as "Go to definition", breakpoints, stacktrace, and variable inspections (but no Intellisense auto-completion yet). I never used it but it must have felt like a dream at the time." And here we are, in a generation of people writing blogs that never used VS6. I am now officially old. I was still using VS6 as late as 2009 btw...also it's from 1998. If you mad…

I could've sworn VC++6 had Intellisense. I'm not going to dig too far to confirm but Wikipedia seems to agree with me (https://en.wikipedia.org/wiki/Code_completion#Visual_Studio) - it's not a great reference but definitely implies that it was there:

> the Visual Basic versions of IntelliSense were always more robust and complete than the 5.0 and 6.0 (97 and 98 in the Visual Studio naming sequence) versions of Visual C++

Post reply on HN