7 ms·

There is something incredibly refreshing about looking at C64 optimizations. Today we throw gigabytes of RAM at simple CRUD apps, while these developers were co

There is something incredibly refreshing about looking at C64 optimizations. Today we throw gigabytes of RAM at simple CRUD apps, while these developers were counting every single cycle and byte. It’s a good reminder that 'efficiency' used to be a core requirement, not an afterthought.

publicdebates 7mo ago
And starting fires or making coats used to be forms of art, now we just buy a Zippo and a London Fog and call it an afternoon. Jobs evolve to specialize. I call that progress.
- kleiba 7mo ago
  And yet there's a difference between a cheaply made coat from an Asian sweat shop and one made with quality materials by a skilled tailor.
  - solarisos 7mo ago
    Exactly. The 'Asian sweat shop' vs. 'skilled tailor' is a perfect analogy for the state of software today. We’ve optimized for speed of delivery (Zippos and fast fashion) but we’ve lost the durability and resource-efficiency that comes from a tailor-made approach. It’s fascinating that in 2026, we’re needing more and more powerful hardware just to keep up with the bloat of basic applications, whereas the Seawolves devs were finding ways to squeeze 'art' out of 64 kilobytes.
    - monkpit 7mo ago
      You’re absolutely right!
  - publicdebates 7mo ago
    And a difference in price that amortizes about the same.
    - solarisos 7mo ago
      That’s true for the consumer's wallet, but the 'amortization' breaks down when you look at the systemic cost. In software, the 'cheaply made coat' equivalent (bloated frameworks, unoptimized dependencies) creates a massive technical debt that doesn't just affect the buyer—it affects the entire ecosystem's energy consumption and hardware requirements. The Seawolves devs weren't just saving money; they were respecting the constraints of the medium. When we treat resources as infinite because they are 'cheap,' we stop being engineers and start being assemblers.
stronglikedan 7mo ago
There was no such thing as premature optimization back then.
- solarisos 7mo ago
  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.
  - senfiaj 7mo ago
    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-is-ok https://waspdev.com/articles/2025-11-04/some-software-bloat-...
dwd 7mo ago
Chris Wild who ported the Lords of Midnight to the PC, and then later worked with Mike Singleton to create versions for Android/iOS that were unfortunately only published after Mike's passing away, put together this series of articles about the optimisations Singleton used to squeeze so much into the limited memory of the ZX Spectrum and C64. If I remember correctly Chris ported from the Spectrum. The data structures are particularly interesting using tokens/lookup tables to compress the data as much as possible. https://www.icemark.com/tower/index.html https://www.icemark.com/tower/index.html Also some notes on Doomdark's Revenge where Singleton managed to create a bigger map and feature more characters. https://www.icemark.com/gate/index.html https://www.icemark.com/gate/index.html

publicdebates 7mo ago

And starting fires or making coats used to be forms of art, now we just buy a Zippo and a London Fog and call it an afternoon. Jobs evolve to specialize. I call that progress.

kleiba 7mo ago
And yet there's a difference between a cheaply made coat from an Asian sweat shop and one made with quality materials by a skilled tailor.
- solarisos 7mo ago
  Exactly. The 'Asian sweat shop' vs. 'skilled tailor' is a perfect analogy for the state of software today. We’ve optimized for speed of delivery (Zippos and fast fashion) but we’ve lost the durability and resource-efficiency that comes from a tailor-made approach. It’s fascinating that in 2026, we’re needing more and more powerful hardware just to keep up with the bloat of basic applications, whereas the Seawolves devs were finding ways to squeeze 'art' out of 64 kilobytes.
  - monkpit 7mo ago
    You’re absolutely right!
- publicdebates 7mo ago
  And a difference in price that amortizes about the same.
  - solarisos 7mo ago
    That’s true for the consumer's wallet, but the 'amortization' breaks down when you look at the systemic cost. In software, the 'cheaply made coat' equivalent (bloated frameworks, unoptimized dependencies) creates a massive technical debt that doesn't just affect the buyer—it affects the entire ecosystem's energy consumption and hardware requirements. The Seawolves devs weren't just saving money; they were respecting the constraints of the medium. When we treat resources as infinite because they are 'cheap,' we stop being engineers and start being assemblers.

stronglikedan 7mo ago

There was no such thing as premature optimization back then.

solarisos 7mo ago
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.
- senfiaj 7mo ago
  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-is-ok https://waspdev.com/articles/2025-11-04/some-software-bloat-...

dwd 7mo ago

Chris Wild who ported the Lords of Midnight to the PC, and then later worked with Mike Singleton to create versions for Android/iOS that were unfortunately only published after Mike's passing away, put together this series of articles about the optimisations Singleton used to squeeze so much into the limited memory of the ZX Spectrum and C64. If I remember correctly Chris ported from the Spectrum. The data structures are particularly interesting using tokens/lookup tables to compress the data as much as possible. https://www.icemark.com/tower/index.html https://www.icemark.com/tower/index.html Also some notes on Doomdark's Revenge where Singleton managed to create a bigger map and feature more characters. https://www.icemark.com/gate/index.html https://www.icemark.com/gate/index.html