The dumbest part about linux is watching coreutils and systemd stuff take less than 512Mb of RAM only for any modern browser or electron app to take a fat 4gb dump all over it.
Compiz with all the fancy effects enabled only adds like 200-300Mb tops.
But rendering a crappy JS infested webpage requires 10 isolated processes because no one learned anything from 40+ years of computer security.
Epic is already teasing Unreal 6 as if Unreal 5 isn’t the reason why every “AAA” release has had horrible lack of optimization.
Didn’t Roller Coaster Tycoon have a file size of something like 55MB?
It’s an almost perfect game, that gets to live pretty much forever with the advent of OpenRTC. That game is a true wonder of human ingenuity, and I’m not even being hyperbolic.
It totally belongs right there next to DOOM and Legend of Zelda haha.
Yeah it’s 99% written in assembly which if you know assembly is fucking hard.
You don’t even have primitives like division in assembly. You have to write that code yourself to tell the processor how to divide two numbers and handle a remainder… Modern CPUs are different now in that they have that as a built in feature but back then they didn’t.
Like the famous joke about assembly: “to bake an apple pie in assembly, first you must create the entire universe”
Yes assembly is complicated, but more like error prone and tedious than fucking hard, which still makes the game a huge achievement, especially considering its complexity. I haven’t had RCT crash on me even once for which I admire the author! What you miss compared to a programming language are named variables and especially structures, named functions and loops can be simulated (as can everything a higher language like C can do) and are just not as comfortable. And you have to have a way more intimated knowledge of the inenr workings of the processors you want to run your software on, than with higher languages.
Div has been part of the Intel assembler since the 8086 from 1978, long before RCT was written. The first processor supporting it is from 1952! (The IBM 701), fdiv (Floating point divide) was widely available on Home-PCs since the 8087 from 1980. By the time RCT was written there where already comfort functions integrated into processor instructions sets like setting single bytes with BTS or scaled index addressing. Still writing software with a programming language was way easier and faster. But the result would never be as optimized as a good assembly program.
I remember systems having only kilobytes. I wrote a whole list of games on a machine which had 16KB for main and graphics RAM together.
Would a secondary console made by a major player with severe limitations sell well? I kinda think so. Let’s say N64 cartridge size maximum as an example for any given game. 512 Megabit? 64MB.
As a fan of digital “fantasy consoles”, I think this is a super cool idea.
It would be great to have a real/semi-popular hardware console that was deliberately locked to some kind of old-school limitations.
Instead of chasing the latest/hottest tech we could just focus on really making great games with reasonable budgets.
At least before we could upgrade our systems to accommodate bloat. Now we’re getting it from the other end with RAM being made too expensive by AI. That same AI will generate even less optimal code requiring even more memory.
The fact that F-Zero only had floating cars was because they couldn’t afford the memory to render tires. Totally made the game better.
💯
It made it feel appropriately futuristic.
It also enabled the weight-shift/lean mechanic, which wouldn’t have made sense with wheels.
For fun:
SNES: 192Kb (total RAM+VRAM)
PSX: 3.5Mb (total RAM+VRAM)
Xbox 360: 512Mb (single bank for CPU and GPU)
PS5: 16Gb (single bank, Pro adds 2GB for CPU)
Xbox Series X: 16Gb (single bank, semi-permanent 6/10 split)
My Desktop: 72Gb (total RAM+VRAM)
Limitations breed innovation
That was before electron
Unless it’s PS vs N64.
Psx and N64 era brought a bunch of the best videogames ever. Not sure what you’re talking about.
Maybe they are referring to one of the long nerdy videos explaining how some game is unoptimized crap
The game size limitation of N64 vs PS disc caused game developers to abandon Nintendo and go to PlayStation.
Ps1 had more breathing room in some ways, but you’re acting like it didn’t also have sharp limitations to work around. Every console of that generation still had severe restrictions.
And yet, we had Resident Evil 2 on N64 with all the videos and no compromises. The only reason why they abandoned Nintendo is because it was the FMV era and those were difficult to properly compress.
On the other hand, N64 was home to huge games that did marvels with the hardware. Because of the cart limitations, we had masterpieces such as Perfect Dark, Zelda Oot, Jet Force Gemini… Cart limits made devs focus on things that weren’t FMVs.
There are definite compromises but it is a good port.
Some N64 games are better than their PS1 counterparts
Nightmare Creatures and Shadow Man come to mind
Nightmare creatures on the PS1 is a blocky polygon mess and Shadow Man on the same system is almost unplayable
I mean there’s an argument for that on just the N64 not comparing to PS1.
Take a look back at the absolute black magic Capcom had to do getting Resident Evil 2 on the N64
Limitation: Nintendo wants to back out of the SNES disk drive console deal.
Innovation: Sony makes their own console and calls it the Playstation.
Limitation: Not enough memory for some games on the N64.
Innovation: Expandable memory for the console, packaged with games that need it.
The n64 also brought us vibrating controllers before Sony’s DualShock controllers, and standardized joysticks on the controller (even though it only used 1).
Result: Square abandoned Nintendo for PlayStation to get the larger disc.
Imagine how much more game you could fit on a hard drive if character models didn’t have billions of triangles
Model vertex count has a negligible influence on size. Model data is small (provided the textures aren’t baked in), and modern GPUs can render ten thousand separately animated instances of the same base model simultaneously when using the right techniques.
It’s the insanely high-resolution textures and audio that bloat install size. That and including the same files many times to reduce HDD seek time, but that’s finally becoming less common as SSDs take over (or at least it was until the current component shortage).
I miss when HD texture packs were separate downloads. If I’m only running a game in 1080p, downloading a hundred gigabytes of 8k textures I’ll never use is a colossal waste of bandwidth and disk space.
We need those super hi-res textures so that we can put a bunch of blurry effects on top.
Motion blur and depth-of-field were bad enough. Now we have AI upscaling and frame gen that absolutely destroy fine details, but are almost required to get a high framerate in some games due to a lack of optimization (I’m looking at you, half of all released Unreal Engine 5 titles).
I remember being appalled when Titanfall 1 had a separate 80 GB download just for the audio because they couldn’t be bothered to compress it. Audio compression has been largely a solved problem for 20 years now, even if the result is somewhat lossy.
If I’m only running a game in 1080p, downloading a hundred gigabytes of 8k textures I’ll never use is a colossal waste of bandwidth and disk space.
I kinda wonder if there’s a visible difference between native 1080p textures and those that are downscaled from a higher resolution. I imagine there isn’t, but I am curious about it.
My favorite instance of unnecessary file bloat was due to a bug. The Microsoft Store and Epic Games versions of Fallout 3 would download the full game once for every single translation the game supported, with every translation in its own subfolder. A nine gig game ended up taking over forty gigs of hard drive space.
And then there’s shit like ARK: Survival Evolved that requires the better part of a terabyte with all the DLC. Infuriatingly they did eventually reduce the install size, but only for the terrible UE5 port that nobody asked for.
And on the opposite end of things, Helldivers 2 reduced their install size by over a hundred gigs (down to around twenty total) by simply removing duplicate data from the game files, if anyone was wondering how expensive that HDD seek time optimization I mentioned was in disk space.
Massively depends on where the texture is used. If it’s for a main character that gets closeups, body and especially detailed textures can be massive and can add up fast even when compressed. Little low contrast details can definitely work fine and go unnoticed next to super hifi textures while being small themselves, though so many just make everything hifi. Bleh.
I miss when games went for lowfi art instead of the modern deluge of AAA pseudo-cinema 100G+ games or friendslop with the art direction of a two day game jam… (obviously there are outliers, but the industry trends are disappointing lately)
FLAC is pretty good compression.
i want SMALLER👏 GAMES👏 made by FEWER👏 DEVELOPERS👏 who are PAID👏 MORE👏 to DO👏 LESS👏 and i’m NOT👏 KIDDING👏
This is why I don’t play any AAAs in the post-UE5 era.
Pre-2019 is a goldmine for small size, high fidelity, and compelling story.
I hate UE5 almost as much as I hate Citizens United. Like, I would use my genie wish responsibly, but there would be deliberation.
Lowkey:
“I wish temporal graphics technologies in video games were never invented and will never be invented.”
That’s like 90% of UE5 fixed.
Xbone/ps4 was the last boon for PC gaming. 8 cores meant companies finally took multi threading seriously. But by the time the ps5 and series came out developers stopped bothering truly optimizing games. And the added resources of those machines meant they could get even lazier.
Everyone just brute forcing unreal to do what they wanted only made things worse. Everyone just wants to take the shortcut to release the game as quickly and shittily as possible.
Sony and MS are ending their console brands just in time!
The reason why I think Pokemon peaked at Gen 5 and went downhill from there. I imagine if Square Enix’s HD-2D engine had caught on earlier, TPCI would’ve gone that route instead of diving headfirst into 3D concrete without a helmet.
Yeah, one of the reasons why I like low-fidelity games is because the devs can just think of an idea, slap together a few pixels into a texture and ship it. You just get much more varied and interesting content that way, because they can easily experiment with ideas and also remove stuff, if it doesn’t work out, without it being much of a time loss.
Could fix this by switching to a theoretical physics engine.
What if they were made of mostly bubbles?
Necessity is the mother of something something
Good performance optimization is part of the art.
Well yes, but have you heard about delivering features? Crunch, agile, moving fast and breaking things?
Basically Mythos just opened the closet door and all the junk, dirty laundry and empty wrappers fell out.
My commodore 64 only had 64K, not 64M.
https://en.wikipedia.org/wiki/Commodore_64That was such a nice machine. Even had a slot for game cartridges.
I developed my first games on one of those. I still have the audio cassette tapes, since they pre-dated even floppy disks.
Back when more people and companies would craft their own game engines with their own code. Almost everyone has been moving toward Unity and Unreal these days though.
