[HN Gopher] Coding Tricks Used in the C64 Game Seawolves (2025)
       ___________________________________________________________________
        
       Coding Tricks Used in the C64 Game Seawolves (2025)
        
       Author : atan2
       Score  : 113 points
       Date   : 2026-02-19 12:24 UTC (10 hours ago)
        
 (HTM) web link (kodiak64.co.uk)
 (TXT) w3m dump (kodiak64.co.uk)
        
       | dorianmariecom wrote:
       | https://archive.is/CvXXP
        
       | diydsp wrote:
       | Ah so with splites you can have a 24 pix wide column of arbitrary
       | data that can be slid around left to right....and may act as an
       | "echo" of the players movement like in this game...or possibly
       | even different physics...
       | 
       | I love the stacking of boolean ops before branches, too.
        
       | Luc wrote:
       | > However, you can save 1 byte of RAM by using the branch
       | instructions instead, as long as you know which flag(s), if any,
       | are guaranteed to be on or off at the jump point.
       | 
       | > For example, if you know the carry flag will always be clear at
       | the jump point, and if the jump distance is within branching
       | range, you can replace JMP with BCC.
       | 
       | However if the BCC crosses a page boundary it'll take 4 cycles,
       | one cycle longer than a JMP.
        
       | empressplay wrote:
       | Interesting stuff! Regarding game sales, other developers have
       | had more success putting their games on physical media
       | (particularly cartridges).
        
       | solarisos wrote:
       | 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 wrote:
         | 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 wrote:
           | 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 wrote:
             | 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.
        
             | publicdebates wrote:
             | And a difference in price that amortizes about the same.
        
               | solarisos wrote:
               | 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 wrote:
         | There was no such thing as premature optimization back then.
        
           | solarisos wrote:
           | 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.
        
       ___________________________________________________________________
       (page generated 2026-02-19 23:01 UTC)