Ask HN: How were video games from the 90s so efficient? • Hacker News Board

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

#181

Post by lostgame » Sat, Nov 06, 2021, 12:36 PM UTC

Dave_Rosenthal wrote: post #101

cmroanirgo wrote: post #96

Earlier quoted context omitted.

Agree with everything you said. We used x87 though and paid extreme attention to fpu stalls to ensure nothing wasted clocks. As developers, we were also forced to give the graphics guys a really hard time: "no that texture is too big! 128x128" & "you need to do it again with less polygons". We used various level of detail in textures and models to minimise calcs and rendering issues. Eg. A tank with only 12 vertices…

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…

A fantastic early example of memory limitations in games are that the clouds and bushes in Mario 1 are the same sprite with a different palette.

Those were certainly different times. :) It was so much cooler to see what developers and artists did within those limitations than what we are doing today. The entire game dev community was like a demoscene in a way.

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

#182

Post by jart » Sat, Nov 06, 2021, 12:55 PM UTC

smcameron wrote: post #169

jart wrote: post #82

Computers aren't that much faster if we consider there's only an order of a magnitude difference between 300mhz and 3ghz. In order to benefit from the full speed of our modern ~3ghz processors your problem needs to fit into about 32kb of memory, due to physics and locality. So size of RAM today is kind of a red herring. I think if you compare the sheer size and scale of what a Factorio game looks like once it turns i…

> Computers aren't that much faster. I don't know about that. I grew up in the 80's and was always trying to make games, first in BASIC, then in Turbo Pascal, and it was always a struggle to get the required speed. You always had to resort to ridiculous assembly language hacks, etc. At some point in the early 90s, I kind of quit trying to make games. Then in 2007, I was thinking about how much faster computers were "…

It's not a question of difficulty. It's not a question of skill. The issue is belief. Once you stop believing that assembly is just some weird hack is the moment it gets easy. In my experience when it comes to simple functions, plain code normally processes data at 400mbps and if you use the weird hacks it goes 40gbps which is two orders of a magnitude. With algorithms it gets even better when you can make things exponentially faster. Even something as constrained as old i8086 is too easy when we believe that nothing is beyond our ingenuity. People have built things like fighter jets using those chips and sent humans to the moon with less.

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

#183

Post by DeathArrow » Sat, Nov 06, 2021, 1:02 PM UTC

cryo wrote: post #159

DeathArrow wrote: post #128

Earlier quoted context omitted.

I dabbled with graphics using mode 13h and later with VGA. It was orders of magnitude simpler than using Vulkan or DX12. CPUs were simpler DOS and Windows 95 were very simple compared to Windows 10. That means that writing optimized C or even assembler routines was pretty easy. If we go 10 years back in time, programming Z80 or MOS Technology 6510 or Motorola 68k was even simpler.

Yes the instruction sets were simpler, but the developers at the time had invented a lot of clever solutions to solve hard problems. I think the most innovative timespan was between 1950–1997'ish, and hope we get back to get the most out of hardware again as common sense.

Developers at that time were great. But is harder to be great today when complexity is 1000x.

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

#184

Post by nickdothutton » Sat, Nov 06, 2021, 1:07 PM UTC

I got started in the 8-bit era. You had no option but to get down to the metal. Even then you often had to rely on “tricks” or quirks of the hardware to cut down the work required. 3D graphics and point and click GUIs in 1985: https://micro-editor.github.io/

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

#185

Post by ArtWomb » Sat, Nov 06, 2021, 1:09 PM UTC

This is just a terrific question and discussion all around. Game dev is a hot topic on HN. And the world needs a dedicated Game Forum to discourse on topics of the moment ;)

I don't have any answer. But I am interested in the transition that took place mid-90s from 2D to 3D. The latter SNES era pseudo-2.5D sprite animations are masterpieces of digital art. And then: discontinuity. Low-poly first gen 3D game design arrives. And no one knows where to put the camera.

One thing I have noticed is that dev cycles are roughly the same. It takes roughly the same time to create a game for N64 or PS5: 18 months. But one is 50 megs the other 50 gigs. They took the time and care back then to get things right. Although many releases were still unplayable disasters

"What were the worst video game excesses of the 90s?" It's another question to learn from!

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

#186

Post by Olreich » Sat, Nov 06, 2021, 1:30 PM UTC

Yes, it’s possible. Obviously things won’t get back to the VGA levels of size because we have higher resolution everything. But you can get similar results by thinking in terms of a memory budget, CPU budget, etc. and then measuring to make sure you stay within that. Once you’ve determined your constraints, then you’ll start optimizing when you bump up against them.

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

#187

Post by Pamar » Sat, Nov 06, 2021, 1:38 PM UTC

kqr wrote: post #149

don-code wrote: post #15

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…

I have zero information about (due also to little interest for) computer games, so this is just a wild speculation: maybe the visuals in terms of "levels/textures/objects/mesh/characters/voice/audio" dominate the planning, now?

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

#188

Post by kqr » Sat, Nov 06, 2021, 1:39 PM UTC

Dave_Rosenthal wrote: post #101

cmroanirgo wrote: post #96

Earlier quoted context omitted.

Agree with everything you said. We used x87 though and paid extreme attention to fpu stalls to ensure nothing wasted clocks. As developers, we were also forced to give the graphics guys a really hard time: "no that texture is too big! 128x128" & "you need to do it again with less polygons". We used various level of detail in textures and models to minimise calcs and rendering issues. Eg. A tank with only 12 vertices…

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 curve anyway. It provides a cheap way for them to visually evaluate various points on that trade-off curve. Very clever.

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

#189

Post by boomlinde » Sat, Nov 06, 2021, 1:40 PM UTC

Dave_Rosenthal wrote: post #109

andrewjf wrote: post #106

Earlier quoted context omitted.

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

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.

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

#190

Post by mjul » Sat, Nov 06, 2021, 1:46 PM UTC

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?

You just need your code to finish before the next frame. Then you wait and start the next cycle when you receive the interrupt from the start of the next frame from your graphics hardware.

Of course once you start writing for heterogeneous hardware like PCs with very different performance between models, you may use adaptive approaches to use all the available resources rather than just providing the most basic experience for everyone.