Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

191–200 of 238 posts

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

#191

Post by MrDOS »

squarefoot wrote: post #121
smallstepforman wrote: post #78

I’ve created a 4k UHD video editor for Haiku OS ( https://github.com/smallstepforman/Medo ), it’s a C++17 native app, with over 30 OpenGL GLSL effect plugins and addons, multi threaded Actor model, over 10 user languages, and the entire package file fits on a 1.44Mb floppy disk with space to spare. If I was really concerned about space, I could probably replace all .png resources with WebP and save another 200kb. How…

Nice, this may be worth a Show HN. I'm not a Haiku user although I try it from time to time should it become interesting for my uses. Also I agree on the value of being exposed to the old way of doing things. I started coding on the Amiga, and the way its OS worked (no memory management) forced me to grow sane habits when for example dealing with memory allocation: if I didn't free a buffer before my program exited,…

> Nice, this may be worth a Show HN.

smallstepforman has submitted it before: https://news.ycombinator.com/item?id=25513557. Unfortunately, it didn't garner much attention.

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

#192

Post by patentatt »

pkphilip wrote: post #171
Dave_Rosenthal wrote: post #81

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

I may be naïve/out of the loop here, but it’s fun to imagine what would be possible with the same gusto and creativity applied to today’s hardware. I imagine that a significant amount of modern hardware, even in games, is eaten up by several layers of abstraction that make it easier for developers to crank out games faster. What would a 90’s developer do with a 16-core CPU and an RTX3080?

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

#193

Post by mjul »

boomlinde wrote: post #189
Dave_Rosenthal wrote: post #109

Earlier quoted context omitted.

You could just measure the isolated inner loop with accurate timers and figure out down to the clock how many cycles it was taking. You also basically knew how many cycles each instruction took (add, multiply, bit shift, memory reference, etc.) so you just added up the clock counts. (Though things got a bit harder to predict starting with Pentium as it had separate pipelines called U and V that could sometimes overla…

On the C64 I will change the border color when my frame routine starts and change it back once my routine finishes. This will tell me how much of a fraction of the total frame time I use, in quite literal terms. I wonder if similar tricks were used for VGA. I think you could change color index 0 to the same effect.

Speaking about the C64 the exact instruction timing was also key to the two rather clever hacks to put sprites outside the nominally drawable 320x200 pixel screen area.

First in the top and bottom border. This was done by waiting for the GPU to start drawing the bottom line of text on the screen and then switching to a mode with one less line of text. The sprite hardware would then not get the signal to stop drawing after the last line since that presumably already happened with fewer lines to display. This would cause it to keep drawing sprites below the bottom border. The in the vertical blanking before the top line was draw you would switch it back from 24 to 25 lines of text.

The side-border is a variation on this where you time your code to wait for the 39th character of a scan line then switch from 40-character wide to 38-wide. Again the sprite engine would not get the signal to stop drawing and continue drawing in the side border outside the 320x200 pixel nominal capabilities of the hardware.

For side border it was necessary to do this for every scan line (and every 8th line would have different timing, probably related to fetching the next line of text), so timing was critical to the exact CPU cycle.

These machines were not much by modern standards but for the hacker mind they were an amazing playground where you had just your assembly code and the hardware to exploit without the layers and layers of abstractions of modern gear.

Edit: spelling

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

#194

Post by kbuck »

patentatt wrote: post #192
pkphilip wrote: post #171

Earlier quoted context omitted.

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

I may be naïve/out of the loop here, but it’s fun to imagine what would be possible with the same gusto and creativity applied to today’s hardware. I imagine that a significant amount of modern hardware, even in games, is eaten up by several layers of abstraction that make it easier for developers to crank out games faster. What would a 90’s developer do with a 16-core CPU and an RTX3080?

You can check out some demoscene demos [0], which usually do this (albeit to save executable size instead of just to run fast). These days you don't even have to run them yourself; most have YouTube recordings.

[0]: https://www.pouet.net/prodlist.php?platform%5B%5D=Windows&pa...

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

#195

Post by candybar »

TacticalCoder wrote: post #66

Hard disagree with many comments here. For ennemies AI, ok: we made progress. But for human-vs-human gameplays, we basically had everything in the nineties. Warcraft II over Kali (to simulate a LAN over the Internet for Warcraft II didn't have battle.net) was basically the gameplay of Warcraft III reforged. Half-Life and then it's counterstrike mod were basically the FPS of today. Diablo II (development for Windows 1…

Warcraft II is a bad example here - it's completely unplayable if you're used to any kind of modern RTS. Terrible unit AI (not computer AI), selection limits, no rally points or queuing. It also has just 2 factions. Starcraft, which only came out just over 2 years later, blows it away from gameplay perspective. Warcraft 3 came out in 2002 (6 and half years after Warcraft 2) and represents an even larger improvement in gameplay and a huge increase in complexity (all of the improvements from Starcraft carried over, 3D terrain, perspective and unit rendering, 4 factions). Arguably that's when things started to slow down in terms of improvements - the gap between Starcraft 2 (2010) and Warcraft 3 (2002) is much smaller than the gap between Warcraft 3 and Starcraft 1 (1998), which in turn is much smaller than the gap between Starcraft 1 and Warcraft 2 (1995).

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

#196

Post by kqr »

uncomputation wrote: post #68

So many great responses in this thread, but I’ll just throw it out there that the original Pokémon games for GameBoy were in hand-written assembly specific to the GameBoy. I would imagine “back then” the programmers had limited memory and thus more obvious constraints. It’s probably possible to recreate this level of efficiency nowadays but both the number of platforms and the expectations of gaming have exploded sin…

This is also the reason they are so many weird bugs in the original Pokemon games; they reused storage and parts of code for different things, but if you exercise that in a specific order it starts doing weird things instead.

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

#197

Post by lupire »

kqr wrote: post #188
Dave_Rosenthal wrote: post #101

Earlier quoted context omitted.

Ha. Yeah, there was not a lot of memory. The toolchain we built at the the time automatically packed all individual game texture maps into a single 256x256 texture (IIRC). If the artists made too many textures, everything started to look bad because everything got downsampled too much. Any yeah, the design of the game content was absolutely affected by things like polygon count concerns: "Say, wouldn't it be cool to…

> If the artists made too many textures, everything started to look bad because everything got downsampled too much. That's really clever. On the surface of it, it's "just" about dynamically adapting fidelity to fit in the available memory. But really, it's a deeper organisational solution: it pushes the breadth vs fidelity of assets trade-off back to the designers, who are the ones that should decide along that curv…

why would you assume the designer would choose the optimal graphics config, instead of the artists who are the visual experts?

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

#198

Post by lostgame »

fxtentacle wrote: post #157

Quite simply: No frameworks. Some games nowadays are built using Electron, which means they include a full web browser which will then run the game logic in JavaScript. That alone can cause +1000% CPU usage. Unity (e.g. RimWorld) wastes quite a lot of CPU cycles on things that you'll probably never use or need, but since it's a one-size-fits-all solution, they need to include everything. For Unreal Engine, advanced s…

That demo is eerily beautiful. Honestly the first time I’ve seen photorealistic detail in a game engine.

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

#199

Post by SavantIdiot »

kqr wrote: post #175
Jensson wrote: post #163

Earlier quoted context omitted.

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?

Yes.

However, this is part of the reason why you always try to avoid performing if/then in critical loops. Obviously the index counter cannot be hoisted, but if you are doing 1000 iterations, 2-bit Yeh prediction (which was common at the time) can be amortized.

Later CPU architectures speculatively executed and then re-executed instructions that were incorrect due to branching, and VLIW allowed you to "shut off" instructions in a loop rather than have to predict.

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

#200

Post by SavantIdiot »

lapsis_beeftech wrote: post #174
SavantIdiot wrote: post #115

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 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.

Yep! Thanks! I was also thinking of his "Graphics Programming Black Book". Black Art ... hah! My bad memory. That dude abused the hell out of int 13! Kinda surprised he's with Oculus under Facebook. I wish his brain wasn't owned by Zuck. Maybe he's in that phase that musicians hit, when they get old and gray and start performing their classics at Vegas for a million bucks a night to audiences of boomers.
Post reply on HN