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

111–120 of 238 posts

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

#111

Post by bellyfullofbac »

adventured wrote: post #71
thewileyone wrote: post #34

The simple answer is you have to work within the constraints you're confined in. I used to work for an ecommerce company, a very early Amazon competitor, and because the Internet was so slow in the early years, we had a rule that our homepage had to be less than 100k, including image icons. Every 1k squeezed was a success and celebrated. Even today Amazon's homepage is less than 1MB, go ahead and check. Now with CSS…

> Even today Amazon's homepage is less than 1MB, go ahead and check. Pingdom reports 4.8mb (3.3mb of images), 661ms to load, and 298 requests. GT Metrix reports 2.65mb (2mb of images), and 307 requests. An incognito window with Firefox on my system says ~3mb and ~265 requests. Just the top six or seven media assets combined that loaded initially weigh in at about 1mb. Certainly not the worst page ever, granted.

Nitpick: MB = Megabyte. Mb = Megabit. mb = millibit?

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

#112

Post by yayachiken »

uncomputation wrote: post #108
yayachiken wrote: post #93

Earlier quoted context omitted.

As far as I remember, Pokemon Gold/Silver were given to some special assembly optimization guru after the game was pretty much finished. He was able to squeeze out so much memory that the Kanto region of the original games was more or less added as an afterthought. And it was totally worth it, having the entire first game available in the sequel, just set a couple of years in the future, seeing how the world changed…

Wow, thank you for this info, I didn’t know that. It’s fascinating what they did back then.

I am glad you found that interesting.

If you want to look the story up: The "assembly optimization guru" was Satoru Iwata, who would later become CEO of Nintendo of America, and who unfortunately died of cancer a couple of years ago.

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

#113

Post by shadowofneptune »

smoldesu wrote: post #83
dehrmann wrote: post #40

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…

It's more understandable considering that it started as a Java applet which could be run in the browser.

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

#114

Post by perryizgr8 »

When needed, even today programmers achieve high efficiency levels. As an example, look at John McCarmack's write ups about the first oculus headset they developed. It was supposed to run entirely on Galaxy S7 phones. They had to devise an overclocked mode for the screen to be able to maintain a consistent 90Hz in order to avoid nausea. I used the Gear VR and it was true that no matter what content was being displayed, the headset never lagged or fluctuated. Really impressive considering it is only now that flagship phones have started offering 90Hz and 120Hz screens.

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

#115

Post by SavantIdiot »

andrewjf wrote: post #106
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…

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 recall, and I should be flogged for forgetting it... but it was directed at game programmers and covered all sorts of assembly tricks for Intel CPUs.)

Also, a little later in the 90's: VTune. When VTune dropped it was a game changer. Intel started adding performance counters to the CPUs that could be queried in real-time so you could literally see what code was missing branches or stalling, etc. Source: I worked with Blizzard (pre-WoW!) developing VTune, feeding back requirements for new performance counter requests from them and developers.

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

#116

Post by jeffbee »

You are not calibrated for the actual hardware we had at the time. Nobody was running Descent on a 300MHz computer. It ran perfectly well on the 486DX2-66, or any Pentium. 300MHz would have been an impossible luxury, something you could just barely get in very high end workstations near the end of 1996. The first 300MHz Pentium didn't come out until 1999.

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

#117

Post by jeffbee »

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…

Yeah, it's helpful to remember that games in the early 90s at least would have been expected to run on a 486, which were still very widespread, and the 486 was neither superscalar nor out of order. It was pipelined (the main difference between a 486 and a 386) but it was still at that time simple to reason about how long your instructions would take. And there was no speedstep or any of that stuff yet.

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

#118

Post by nitrogen »

SavantIdiot wrote: post #115
andrewjf wrote: post #106

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…

(At the time there was a book called The Black Art of ... Assembly? I can't recall, and I should be flogged for forgetting it...

Probably not the book you're thinking of, but Michael Abrash's Graphics Programming Black Book was a mix of reprinted old articles and new content that had a bunch of highly optimized (for 486) graphics routines. IIRC there was a 9-cycle-per-texel texture mapping routine.

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

#119

Post by radicalbyte »

SavantIdiot wrote: post #115
andrewjf wrote: post #106

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…

It was common back in the day for machines to ship with detailed technical documentation.

I spent many an hour as a young child reading the C64 programmers reference guide, calculating the op speed and drawing memory maps.

https://archive.org/details/c64-programmer-ref

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

#120

Post by cerved »

crate_barre wrote: post #79
thewileyone wrote: post #34

The simple answer is you have to work within the constraints you're confined in. I used to work for an ecommerce company, a very early Amazon competitor, and because the Internet was so slow in the early years, we had a rule that our homepage had to be less than 100k, including image icons. Every 1k squeezed was a success and celebrated. Even today Amazon's homepage is less than 1MB, go ahead and check. Now with CSS…

Hit the nail on the head. Constraints fuel creativity and innovation. If I give you everything, then what do you have left to do? It’s like the General that wins every battle because he has the most elite soldiers. Could the General win with a rag tag shoddy group of soldiers?

Like the Köln concert!

https://en.m.wikipedia.org/wiki/The_K%C3%B6ln_Concert

Post reply on HN