I'd be extremely surprised if programmers now used current-gen consoles efficiently as programmers in the 8-bit era used the NES.
Me too, I highly doubt it. But this has a number of reasons which I, as a fellow dev, fully understand:
* A bazillion times more code and logic needed. Modern video games have a million lines of code (
one source) or more (two million for just the Unreal engine), and optimizing it all would in all likelyhood require even more code.
* A bazillion times more processing power and memory. Back when, every performance optimization would've had an impact on the game. Nowadays, they don't. For example, ++i is faster than i++ (something to do with the latter increment operation requiring an intermediate variable). These days, the choice between the two is only a logical one (as in, do I need the current or the next value), as the performance is only like 10%. But back then, that would've been very relevant.
* Money. A developer costs money - ranging anywhere from between $40 to $200 an hour - and each hour spent on optimization that may not have a significant impact on performance will not be spent on adding actual business value. And optimizations for modern platforms cost much more than just an hour. Unless you're John Carmack.
It's still possible to squeeze every last inch of performance out of a system though, just as long as someone's willing to pay for it. One recent example is the LMAX Architecture, described properly by
Martin Fowler in this article. There's a team that took Java and the JVM by the nuts and squeezed every inch of performance out of it to create a fucking fast market transaction system, achieving six million transactions per second on a dual-socket, quad-core processor at 3 GHz. I'd say that's a lot, especially when you take in- and output into consideration.
And to boast myself: we finished a graphical iPad app today that uses just 6 MB of memory. 'Cause we're pr0 like that. We don't employ any particular hacks or particularly optimized for memory usage though, and we're probably abusing the CPU / GPU far more than we could've if we were graphics / performance experts and got much more money / time for it (and if anyone gave a damn).
One simple optimization we did though was to not have animations occur on both halves of the screen at the same time. We noticed that, at one point in the application, both halves would have running animations (should do a post about it soon, you'd get it then), at which point the app's frame rate would drop on the iPad 1. This is because, at that point, the entire screen needs to be refreshed, as opposed to just the left side of it.
That's just an example of an optimization - not redraw part of the screen if nothing happens there. An optimization we did then was to not run animations on both halves of the screen.
(Another simple optimization was to reduce the amount of overall simultaneous animations on lower-end systems like the iPad 1. In this case, that also changed the logic / how it works, but w/e).
