That you can apparently see where designers changed their mind when building a room, because items have sometimes been "painted over" with other items, is absolutely amazing. That is some kind of computer/game archeology that you have to be very lucky to be able to do.
I do wonder however if that's certain... in the example where bushes have been overlaid with flower titles, are we certain this does not change some property of the tiles in meaningful ways? In the same room, you can also see how the cave entry is painted over with the statue, and in this case that cave entrance is something that gets revealed later in the game.
In any case, a great series. This is exactly the type of content I come to HN for.
The flowers can also be cut as if they're bushes, making it a reasonably hypothesis that the bushes serve to make the tile "cuttable", and the flowers then just change the look.
I too enjoy the traces of development decisions that must have been made decades ago. As an example, when making a toy Gameboy emulator, I discovered Tetris writes to a memory address that is normally used for bank switching, yet the game has no memory bank controller. Given that it just barely fits in 32K, with 60 bytes or so to spare, I presume they were using such a controller during development and then maybe spent some time cramming it into 32K to spare the cost of the part.
Way back in the day, I was working on a project to extract your score from a bunch of old ROMs across various platforms. Developers picked some insane ways of storing even something as simple as a score. The very worst I recall was some old game about, I think, catching falling pots or something. Instead of just storing a 4 digit number, they stored the score as 4 pointers to the location where that digit was stored in memory. They'd increase your score by adding a multiple of the images' size to that location, and they handled overflow manually. I assume the idea here was screen rendering performance, but it didn't seem like it could possibly be worth it.
Having written a fair share of deeply embedded assembly.. if you're used to writing this close to the metal on a small system, that may have actually have been the most straight-foward way. Since ultimately the score must be rendered to the screen, and that might be its only purpose, there was probably little point in holding a "raw" intermediate value. Adding a constant and a few instructions for rollover don't sound too bad in the grand scheme of things.
figuring out tricks like that looks so fun. my "embedded" experience has been hard real time but usually on things with decent amounts of rom and ram. so tricks like that weren't needed.
There are a plethora of really neat design choices made to get the most performance out of consoles & handhelds. The only downside is it can make writing emulators or porting said code to another platform quite difficult.
Its definitely a way to go about porting games, but its laborious and sometimes hard to fully document the program's existing behavior, especially with uncommented assembly.
Comments
That you can apparently see where designers changed their mind when building a room, because items have sometimes been "painted over" with other items, is absolutely amazing. That is some kind of computer/game archeology that you have to be very lucky to be able to do.
I do wonder however if that's certain... in the example where bushes have been overlaid with flower titles, are we certain this does not change some property of the tiles in meaningful ways? In the same room, you can also see how the cave entry is painted over with the statue, and in this case that cave entrance is something that gets revealed later in the game.
In any case, a great series. This is exactly the type of content I come to HN for.
The flowers can also be cut as if they're bushes, making it a reasonably hypothesis that the bushes serve to make the tile "cuttable", and the flowers then just change the look.
I too enjoy the traces of development decisions that must have been made decades ago. As an example, when making a toy Gameboy emulator, I discovered Tetris writes to a memory address that is normally used for bank switching, yet the game has no memory bank controller. Given that it just barely fits in 32K, with 60 bytes or so to spare, I presume they were using such a controller during development and then maybe spent some time cramming it into 32K to spare the cost of the part.
Way back in the day, I was working on a project to extract your score from a bunch of old ROMs across various platforms. Developers picked some insane ways of storing even something as simple as a score. The very worst I recall was some old game about, I think, catching falling pots or something. Instead of just storing a 4 digit number, they stored the score as 4 pointers to the location where that digit was stored in memory. They'd increase your score by adding a multiple of the images' size to that location, and they handled overflow manually. I assume the idea here was screen rendering performance, but it didn't seem like it could possibly be worth it.
Having written a fair share of deeply embedded assembly.. if you're used to writing this close to the metal on a small system, that may have actually have been the most straight-foward way. Since ultimately the score must be rendered to the screen, and that might be its only purpose, there was probably little point in holding a "raw" intermediate value. Adding a constant and a few instructions for rollover don't sound too bad in the grand scheme of things.
figuring out tricks like that looks so fun. my "embedded" experience has been hard real time but usually on things with decent amounts of rom and ram. so tricks like that weren't needed.
There are a plethora of really neat design choices made to get the most performance out of consoles & handhelds. The only downside is it can make writing emulators or porting said code to another platform quite difficult.
A documented disassembly followed by a reimplementation seems to be a viable way to get games ported to other platforms.
Its definitely a way to go about porting games, but its laborious and sometimes hard to fully document the program's existing behavior, especially with uncommented assembly.
Yeah, and reimplementation is, arguably, more difficult than tweaking source code and recompiling. 8)
I never noticed Tetris trying to bankswitch before (I have also written a Gameboy emulator.) That's amusing.