[dahfizz]

Right, but that 140 bytes of JS runs on mountains of browser and OS code. The ROMs run directly on the hardware.

Just think of the boilerplate needed to set up graphics when you can't simply output to a canvas tag. That's the point being made - JS is an interpreted language, so you can't really compare code size with compiled code.

[beagle3]

But hardware back then was simple and uniform per platform. I developed professionally for the SNES some 30 years ago. You could set up sample playback with a handful of instructions, sprites with another handful, etc.

It actually is comparable in my experience and opinion.

Setting up graphics modes on the SNES was much easier (hardware wise) than e.g. switching VGA (or even CGA) to graphics mode - one did have bios INT 10h to rely on for the PC, but “select and set up graphics mode, colors, etc” in practice was a comparable effort.

And many games implemented tiny virtual machines to simplify and compress code. As another example, ZX Spectrum basic rom (16k of z80 machine code and data) spent a few hundred bytes implementing a floating point stack VM interpreter that compressed relevant math code by approximately 1:5 compared to “native” calls.

[conductr]

Wow. Reading along and I didn’t fully appreciate it either. This adds a ton of perspective to what early game devs were working with.

[bebrws]

Amen