Live data from Hacker News

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

news.ycombinator.com

171–180 of 238 posts

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

#171

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…

The 199os were a time when we tried all sorts of tricks to get the last bit of performance out of the hardware. One book which stands out is the one Michael Abrash wrote:

Michael Abrash's "Graphics Programming Black Book" https://github.com/jagregory/abrash-black-book

https://www.drdobbs.com/parallel/graphics-programming-black-...

As CPU power, the number of cores, RAM sizes, HDD sizes, graphics card capabilities have increased, the developers are no longer as careful to squeeze out the performance.

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

#174

Earlier quoted context omitted.

Out of curiosity, How did you know how many clock cycles your rendering code took?

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 might be thinking of "Zen of Assembly Language" or "Zen of Code Optimization" by the brilliant Michael Abrash. I own the latter and in addition to plenty of low-level code optimization advice for the microprocessors available at the time it also includes timer code for DOS that lets you measure code performance with high precision.

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

#175
post #151

Earlier quoted context omitted.

Were games at this point of low enough complexity that the combinatorial explosion of branches could be contained and reasoned about by humans? Or did you have software doing this?

There is no such thing as combinatorial explosion here, just take the longest branch every time.

But this means if you have a situation like

    if (a) { ... }
    ...
    if (b) { ... }
Where the branches are long, and b = !a, you significantly overestimate the amount of code. I guess that was considered good enough, then?

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

#176

yes, it is possible to be that efficient now, but there is little incentive to do so. it is far easier, and faster, to use a library that is bad than to write what you need efficiently. "CPU is cheap." "RAM is cheap." two of the many cancerous sayings that developers use to excuse their poor efforts. we don't do this now because we simply do not care enough as an industry. we want the software written immediately and…

> we don't do this now because we simply do not care enough as an industry. we want the software written immediately and for as little money as possible.

It's not about "as little money as possible" it's about priorities. Above, someone mentioned spending 2 months individually packing structures for a game to reduce memory to fit. Given the choice between having a developer spend 2 months on that or a developer spend 2 months localising the game, or adding accessibility options the choice today is features.

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

#177

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…

A game like Donkey Kong uses a static tile mapped background and some small dynamic objects that move around, and the hardware combines them.

These machines don’t even have enough memory to store one frame buffer, you can’t program like a modern game where everything is customizable and you can just do whatever you want as long as it’s fast enough.

In a game like Donkey Kong you do what the hardware allows you to do (and of course the hardware is designed to allow you to do what you want to do).

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

#178

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 det…

64-bit support was added in Dwarf Fortress 0.43.05, released in July 2016.

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

#179
Personally I think the reason they were faster than today is abstractions. Today developing a video game for a browser doesn’t require you to know anything about the details of graphics or pixels or GPU. Such abstractions - such as the V8 engine or a video game library - allows ease of development, hence easier to hire people that can manage and understand it.

Unfortunately the abstraction comes at a cost - in CPU cycles.

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

#180

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…

I remember reading the comp.graphics.algorithms news group back when Descent was just out. People were going a little bit crazy trying to figure out how the hell that thing worked. I found this page that talks about some of the things done to do texture mapping: https://www.lysator.liu.se/%7Ezap/speedy.html

Descent blew my mind, as well. IIRC it predated Quake and was the first ’true’ 3DoF FPS?

The source code has since been released on GitHub, if you’re ever interested in seeing it!

Post reply on HN