[louthy]

As somebody who was working in the games industry at the time (as Playstation 1 engine guy), the amount of hoops you had to jump through to make something go as fast as possible was enormous; and sometimes best practice falls by the wayside. The way your game stood out was to do more than the others, I remember hand optimising my C written engine into R3000 assembler and made it fit in 4k so it could fit in the R3000 instruction cache. This would involve manually writing concurrent operations where I'd use the 4 cycles it took to access something from memory (which meant 3 spare cycles waiting) to do other operations. It certainly wasn't pretty, but it broke Sony's own figures for how many polygons could be rendered per frame. That stuff mattered at the time, because doing more per frame meant the game could do more - nobody was going to thank you for pretty code that was slow.

As well as that, the industry was very much a cottage industry at the time, many programmers were self taught and came from an era where one person would make the entire game. I was one of those programmers, and in the days before you could readily find information online about how to do things 'correctly' you found your own way (no Google, no StackOverflow, ...).

Would I want to go back to writing code like that today? No way. But I understand why it happened.

I put 'correctly', because even today we don't know how to write code. It's still an open question, and anybody that tells you they have the 'one true way' needs some extraordinary proof - otherwise it's just arrogance.

My preferred method these days is functional, but after 30 years of programming - starting from a BBC Micro (8bit, 32K of RAM), I am still learning. Mostly becoming a good programmer (in my opinion) is learning to deal with the inadequacies of the wet-ware between your ears. It's all coping strategies for the complexity of the problems we're trying to solve today.