Live data from Hacker News

Ask HN: How were video games from the 90s so efficient?

news.ycombinator.com

141–150 of 238 posts

Re: Ask HN: How were video games from the 90s so efficient?

#141

I recommend watching this: https://youtu.be/izxXGuVL21o Naughty Dog Co-founder Andy Gavin discusses various hacks that were used on the Playstation to get Crash Bandicoot to run smoothly. The fuller version is also worth watching.

The art of working with constraints does not seem to be lost; just look at late cycle console games.

A PS4 was/is effectively unchanged hardware between Nov 2013 and today, yet the late lifecycle games look great. Upon release of the hardware devs had plenty of performance to play with, then 5 years in they have honed their craft and are able to use all the tricks at their disposal to squeeze as much graphical and performance life out of a limited resource budget.

Re: Ask HN: How were video games from the 90s so efficient?

#142

You are not calibrated for the actual hardware we had at the time. Nobody was running Descent on a 300MHz computer. It ran perfectly well on the 486DX2-66, or any Pentium. 300MHz would have been an impossible luxury, something you could just barely get in very high end workstations near the end of 1996. The first 300MHz Pentium didn't come out until 1999.

nitpicking your nitpicking :)

1997 https://en.wikipedia.org/wiki/List_of_Intel_Pentium_II_micro...

with everyone being able to afford fast 450MHz in 1998 https://en.wikipedia.org/wiki/List_of_Intel_Celeron_micropro...

Re: Ask HN: How were video games from the 90s so efficient?

#143
post #137

Earlier quoted context omitted.

You look at the assembly code, grab an Intel Programmer Reference manual (they were about 1000 pages), look up each instruction opcode and that would tell you the clock cycles. For memory operations it is much more difficult due to caching. However, for many hot regions of code, the data is already in the L1s so manual counting is sufficient. (At the time there was a book called The Black Art of ... Assembly? I can't…

> You look at the assembly code, grab an Intel Programmer Reference manual (they were about 1000 pages), look up each instruction opcode and that would tell you the clock cycles. Wouldn't this "just" tell you how many "cycles of code" there are, and not how many cycles actually run? Branches etc. will of course cause some cycles to be double-counted and others to be skipped, in the dynamic view.

Then you just calculate them all.

If Branch A is taken ... total X clock-cycles.

If Branch B is taken ... total X clock-cycles.

If Branch C is taken ... total X clock-cycles.

And so on. And then make sure that the "longest" branch fits into the clock-cycle budget.

Re: Ask HN: How were video games from the 90s so efficient?

#144
post #16

Broadly speaking, modern developers don’t have to deal with resource limitations (neither computing nor financial) so they instead devote that extra energy on completely unnecessary orchestration systems and build toolchains to feel like they’re doing something complex and challenging.

> Broadly speaking, modern developers don’t have to deal with resource limitations (neither computing nor financial) so they instead devote that extra energy on completely unnecessary orchestration systems and build toolchains to feel like they’re doing something complex and challenging.

That is massively far from truth. Rendering graphics to the level modern games require is driving even current powerful hardware to its limits and it's far from "not having to deal with resource limitations".

Your post seems to be horribly condescending and not realising just how much work goes into squeezeing performance from modern GPUs and consoles.

Re: Ask HN: How were video games from the 90s so efficient?

#145

I built games in the 90s. Graphics was obviously the hardest part. We thought about things in terms of how many instructions per pixel per frame we could afford to spend. Before the 90s it was hard to even update all pixels on a 320x200x8bit (i.e. mode 13h) display at 30 fps. So you had to do stuff like only redraw the part of the screen that moved. The led to games like donkey kong where there was a static world and…

Good write up. I’d also add to that, that modern techniques are written to use the modern hardware.

It’s easy to forget that each upgrade to graphics is an exponential jump. Going from 8 colours to 256 colours on screen. Jumps in resolution. Jumps in sound, number of sprits the hardware can track. Etc.

When we look at graphics now and the tangible visible difference between 8k, 4K and HD and Moore’s Law no longer in effect it is easy to forget just how significant the jumps in tech was in the 80s and 90s if you hadn’t lived through it and/or developed code during it.

Re: Ask HN: How were video games from the 90s so efficient?

#146
Dwarf Fortress mostly has two bottlenecks for historical reasons: It's single-threaded and is a 32bit application, meaning it can use less than 3GB Ram. So interestingly a modern gaming PC could be worse at running Dwarf Fortress than an older one, as nowadays multithreaded performance is prioritized and anything beyond 4GB Ram doesn't help you.

And I guess at a certain world size good performance would need less detailed simulation in other parts of the game world.

Re: Ask HN: How were video games from the 90s so efficient?

#147
I'm sure this is covered elsewhere in this large thread but I also worked on a triple A game in the nineties, one of the first 3D FPS games with a huge story. Every aspect of the game's memory footprint was tuned. I spent over two months at one point just going in and reducing every structure to remove unneeded waste and to quantize variables down to the absolute minimum. Bools were held in a single bit. If a variable only needed less than 256 values it would be held in a single byte. I changed a lot of data structures to be highly optimized and crushed down to just what they needed to still work. The non technical producer couldn't understand that I spent two months and was so joyful that the game was running and _nothing_ looked different.

Re: Ask HN: How were video games from the 90s so efficient?

#148
My old boss was in the video game industry from the late 90's until 2017 or so and would talk about this a lot.

It's less about old games being optimised so much as modern non-game software being mind-blowingly wasteful.

Modern, well optimised AAA stuff like Doom 2016 or The Last of Us 2 is as much a work of genius design (if not more) as Rollercoaster Tycoon or Warcraft II. If anything, Vulkan is bringing us closer to the metal than ever before.

It's just a general shift in consumer expectation over time. There is no longer any pressure for regular apps to be performant, so they aren't.

Re: Ask HN: How were video games from the 90s so efficient?

#149

These tricks are things that you could still pull off today. The difference is, outside of competitions or the demoscene, nobody _needs_ to pull them off - it greatly decreases your time-to-market to do things in a straightforward way, rather than a novel way. That wasn't true 20+ years ago - the straightforward way often brought you up against hardware limitations.

> it greatly decreases your time-to-market to do things in a straightforward way

I mean, it's hard to disagree when you phrase it this way, but... really? In the old days (mid-'90s) studios like id released many games per year, some of which with completely new technology.

Modern studios and indie developers (!) who "do things in a straightforward way" can be happy to release even one game per year, and that's with a lot of reuse. Forget novel technology once a year!

So maybe these tricks don't really increase time to market that much, compared to other variables that are also in play?

Re: Ask HN: How were video games from the 90s so efficient?

#150
If you wanna know about it, you should watch in youtube about making crash bandicoot. They were trying to make the gameplay as efficient as possible and making sure that user experience is not affected by it. For example, you only need to load data per level, in case big data needs to be loaded once per level, they will load it from the disc.

Another big problem they have to solve is how to make the crash character fits into the system with too many "models"

Post reply on HN