Live data from Hacker News

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

news.ycombinator.com

121–130 of 238 posts

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

#121

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, that buffer would remain allocated until the next reboot. I once had to debug a small assembly program of mine that lost a longword (4 bytes) at every run; turned out I missed it when doing pointer calculations with registers, and the journey to monitor the program activity, find the problem and correcting the error has been of tremendous help years later.

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

#122
Software was simpler, so it was easier to optimize. Also, hardware was very limited and that meant you were forced to optimize if you wanted to sell anything.

The public was accustomed that the software should be nimble and run fast. If you would have given the regular Electron app to the '90s public they would have been displeased.

Hardware limits and developers being more thoughtful and less lazy are pretty much the answer.

In the 90s most software was C/C++ running on hardware. Now we have layers upon layers of abstractions. VMs, Kubernetes, Docker, jitted languages, OOP codebases written against Uncle Bob's preachings and GoF patterns. And the jitted language is best scenario. Many software is written in interpreted languages.

If anyone cares to make a trivial benchmark, it would be telling: write a simple C program and time it. Write the same in Java or .NET, but use a class for everything and introduce some abstractions like builders, factories etc. Run the program in a container in a virtalized Kubernetes cluster. Time it.

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

#123

Earlier quoted context omitted.

If I remember correctly the two main hacks were making draw lists such that only certain polygon faces were rendered based on Crash's xyz position (the theory being that it isnt possible for other faces to be seen from that location), and also that he removed functions/files from Sony's standard C libs on the PS1 SDK?

They realized that untextured polygons were way faster to draw than textured ones, so rather than texture the Crash model, they cranked up the polygon count and simply colored them. Often times, the triangles were on the same order of size as the pixels. It also avoided the playstation's lack of perspective correction on textures. It both made the character look gorgeous for the day, and made the code run faster.

Yes, I played many many hours of crash as a kid and he looked extremely vivid and bright. When I code in Three.js these days I also skip loading textures and just go for hex colors on polygons :)

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

#124

Earlier quoted context omitted.

> Java...a great tool for prototyping, but when it came to delivering a high-performance product it often fell short. I think this only been said in the context of games.

It really depends. Java isn't bad as server-side software, and there are benefits to using it's runtime. For client-side software though (particularly in 2012-2020), not many commercial PCs could play Minecraft at a decent framerate. Even now, feeding the Java version huge amounts of high-bandwidth memory is the only way to mitigate slowdown, and that still doesn't account for the micro-stuttering that you get when w…

The jetbrains IDEs are written in Java and they run very nice.

I'd wager the micro stuttering is GC?

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

#125
Optimizing software means 99% percent of the time to not pessimize it. That is not write code that is not necessary, don't make the CPU run code which isn't needed to accomplish the task.

Casey Muratori explains it well: https://youtube.com/watch?v=pgoetgxecw8

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

#126

Optimizing software means 99% percent of the time to not pessimize it. That is not write code that is not necessary, don't make the CPU run code which isn't needed to accomplish the task. Casey Muratori explains it well: https://youtube.com/watch?v=pgoetgxecw8

YT link doesn't work

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

#127
In short, "necessity is a helluva thing." It is not a technical explanation, but there is a great amount of truth in saying they were that way because they had to be to make it work.

Coming from another angle, the developers at that time considered those resources to be an amazing amount of plenty. Compared to, say, an 8086 with 128k or 256k of RAM, no HDD and maybe 512k or 1.44MB of floppy storage, those specs were huge.

If you're looking for other kinds minimal examples, I recommend glancing through the demoscene (https://en.wikipedia.org/wiki/Demoscene) stuff. To some degree, the "thing" there was amazing graphical outputs for minimal size.

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

#128

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

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

#129

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…

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…

Honestly, though the numbers are bigger and floating point arithmetic is fast on a modern GPU this still sounds a lot like how we work nowadays.

I recently spent two years on the performance team for a large indie title and a huge portion of it was asking artists to simplify meshes, improve LODs, increase the amount of culling we could do on the CPU, etc.

My own work was mainly optimising the rendering itself.

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

#130
post #89

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…

Some interesting related stuff in this talk: HandmadeCon 2016 - History of Software Texture Mapping in Games https://www.youtube.com/watch?v=xn76r0JxqNM I think they say at one point it went from 14 to 8 instructions, and then the Duke Nukem guy (Ken Silverman) got it down to around 4. Quake would do something where it only issued a divide every 8 pixels or something, and then only interpolate when inbetween and the…

For perspective correct texture mapping quake did the distance divide every 8 pixels on the FPU, and the affine texture mapping on the integer side of the CPU in between (you can actually see a little bit of “bending”, if you stand right next to a wall surface in low res like 320x200).

Since the FPU could work in parallel with the integer instructions on the pentium, this was almost as fast as just doing affine texture mapping.

This worked even on the basic Pentium.

It was likely also the reason Quake was a unplayable on the 486 and Cyrix 586.

Post reply on HN