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.
Comments
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.