Exactly. When your total memory is 64KB, all optimization is mature optimization.
It's a fascinating contrast to the modern 'move fast and break things' approach. Back then, if your routine was 3 cycles too slow, the sprite didn't just 'lag'—the entire raster effect collapsed. There was a level of deterministic discipline that we've largely abstracted away in favor of developer velocity.
Yeah, but not very maintainable (mildly saying). Now, someone asked you to change a color somewhere... or whatever. After changing that color the code doesn't run because the author also reused the portion of the code (you changed) as a constant ). Now you fix that, but something else breaks, etc. Such hyper-optimized software is very brittle. Not every bloat is necessarily a bad thing, in moderation it allows to easily make changes. https://waspdev.com/articles/2025-11-04/some-software-bloat-...
Comments
There was no such thing as premature optimization back then.
Exactly. When your total memory is 64KB, all optimization is mature optimization.
It's a fascinating contrast to the modern 'move fast and break things' approach. Back then, if your routine was 3 cycles too slow, the sprite didn't just 'lag'—the entire raster effect collapsed. There was a level of deterministic discipline that we've largely abstracted away in favor of developer velocity.
Yeah, but not very maintainable (mildly saying). Now, someone asked you to change a color somewhere... or whatever. After changing that color the code doesn't run because the author also reused the portion of the code (you changed) as a constant ). Now you fix that, but something else breaks, etc. Such hyper-optimized software is very brittle. Not every bloat is necessarily a bad thing, in moderation it allows to easily make changes. https://waspdev.com/articles/2025-11-04/some-software-bloat-...