It sort of blew my mind seeing the whole map and how small it looks. It conflicts with my objectively true memories, which are that Metroid is a vast unknowable maze, possibly endless.
But yeah the breakdown of how it actually works is pretty interesting. It seems like it was close to "good enough" on the famicom, and then needing a few extra cycles for audio on the NES bumped it over the threshold where many frames started getting missed. And then screen loading was not efficient, perhaps a victim of wanting a flexible system that allowed lots of screens at the cost of unpacking them into RAM slowly. Seeing this sort of thing (and the broken RNG) dispels the mystique that all those 8 bit games are perfect polished optimized gems, and they too are making tradeoffs and having bugs and "eh good enough" moments.
I have the famicom version of the soundtrack on my playlist, it's significantly better than the NES one. Having dedicated sound hardware explains that.
Seeing this sort of thing (and the broken RNG) dispels the mystique that all those 8 bit games are perfect polished optimized gems,
One idea that gets re-invented every few years is a "high level portable assembler" that will allow you two write assembly for any architecture. Because assembly is inherently fast, all your code will be much faster than that dumb bad bloaty compiled C++ that everybody knows is inherently slow. But yeah, you can write fast or slow code in assembly. And "fast" or "fast enough" is very much dependent on what you are doing and what the hardware is doing. Even with the exact same CPU and GFX, the code was "fast enough" on Famicom and "almost fast enough" on NES. For assembly code to be fast, you still need to do the work of design and profiling and refinement. Just the fact that it is written in assembly doesn't actually mean that what you are doing is inherently super fast.
Just playing 8 bit and 16 bit games dispels you of that notion real fast. Lots of games back then had flickering, slowdown, and bugs. The boon of emulation nowadays is that the more popular of these games have patches to address these problems.
I wonder how this could be fixed, and still stay within 32 kB.
It seems like to avoid major lag, you almost have to load one row or one column of tiles (the video calls these "macros") at a time instead of an entire screen. So the "structures" should maybe always be an entire row or an entire column of tiles. There's a lot of repetition of rows and columns, so you'd still get good compression with this method, but I don't know if it would be good enough.
elaforge@reddit
It sort of blew my mind seeing the whole map and how small it looks. It conflicts with my objectively true memories, which are that Metroid is a vast unknowable maze, possibly endless.
But yeah the breakdown of how it actually works is pretty interesting. It seems like it was close to "good enough" on the famicom, and then needing a few extra cycles for audio on the NES bumped it over the threshold where many frames started getting missed. And then screen loading was not efficient, perhaps a victim of wanting a flexible system that allowed lots of screens at the cost of unpacking them into RAM slowly. Seeing this sort of thing (and the broken RNG) dispels the mystique that all those 8 bit games are perfect polished optimized gems, and they too are making tradeoffs and having bugs and "eh good enough" moments.
I have the famicom version of the soundtrack on my playlist, it's significantly better than the NES one. Having dedicated sound hardware explains that.
wrosecrans@reddit
One idea that gets re-invented every few years is a "high level portable assembler" that will allow you two write assembly for any architecture. Because assembly is inherently fast, all your code will be much faster than that dumb bad bloaty compiled C++ that everybody knows is inherently slow. But yeah, you can write fast or slow code in assembly. And "fast" or "fast enough" is very much dependent on what you are doing and what the hardware is doing. Even with the exact same CPU and GFX, the code was "fast enough" on Famicom and "almost fast enough" on NES. For assembly code to be fast, you still need to do the work of design and profiling and refinement. Just the fact that it is written in assembly doesn't actually mean that what you are doing is inherently super fast.
Gommy@reddit
Just playing 8 bit and 16 bit games dispels you of that notion real fast. Lots of games back then had flickering, slowdown, and bugs. The boon of emulation nowadays is that the more popular of these games have patches to address these problems.
EntroperZero@reddit
I wonder how this could be fixed, and still stay within 32 kB.
It seems like to avoid major lag, you almost have to load one row or one column of tiles (the video calls these "macros") at a time instead of an entire screen. So the "structures" should maybe always be an entire row or an entire column of tiles. There's a lot of repetition of rows and columns, so you'd still get good compression with this method, but I don't know if it would be good enough.
MintPaw@reddit
This starts pretty slow, but he ends up going through a lot of the Metroid game loop, it's pretty interesting.