Ok, that got me. I still remember the days of ZX and that funny noise… But I do have a question for one part of the meme: can someone explain to me why on Earth the updates now weigh these tens of gigs? I can accept that hires textures and other assets can take that space, but these are most likely not the bits that are being updated most of the time. Why don’t devs just take the code they actually update and send that our way?
I’ve got 2gig fiber, not 56k dialup. It’s Steam’s bandwidth now. They paid Valve their 30%. Why bother with insane compression that just makes it feel slow for us?
That is also a factor I do not understand. Bandwidth costs the storefront money, would Steam and others not want to decrease this load? And well done you with that fiber, you dog! I also have a fiber line but see no reason to upgrade from my tariff (150mib, i think?) that covers everything just to shave that hour of download time a year.
I am perfectly fine with paying developers, as I buy only the games i do like after some testing ) Going the repack route is unpredictable - no updates, may contain whatever viruses repacker is interested in adding (and given the particular one is likely Russian, I do have my reservations at this crazy time…), etc.
I mean, I understand when they chuck everything into a single file, but they used to know how to make their updaters unpack and replace only the stuff that needed updating, instead of just throwing the whole fucking file at you, redundancy be damned.
For instance, stuff in Quake 3 engine is kept in .pk3 files. You don’t need to download the full, newest .pk3, you send a command to remove/replace files X, Y and Z within it and call it a day.
Yeah but then people go completely ballistic when games require you to install their own launches I don’t think Steam would necessarily be able to handle the myriad of different formats that would be needed to make that work. So either you have custom lunches or you don’t have particularly efficient patches.
That’s because games don’t need “their own launcher” to apply updates like that. Ask anyone that’s been playing on PC, patches were these self extracting files or “mini installers” that you just needed to point to the installed game’s folder. Even vanilla World of Warcraft let people download the patches for offline install, it even included a text with all the changes applied.
People don’t want the fiddling on of that. I just want to be able to install the patch and then it be there.
That’s why lunches are a thing there’s no other reason to have them.
You might enjoy the technical solution but 99% of people don’t care. I never understand why people seem to think that the 1% of the most experienced people are the standard when they are anything but. Most gamers build their own PCs, they don’t want to have to understand about file systems and formats and compiling. They just wanted to work and then they want to play their game.
For modern games, from what I’ve seen, they’ve taken a more modular approach to how assets are saved. So you’ll have large data files which are essentially full of compressed textures or something. Depending on how many textures you’re using and how many versions of each textures is available (for different detail levels), it can be a lot of assets, even if all the assets in this file, are all wall textures, as an example.
So the problem becomes that the updaters/installers are not complex enough to update a single texture file in a single compressed texture dataset file. So the solution is to instead, replace the entire dataset with one that contains the new information. So while you’re adding an item or changing how something looks, you’re basically sending not only the item, but also all similar items (all in the same set) again, even though 90% didn’t change. The files can easily reach into the 10s of gigabytes in size due to how many assets are needed. Adding a map? Dataset file for all maps needs to be sent. Adding a weapon or changing the look/feel/animation of a weapon? Here’s the entire weapon dataset again.
Though not nearly as horrible, the same can be said for the libraries and executable binaries of the game logic. This variable was added, well, here’s that entire binary file with the change (not just the change). Binaries tend to be a lot smaller than the assets so it’s less problematic.
The entirety of the game content is likely stored in a handful (maybe a few dozen at most) dataset files, so if any one of them change for any reason, end users now need to download 5-10% of the installed size of the game, to get the update.
Is there a better way? Probably. But it may be too complex to accomplish. Basically write a small patching program to unpack the dataset, replace/insert the new assets, then repack it. It would reduce the download size, but increase the amount of work the end user system needs to do for the update, which may or may not be viable depending on the system you’ve made the game for. PC games should support it, but what happens if you’re coding across PC, Xbox, PlayStation, and Nintendo switch? Do those consoles allow your game the read/write access they need to the storage to do the unpacking and repacking? Do they have the space for that?
It becomes a risk, and doing it the way they are now, if you have enough room to download the update, then no more space is needed, since the update manager will simply copy the updated dataset entirely, over the old one.
It’s a game of choices and variables, risks and rewards. Developers definitely don’t want to get into the business of custom updates per platform based on capabilities, so you have to find a solution that works for everyone who might be running the game. The current solution wastes bandwidth, but has the merit of being cross compatible, and consistent. The process is the same for every platform.
The console argument does actually make a lot of sense to me, thank you for the detailed response. It would still (seemingly) be possible to structure the project in a way that would allow replacing only what you actually need to replace, but that requires more investment in the architecture and likely cause more errors due to added complexity. Still, i cannot forgive the BG 3 coders for making me redownload these 120gb or so! )
The issue is the compression. There’s hundreds of individual assets, the process to compress or more accurately, uncompress the assets for use takes processor resources. Usually it only really needs to be done a few times when the game starts, when it loads the assets required. Basically when you get to a loading screen, the game is unpacking the relevant assets from those dataset files. Every time the game opens one of those datasets, it takes time to create the connection to the dataset file on the host system, then unpack the index of the dataset, and finally go and retrieve the assets needed.
Two things about this process: first, securing access to the file and getting the index is a fairly slow process. Allocating anything takes significant time (relative to the other steps in the process) and accomplishes nothing except preparing to load the relevant assets. It’s basically just wasted time. The second thing is that compressed files are most efficient in making the total size smaller when there’s more data in the file.
Very basically, the most simple compression, zip (aka “compressed folders” in Windows) basically looks through the files for repeating sections of data, it then replaces all that repeated content with a reference to the original data. The reference is much smaller than the data it replaces. This can also be referred to as de-duplication. In this way if you had a set of files that all contained mostly the same data, say text files with most of the same repeating messages, the resulting compression would be very high (smaller size) and this method is used for things like log files since there are many repeating dates, times, and messages with a few unique variances from line to line. This is an extremely basic concept of one style of compression that’s very common, and certainly not the only way, and also not necessarily the method being used, or the only method being used.
If there’s less content per compressed dataset file, there’s going to be fewer opportunities for the compression to optimize the content to be smaller, so large similar datasets are preferable over smaller ones containing more diverse data.
This, combined with the relatively long open times per file means that programmers will want as few datasets as possible to keep the system from needing to open many files to retrieve the required data during load times, and to boost the efficiency of those compressed files to optimal levels.
If, for example, many smaller files were used, then yes, updates would be smaller. However, loading times could end up being doubled or tripled from their current timing. Given that you would, in theory, be leading data many times over (every time you load into a game or a map or something), compared to how frequently you perform updates, the right choice is to have updates take longer with more data required for download, so when you get into the game, your intra-session loads may be much faster.
With the integration of solid state storage in most modern systems, loading times have also been dramatically reduced due to the sheer speed at which files can be locked, opened, and data streamed out of them into working memory, but it’s still a trade-off that needs to be taken into account. This is especially true when considering releases on PC, since PC’s can have wildly different hardware and not everyone is using SSDs, or similar (fast) flash storage; perhaps on older systems or if the end user simply prefers the less expensive space available from spinning platter hard disks.
All of this must be counter balanced to provide the best possible experience for the end user and I assure you that all aspects of this process are heavily scrutinized by the people who designed the game. Often, these decisions are made early on so that the rest of the loading system can be designed around these concepts consistently, and it doesn’t need to be reworked part way through the lifecycle of the game. It’s very likely that even as systems and standards change, the loading system in the game will not, so if the game was designed with optimizations for hard disks (not SSDs) in mind, then that will not change until at least the next major release in that games franchise.
What isn’t really excusable is when the next game from a franchise has a large overhaul, and the loading system (with all of its obsolete optimizations) is used for more modern titles; which is something I’m certain happens with most AAA studios. They reuse a lot of the existing systems and code to reduce how much work is required to go from concept to release, and hopefully shorten the duration of time (and the amount of effort required) to get to launch. Such systems should be under scrutiny at all times whenever possible, to further streamline the process and optimize it for the majority of players. If that means outlier customers trying to play the latest game on their WD green spinning disk have a worse time because they haven’t purchased an SSD, when more than 90% + have at least a SATA SSD, all of whom get the benefits from the newer load system while obsolete users are detrimented because of their slow platter drives, then so be it.
But I’m starting to cross over into my opinions on it a bit more than I intended to. So I’ll stop there. I hope that helps at least make sense of what’s happening and why such decisions are made. As always if anyone reads this and knows more than I do, please speak up and correct me. I’m just some guy on the internet, and I’m not perfect. I don’t make games, I’m not a developer. I am a systems administrator, so I see these issues constantly; I know how the subsystems work and I have a deep understanding of the underlying technology, but I haven’t done any serious coding work for a long long time. I may be wrong or inaccurate on a few points and I welcome any corrections that anyone may have that they can share.
Is your point that developers today aren’t as good/benevolent/whatever as devs back in the day? I’m saying (sarcastically, I suppose) that the same type of developers exist today. What does survivor’s bias have to do with it? Is my point moot because GMOD exists?
Your point is moot because there is an unending hose of indie games being created and knowing that 2 gems exist doesn’t mean the rest of the cottage industry measures up to the things being achieved earlier, and nor does said indie scene have a similar rate of success as the old industry back then.
it’s survivor bias because having one or two good games in a tidal wave of indie bug riddled, knockoff messes isn’t exactly the same thing as the innovations from back in the day. Some asshole’s Amnesia knockoff or twin stick shooter being good is hardly surprinsing when 5000 of them come out daily.
Tbf, games were easier to create using in-game functions and logic that was created for another game. Modding a whole rework was easier than making the entire game from scratch. Undeniably lethal company is similar in look and feel but it has better game play than some mods.
That and it easily running on Linux, either naively or though Proton, is why I haven't touched any AAA in like... at least 5 years? Maybe closer to 10.
groomerwojak.jpg: "I groomed a teen fan of mine, and when she came forward I made her to write an apology, also I spent my Patreon money on a sexdoll, and my code is spaghetti."
"We barely managed to make a functioning game with premade assets, and our popularity was so dependent on Pokémon not performing well, our fanbase is a toxic cesspool as a result, who can't express the love to the game without actively dissing Nintendo."
"I'm a bigoted con artist who rebrands every time they get busted for his crappy horror game."
"Optimization? We are already using low-poly assets!"
"The assets in our pixelart games are very unaligned, and we use high-resolution fonts because no one makes bitmap fonts anymore."
Why are you twisting things around? It’s Nintendo fans that won’t shut up about plagiarism to the point that the The Pokémon Company told everyone that they know, stop sending emails about it.
If you donate money to develop a vaccine against something, much of that money will go towards the salaries of researchers to pay for their work. Some of them may buy sex dolls, dildos, satisfyers or chastity belts with some of that money, because they have rightfully earned it, and the money you paid was still used to develop that vaccine.
I mean nobody said all indie devs were great, i just think that if you want to find examples of good game development today you’re largely going to find the stars are indie, not triple A
But only for today. The concept of triple A didn’t really exist back then, and at least one of the “then” game devs was totally indie for the game he made
Do you have any recent examples? Am genuinely curious, given that it’s something that’s been a problem in the game’s industry for a long time, particularly at places like Activision.
Totally, that’s what I’m trying to lampoon, sorry if the sarcasm didn’t come through on that aspect. I maintain my premise, there’s a tremendous amount of harassment devs put up with for the ‘privilege’ of working in the games industry, a key aspect that makes me support unions and worker organization.
I see stuff like this and I don’t blame developers/coders for all the shit that’s happening. If you objectively look at gameplay and such, most games are actually pretty decent on their own. The graphics are usually really nice and the story is adequate, if not quite good, the controls are sensible and responsive…
A lot of the major complaints about modern games isn’t necessarily what the devs are making, it’s more about what the garbage company demands is done as part of the whole thing. Online only single player is entirely about control, keeping you from pirating the game (or at least trying to) plus supplying on you and serving you ads and such… Bad releases are because stuff gets pushed out the door before it’s ready because the company needs more numbers for their profit reports, so things that haven’t been given enough time and need more work get pushed onto paying customers. Day one patches are normal because between the time they seed the game to distributors like valve and Microsoft and stuff, and the time the game unlocks for launch day, stuff is still being actively worked on and fixed.
The large game studios have turned the whole thing into a meat grinder to just pump money out of their customers as much as possible and as often as possible, and they’ve basically ruined a lot of the simple expectations for game releases, like having a game that works and that performs adequately and doesn’t crash or need huge extras (like updates) to work on day 1…
Developers themselves aren’t the problem. Studios are the problem and they keep consolidating into a horrible mass of consumer hostile policies.
I hate this conflation of “Developer” with every other role in modern game development.
If you think the new Porsche looks shit, do you blame the Mecanical engineer who designed the brake mechanism?
If your new manga body pillow gives you a rash, do you blame the graphic designer of the manga?
There is not a single thing listed in the meme above that is actually the fault of the actual developers working on the game. Don’t even need to talk about the first picture.
game size is studio management related. They want to stuff as much (repetitive, boring) content into the game as possible. Plus a multiplayer mode no one asked for.
Optimizations don’t happen because the CEO decides to take the sales money of the game this quarter, and not next, and ships an unfinished product.
Always online is ALWAYS a management decision.
It’s a shit joke, it’s wrong because it blames the wrong people, and its also just dumb.
I’ve written software professionally for two decades and I’m still in awe of the people who used to wring every last drop out of 512kb of memory, a floppy drive and 16 colours on the Amiga 500.
I played some pretty good games on the 48k spectrum back in the day. My first computer was a zx81 with 1k ram, it was a bit challenging to do anything interesting with it - but people still wrote games for the thing.
While true that it’s impressive, now games have to be made to work on variable screen sizes with different input controllers, key mappings, configurations, more operating systems, with more features than ever. It’s an absolute explosion of complexity.
Even making a 2D game for today’s hardware is more difficult than making a 2D game for Gameboy.
Honest question, is that true? It’s my understanding that developing a 2D game today would be a simpler task than for a system from the 90s due to so many improvements in development software.
Oh, man, imagine thinking that minimum requirements weren't a thing before.
I once deleted the operating system just to fit a single game into my hard drive, booted from floppy while I was playing it and reversed the process when I was finished. Sometimes games were aiming at a specific speed of computer and if you had a computer that didn't run at that specific number of megahertz the game just ran like a slideshow or in fast forward. I didn't realize some of my favourite games were running under the speed cap for years sometimes. We just didn't have a concept of things running at the same refresh rate as your screen in the early 3D era until APIs fully standardized. Sometimes you upgraded your GPU and the hardware accelerated version of your old software rendered game actually ran slower.
Also, game developers "then" made arcade games that literally charged you money for dying, then charged you more money for effectively cheating at the game and actively asked you to literally pay to win. We used to think that was normal.
Also, also, we used to OBSESS about games being bigger. The size the game took up was heavily advertised and promoted, especially on consoles. Bigger was better. We were only kinda glad that CDs could do 500 Mb, so we could keep getting bigger on a single disk, but by the time FMV games got popular triple A games were back to coming into books with disks instead of pages. This was still seen as a selling point.
Also, also, also, the assembly code of a whole bunch of old games is sheer spaghetti. Half of the mechanics in NES games are just bugs. There are a couple of great Youtube channels that just break these down and tweak them. In fairness, they didn't have development tools as much as a notepad and a pencil, but still.
Yeah I remember the specific clock speed thing! I had a game that I loved on a friend’s computer and didn’t get to play it much. Some sort of space sim / combat game. Years later I had my own much more powerful machine and was hyped to check it out. Installed via dosbox or whatever, loaded it up, and it ran at fucking 10x speed! It took seconds to walk around a city and the combat was completely unplayable. So sad but also pretty funny. No idea why they attached the FPS directly to the hardware. If you want an easier game, just get a worse computer apparently.
Hah. In fairness, sound cards weren't "minimum requirements". It's just that depending on the hardware you had the game would just have a completely different soundtrack, 75% of which sounded completely broken. If you were lucky the "minimum spec" was silence. If you were unlucky it was making your beeper sound like somebody had tripped a car alarm.
People these days are out there emulating Roland MT-32s on Raspberry Pis. I didn't have a sound card until the Pentium era. Every DOS game in my memory sounds like a Furby got a bad case of hiccups.
I leave this as an example, but please understand this is the absolute best case scenario. Michael Land and the rest of the Lucas guys were wizards and actually cared to tune things for multiple options, including really impressive beeper music.
I have heard the difference of sound cards before in a video explaining it, but it is still just a wild too me to hear it, and nearly a bit difficult to imagine it actually being that way. Like I KNOW it was how sound on computers was at that time, but it is still hard to imagine my games sounding so completely differently depending on what pc I play it on.
I have the opposite problem, where I have to remind myself that a lot of people making these memes just don't have a frame of reference for any of this. I'm used to having been there for the vast majority of home computing, it's so hard for me to parse having been born with computers just mostly working the way they do now.
I can somewhat comprehens the difference in appearance and sometimes game play, but at the same time not really. I have seen the same game be different on pc vs console and a third version on handheld, and while I know this where all computers, I still very much think of them in the way of game consoles you could also do computer things on, even though I know that they were computers that you could play games on.
I blame it a bit on terminology, every time I hear about old computers, they are always referred to much more similar to how we refer to games consoles today then we do with computers. It is an Amiga 500, Amiga 1000 or an Atari 7800 or Atari ST. That is much more similar in my head to like Nintendo Wii, Nintendo Switch, PlayStation 2 or PlayStation 4.
I have never really heard computers be referred to in that manner now a days, they probably are to some extent in some circles, but I have completely managed to miss them, and I do have some interested in computers. Like I can tell you I have owned a Dell, a HP and a Lenovo amongst some, but I would really have to do some digging to maybe be able to tell what version of them it was.
I know my current one start with G and the following looks some what like lam, but I only know that because it kinda looked like Glam so I named it that and because I have needed to Google that exact model, to look up some stuff.
I can however understand how you feel having grown up with with the computers and now talking to and interacting with a lot of people that never experience the older ones. Realising that people have a completely different fram of reference to something is a very weird thing to experience and somewhat difficult to navigate.
I am however happy that you and other people do have different experiences as then I could learn about how sound cards made games sound completely different or how changing GPU or computers manufacturer could completely change the game.
Man I loved the hell out of my SB16. I still play a lot of old DOS games in emulation and work pretty hard to get them to sound like I remember vs the higher fidelity versions.
It was the first time I played it and found the combat frustratingly difficult because of the increased speed. Especially in dungeons where I had to bait enemies one by one just to not get overwhelmed. One hand was always holding a healing spell as well.
No idea why they attached the FPS directly to the hardware.
It’s the most trivial and straight forward thing to do. The game is a simple loop of:
get user input (can be nothing)
calculate new game state based on old state and input
draw new game state.
The speed of the game is now 100% dependant on the speed of computation. NOT attaching fps to hardware is the hard thing, as you need to detach the game state loop and the drawing loop and then synchronize them. Doing that yourself is extremely complicated. Today developers don’t even need to think about that because the whole drawing loop is abstracted away by things like directX/Vulcan and the game engine. But without those tools, fps tied to CPU speed is basically the default.
And in fairness a lot of microcomputers at the time were closed specs. Even on PC for a while you were theoretically aiming at a 4Mhz XT or, at worst, also wanted to account for a 8MHz AT. By the time IBM clones had become... you know, just PCs, a lot of devs either didn't get the memo or chose to ignore it for the reasons you list.
Most of the time "lazy devs" are just "overworked and underfunded devs", but the point is, that didn't start this century.
Also games have gotten way more complicated since the gameboy colour era. I’ve coded a basic 2D physics engine from scratch (literally just circles with soft collisions) and its not just enough to set up the vector math correctly. You can literally make a true to real life physics model (as far as the math of infinitely rigid perfect spheres on a perfectly flat plane goes anyway) and have all sorts of problems crop up because computers aren’t the universe and order of computation is a bitch.
Even the first Dark Souls had game ticks tied to the FPS because consoles had been standardized to 30 FPS for decades.
On the PC port, it was locked to 30 FPS, but a super popular mod unlocked the FPS, and at 60 FPS DoT effects ticked twice as fast, and at even higher FPS could kill you before you had time to react.
At my buddy's house, he had a game called something like 'wings of glory' that was meant for an older clock speed. We were messing with the turbo button and it quickly became unplayable when not in the slower mode.
If you try it again, emulators like dosbox let you slow the game down to be playable. I don’t remember the exact setting but I’ve had to do it on things like Freddy Farkas iirc.
Right. That was common, too. Games were tiny and very expensive, so broken balance was often used to pad out length. And yeah, it got crazy once Americans started popularizing rental and publishers got desperate to make the games less economical to beat without purchasing them.
I did finish Ecco 1 legit, though. Once.
I've tried the last couple of stages a few times. I still don't understand how tween me managed that. Even on a CRT with original hardware and zero lag that's a stupid thing to try to do.
Bigger was better, since a larger game meant they packed in more content. Now the bloat is out of control since all game content is delivered over the Internet.
Bloat is out of control because games are HUGE and you can often trade size for performance if you have enough memory to do so.
Also, memory used to be extremely expensive, especially catridge ROMs. Outside of the Switch this is less of a concern now, that's true, but the tradeoff is you get to have pin-sharp high resolution assets and tons of performance optimizations instead of... you know, just chopping enough frames of animation to fit your sprites in 16 megabits then charge a hundred bucks for the extra-sized cart. You can buy a terabyte of extremely fast storage now for the money it used to cost to buy a single game shipped on a cartridge.
The hard drive I had to wipe from the OS, as I mentioned above was a whole 20 gig. 386-ish era. It seemed so huge when I got it (and so expensive) and by the time that PC was done it was... well, a "wipe to OS to fit stuff in" drive.
But that's not necessarily the point, the more relevant thing is how big things are relative to storage and how cheap it is to upgrade storage. It's true that storage sizes and prices plateaued for a while, so a bunch of people are still running on 1-2 TB while the games got into the hundreds of GB. But still, storage had gotten so proportionately cheap before then, and very fast storage is so overkill now. A 1TB Gen 3 NVMe is 75 bucks, and most games will run fine on it, Sony propaganda notwithstanding.
You can fit loads of x360-ps3 era games in the same space CoD warzone takes. The irony is that, for PC players with lower specs, that’s a lot of wasted storage, since they’ll never use/load the higher res textures.
You can buy a terabyte of extremely fast storage now
That line of thinking is what leads to extreme, unnecessary bloat. “Just buy more storage, brah”
You can absolutely do that. You can also fit 16 frames of the Xbox 360 game into a single frame of the Xbox Series X game.
Sometimes people forget how much bigger a 4K target is compared to a 720p image, so I added a bit of a visual aid below. Those two screenshots are to scale, displayed at the native resolutions of their respective platforms. Just keep in mind that the big one is from a 1440p 21:9 monitor, so on a 4K TV the picture would have two of those stacked on top of each other.
It's good that this is smaller, because If you squint you can also notice the Xbox 360 game is extremely blurry and looks like it's in black and white. That's because it is. The 360 had 512megs of ram, to share between the CPU and the GPU. The Xbox Series X has 16 gigs, so 32 times more, and it's running a cool 300 times faster. 360 games were compressing textures within an inch of their lives to fit them into that tiny slab of memory, stripping color data among other things.
Computers are not magic. If you want to draw 15 million pixels of a wall and not have it look like soup you need data for each of those pixels. If you want that data to fit in less space you have to either spend resources compressing and decompressing it or you need more storage to put it in. Or you can draw it procedurally, I guess, but then you're back to the performance problem.
On the other thing, it's not "just buy more storage, brah", it's that storage has to ramp linearly with memory. If you are trying to build huge worlds running at hundreds of frames and streaming data at gigabytes per second out of a SSD you're going to need to put those assets somewhere. The problem isn't (just) that games are big, it's that the ability to move those big assets has grown a bit faster than the ability to make cheaper, faster storage for the same price.
Games aren't big because developers are lazy, they're big because physics and engineering are hard and not every piece of technology improves at the same rate. But hey, on the plus side, storage HAS gotten cheaper. By the end of its life the PS3 was shipping 500 GB. The PS5 and Xbox Series ship 32 times more ram but only 1.5 to 2x more storage because storage is where everybody is skimping to contain costs. That's not commensurate with the increase of visual fidelity or asset size, but at least you can add more for relatively little money, especially on PC.
EDIT: Sorry, this client didn't like the picture going in. Link to an example below from a random image hosting site. Follow it at your peril, I make no claims about its safety. https://ibb.co/Ss7RfzW
The smallest standard for CDs was 63 minutes and 550-ish MB. For most of the life of the medium you'd mostly get the 74 min, 650MB one. The stretch 700 and up standards were fairly late-day. I tend to default to 500 in my head because it was a decent way to figure out how many discs you'd need to store a few gigs of data back in the day, though, not because I spent more time with the 63 min CDs.
The smallest standard for CDs was 63 minutes and 550-ish MB
I think I came along around 2 years after burners were commercially available, so I never saw that. And the 700 MB discs came along very shortly later. So I never had a concept of a 550 MB CD (btw you said 500 MB). This is the first I’ve heard of it.
It did exist, I promise. But again, I just default to 500 because it was such common shorthand to think about it in terms of needing two discs to store a gig. And to this day I still have 650 CDs laying around, even when 700MB ones were available they were both around at once.
I think some of the mismatch may also be that you're thinking about it in terms of storage only (i.e. CD-Rs) because of your age and I'm probably a bit older and was mostly talking about them as read-only media. It was years between the first CDs in the late 80s and writers being widespread at all, assuming whatever game or application that came in a single CD was going to take 500 meg-ish to duplicate or install was, again, pretty useful.
In any case, this is obsolete trivia. The point is we went from games being tens of megs to hundreds of megs overnight, and we were all extremely pleased about it.
You are half right. I am misremembering 63min being the original standard of the red book audio CD, that was 650 already, although apparently 63 min CDs were used for audio mastering at some point? Info about that is sparse. As a side note, man, modern search engines suuuck.
Anyway, 63min/550MB was the low capacity standard of the CD-R instead.
And also this, from a eBay auction selling a box and labelling them "incredibly rare", which apparently is accurate. I came just shy of digging through my pile of old CDs to see if I have any left. I may still do that next time I have them on hand.
I mean, the demo for Rollercoaster Tycoon (Mr. “Hand coded in assembly” there) bricked our Windows 98 machine when i installed it as a kid. My dad was pissed: we had to reformat the harddrive, reinstall windows, all that.
Oh, that's a whole other subject. "Old games were so polished and fully finished". Meanwhile, half of the planet was either playing games squished down, in slow motion or both. And most of them didn't even know.
It's not as simple as that, either. May people think all games ran 15% slower. Many games did have some retiming somewhere, but it was definitely not great and people didn't complain because with no internet, they often didn't realize what was going on.
I remember reading an early-2000s book on game dev. It did mention that some game (I want to say one of the Unreal games, but I can't recall for sure) had to code their level loading in assembler because it was taking upwards of 10 minutes in C++.
Yeah, I definitely think the OP has super rose-colored glasses on. The free shareware was pretty awesome, though. I had one called "80 mega-hits" or something like that with a ton of games (many of which my poor old PC couldn't run).
I do think that optimization has slacked off more as hardware prices generally trended down. Disk space I don't so much mind, but memory and CPU are still expensive.
This is one of those things where I'm not sure what people mean when they say it.
There are bugs that affect performance, and yeah, we're generally more likely to see bugs fro several reasons now. But there's also games just being heavy. We're not in a cycle where the top of the line hardware just maxes out many games, because... well, we're doing real time path-tracing, we have monitors that go up to 400 Hz and resolutions up to 4K. The times of "set it to Ultra and forget about it" with a 1080 are gone and not coming back for a really long time. Plus everything has to scale wider now, because on the other end we have actual handhelds now, which is nuts.
So yeah, I'm not sure which one people are complaining about these days. I'll say that if you can play a game in a handheld PC and then crank it up to look like an offline rendered path traced movie that's way more thought to scalability than older games ever had, but maybe that's a slightly different conversation.
The “free shareware” thing is kind of back. I’ve been noticing more and more games producing demos; check out Steam Next fest, for example.
I also remember playing a ton of games from a CD. I had a Mac at the time, but it was “dos compatible”, which meant it had a 486 in addition to the Mac processor at the time, so you could switch over into dos, though you could only allocate half the ram to it.
We ended up installing Windows 95 to play a lot of the games, which ran great on the available 4 MB of RAM.
I once deleted the operating system just to fit a single game into my hard drive, booted from floppy while I was playing it and reversed the process when I was finished.
I remember doing this Battle of Britain and TIE Fighter! Man, memories.
startrek.website
Aktywne