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.

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.

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.

Amen

So since you can abuse eval() in a wacky way, that means JS should be compared to compiled code? I don’t understand your point.

My point is that code density is code density regardless of underlying CPU, programming language, and libraries - up to a constant (bounded above by size of an emulator and said libraries). That’s actually very rigorously defined for those who care - and has a lot of implication. The rabbit hole starts with “algorithmic complexity” also known as “Kolmogorov complexity”.

The constants matter. It may be harder to get an impressive dwitter style output from bare NES or C64, but there a 32, 64, 128 and 256 byte demo “micro scene” for c64 and DOS that pumps out very impressive stuff for the size - some that would even be impressive on dwitter.

Most NES code is tight (due to constraints). Most JS code is not (there are essentially no constraints) but that’s not inherent, as is shown with demos and proven by kolmogorov solomonoff and chaitin.

Speaking of 256 byte demos, I have to push these out http://www.youtube.com/watch?v=f1joQfp78Yo (tube by 3SC) and https://www.youtube.com/watch?v=QdaMbGPEXV8 (A Mind is Born by lft).

Impressive stuff indeed.

While we are being pedantic I seriously doubt either Metroid or Castlevania was compiled, given that most NES games were written in 6502[1] assembly.

1: 6502-ish, it was a clone with the BCD instructions disabled.

>At ~140 chars on a browser, JS can do this

*a JS function, utilizing dwitter-specific functions, called in some other dwitter-specific function, included in some specifically designed frame

Wouldn't be surprised if the total JS code required nears the submitted game.