Live data from Hacker News

Quake Shareware, a CD-ROM just a little too full

fabiensanglard.net

211–220 of 230 posts

Re: Quake Shareware, a CD-ROM just a little too full

#211
post #161

Earlier quoted context omitted.

When Metal Gear Solid 4 released on Ps3, they used uncompressed audio. I think part of it was just to show off how much storage Blu Ray had. The game Titanfall on PC has the audio in it twice, compressed and decompressed. The decompressed was for machines with dual core or less so that there was enough overhead to keep the game running.

The video game Uru shipped with the sounds as ogg files. Post installation they were decompressed to wav files, I'm guessing so that they can squeeze some more performance out of the game

> Post installation they were decompressed to wav files, I'm guessing so that they can squeeze some more performance out of the game

Maybe, but there could be other reasons.

In a former life I briefly worked at a game developer, and the PC port of a game we shipped did the same thing. The reason I got was that the assets were just barely too big for the game to ship on one CD-ROM and going to a second disc was going to cost too much. The solution was to encode all the sound assets into .ogg (because it was free and unencumbered) to put on the disc and then convert them all to .wav post-install because the in-house engine couldn't play .ogg files and there was no time to add support before publishing.

Re: Quake Shareware, a CD-ROM just a little too full

#212
post #157
post #154

Earlier quoted context omitted.

Oh, but that's why you went to the computer lab of your uni - those machines were on a 10mbit LAN and had a decent connection to the internet! Although you still wouldn't download a CD, simply because... you wouldn't have been able to take it home with you! Hard drives were in many cases smaller than a single CD. Anything more than a few 10s of MBs would have been considered excessive.

Connecting to office LANs and going on the internet was a magical feeling back then. The speed coming from a 56k dialup was jarring. We'd have network games of Quake (rocket jumps included) and watch Real Player versions of grainy South Park early episodes at er, lunch. Good times.

More than the raw speed was the fact that the error checking, buffering, and compression on dialup added anywhere from 150-400ms to your ping RTT. You could disable a lot of it, but results could be mixed depending on the quality of your lines.

Re: Quake Shareware, a CD-ROM just a little too full

#214
post #178

Surprised that it's not mentioned that the CD was also an audio CD with the Quake soundtrack..! https://en.wikipedia.org/wiki/Quake_(soundtrack) "Originally pressed on the same disc as the game, Quake was otherwise commercially unavailable until its release on vinyl in September 2020" Soundtrack: https://www.youtube.com/watch?v=zbLttdCOgCM

It was actually reasonably common around the mid 90's for game CDs to have their music as audio tracks on the CD. I guess there was a point when CD-ROM was the target format anyway but game content hadn't necessarily grown to fill it yet. Having the CD drive play the audio directly (it could be directly connected to the sound card) with no decompression or software processing required probably saved some CPU cycles a…

Did the early proprietary CD-ROM interface cards that shipped in "multimedia upgrade kits" and on sound cards even support DMA?

I know both DMA and PIO-only SCSI HBAs existed at the time, but I'm not sure about the proprietary interfaces that were more common for consumer CD-ROM drives.

Re: Quake Shareware, a CD-ROM just a little too full

#215

Earlier quoted context omitted.

If I ask you to pass on a message from me to someone else, and the message is encrypted using a symmetric key known to me, and to the recipient, but not to you, there's no security-by-obscurity in place. If I ask you to pass on a message to someone, and the message is encrypted using a symmetric key known only to me, and I expect the recipient to be able to decrypt it because he knows that the key is written on the b…

But all parties are able to bruteforce the key, it's still just math, still obscured. The only difference is how complicated the math is, and how long the attack takes. Changing from a simpler substitution algorithm to a "real" crypto cipher IMO is still just as symmetrical, and still technically obscurity, only more complicated this time.

> But all parties are able to bruteforce the key

This isn't true, and you should be well aware of that.

Re: Quake Shareware, a CD-ROM just a little too full

#216

How would the challenge/serial have worked if implemented correctly? Since the challenge rotate every 5 minutes, there must be some way for a user to enter against an old challenge, right? Else they call, get a code and nothing. But even with that out of the way, the decryption key must be the same across all discs, since there is only 1 master disc. So the challenge/serial must combine to create a decryption key, wh…

IIUC the rotating challenge actually didn't have anything to do with the key, it was a red herring. The actual decryption key was just a function of the fixed serial number or something like that.

Re: Quake Shareware, a CD-ROM just a little too full

#217
post #216

How would the challenge/serial have worked if implemented correctly? Since the challenge rotate every 5 minutes, there must be some way for a user to enter against an old challenge, right? Else they call, get a code and nothing. But even with that out of the way, the decryption key must be the same across all discs, since there is only 1 master disc. So the challenge/serial must combine to create a decryption key, wh…

IIUC the rotating challenge actually didn't have anything to do with the key, it was a red herring. The actual decryption key was just a function of the fixed serial number or something like that.

I'm talking about, if they had actual encryption, how would it have supposed to even work?

Re: Quake Shareware, a CD-ROM just a little too full

#218
post #91
post #81

Earlier quoted context omitted.

Meh, in the early days of DVDs I recall a game that came with uncompressed 48kHz audio. Compress it to mp3 (which the game naively accepted if you had the correct Windows filters) and it fits in a CD.

Uncompressed audio tracks may have been necessary to get acceptable performance. e.g. GTA 1 came with some PCM tracks on the CD. If you didn't like them, you could pop in a different CD and get different music on the radio in-game. Playing mp3's was, in the early to mid-90's, actually pretty intensive. There were still a decent number of 386's around that could barely run a mp3 player in a Linux console-only setup. Y…

Well, I looked it up and the game shipped in the early 2000s, and listed Pentium 266 as minimum requirements (Pentium 500 recommended).

I don't recall the 386 era and the DVD era overlapping that much…

Re: Quake Shareware, a CD-ROM just a little too full

#219
post #178

Earlier quoted context omitted.

It was actually reasonably common around the mid 90's for game CDs to have their music as audio tracks on the CD. I guess there was a point when CD-ROM was the target format anyway but game content hadn't necessarily grown to fill it yet. Having the CD drive play the audio directly (it could be directly connected to the sound card) with no decompression or software processing required probably saved some CPU cycles a…

Did the early proprietary CD-ROM interface cards that shipped in "multimedia upgrade kits" and on sound cards even support DMA? I know both DMA and PIO-only SCSI HBAs existed at the time, but I'm not sure about the proprietary interfaces that were more common for consumer CD-ROM drives.

Very firsts Philips/DEC LMSI controller did DMA https://github.com/AkBKukU/CM153-Repro https://github.com/AkBKukU/CM153-Repro/blob/main/EDA/ISA-Car...

Panasonic (MKE) was pure pooled PIO and didnt even support Interrupts. Sony and Mitsumi do have DREQ/DACK pins so most likely did ISA 8bit DMA. ISA DMA is pretty terrible and slow (4.7MHz clock, steals CPU cycles for the duration of the byte transfer), barely enough for 2x CDROM. IDE PIO is better on 286 and up than ISA DMA thanks to nice dedicated REP INSW. Taking into account ISA limits transferring one CD sector should take no less than ~700-1000us.

While ISA SCSI and VLB controllers could do DMA, they rarely did with ISA 16MB memory limit and VLB compatibility worries. The one VLB IDE controller dlaiming to do DMA, Promise PDC20630, does MWDMA2 to the drive but with CPU manually pooling IO pins on the other side, total waste https://www.vogons.org/viewtopic.php?p=1323789

TLDR: Talk of enabling DMA for your HDD and maybe even CDROM became common only somewhere around 1996, a good year into Intel shipping busmastering IDE controller in PIIX on Pentium boards (430FX and up). You had to put devices on separate IDE channels and hope everything is compatible and works.

Re: Quake Shareware, a CD-ROM just a little too full

#220

How would the challenge/serial have worked if implemented correctly? Since the challenge rotate every 5 minutes, there must be some way for a user to enter against an old challenge, right? Else they call, get a code and nothing. But even with that out of the way, the decryption key must be the same across all discs, since there is only 1 master disc. So the challenge/serial must combine to create a decryption key, wh…

> since there is only 1 master disc

you destroy every retail disk a little

https://news.ycombinator.com/item?id=49343326

Post reply on HN