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…
Ask HN: How were video games from the 90s so efficient?
121–130 of 238 posts
Re: Ask HN: How were video games from the 90s so efficient?
#122The 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?
#123Earlier 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.
Re: Ask HN: How were video games from the 90s so efficient?
#124Earlier 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…
I'd wager the micro stuttering is GC?
Re: Ask HN: How were video games from the 90s so efficient?
#125Casey Muratori explains it well: https://youtube.com/watch?v=pgoetgxecw8
Re: Ask HN: How were video games from the 90s so efficient?
#126Optimizing 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?
#127Coming 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?
#128I 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…
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?
#129I 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…
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?
#130I 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…
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.