I found over the years that good game developers, don't necessarily produce the most optimal code or design - to put it nicely. I've attempted to understand the thinking and philosophy of Japanese programmers in the 80's and 90's, and I'm just at a complete loss. I know there are factors keeping them from optimizing and fine tuning every little thing, but as a programmer and people that I known as programmers - there's this idea, this desire, this drive - that you want to create the best/fastest/whatever code possible; you want to push something to its limits. I guess that's a cultural thing and that's not what motivated most Japanese programmers at the time (with exceptions of course. There are always exceptions).
I read an interview with one of the guys that worked with Nintendo to get 3D on the SNES (originally meant for NES - the MARIO chip), and how he ended up moving to Japan and working directly with Nintendo programmers and producers for a number of years. He mentioned that game developers, like Miyamoto, would often take a game back to ground zero - many times during its development. If that was the case, I can see how optimizing stuff would be a waste of time during the development cycle. But to me, that shows that the producers were simply dictating to the programmers rather than working with them. Like I said, I really don't know.
I don't have the time (or interest) to write a long article to try to explain the history and the different development philosophies over the last 30 years ... but if you hang around the right bars
surrounding GDC or E3 you'll probably find some old-timer to tell you about the realities of the industry.
Most programmers like a beer, and free beer definitely helps lubricate a discussion!
With your personal passions and capabilities, a big company would put you on the Engine team, where your talents would be used best.
In a small company you'd probably be a lead-programmer.
Either way ... you'll find that it's usually not cost-effective to over-optimize things, no matter how programmatically "beautiful" it is.
Having enough experience to know where to draw that line is something that usually comes with time ... and with working too many late nights in a row in order to hit a deadline.
When you're an amateur (or retired), then you get the freedom to do things however you like, and to spend as much time as needed to wring every-last-cycle out of a particular piece of code. As you already know, it's fun!
Yeah, it's bad. Not just that, but the Hsync routine is a mess as well. I'm surprised this game isn't in perma slowdown.
And that's kind of the point ... in a lot of companies, "not-actually-causing-a-problem" really is "good-enough" when it comes to shipping a project.
When if comes to hitting a deadline, it's often cheaper-and-easier to just remove an enemy sprite or a background effect, rather than get a programmer to rewrite their code to make it faster.
Not all programmers are "great" ... and sometimes you'll find a "really-not-great" one on a team, particularly in the larger teams that some of the Japanese developers used.
