[citation][nom]jellico[/nom]Today, software coding is a major undertaking. With the complexity of the applications and all of the features they incorporate, it takes nothing less than a small team working full time to put out anything of note. With computers having memory in the gigabytes, you code for performance, not size.[/citation]
Not exactly. Speaking more specifically of the Commodore 64, for which I used to be a games programmer. The C64 was based on the Motorola MOS 6510, which is the same processor as the 6502 used in the Apple II's and the 8-bit Nintendo, with some very minor internal hardware changes. The 6510 ran at a speed of 1 MHz, and besides being slower than the Zilog Z80, it also had a far more limited instruction set. Despite of that, programmers were able to produce far better games on the C64, both visually and sonically, than on Z80-based computers like Sinclair's own ZX-Spectrum, the TRS-80's, the MSX's and their variants.
That was because inside the C64 the (relatively) weak 6510 was accompanied by a very powerful graphics chip (compared to anything else that existed at the time, of course), and the still venerable "SID", as we affectionately used to call the computer's sound generator chip. The C64's video chip was able to perform various tricks by hardware, like moving the screen image sideways and projecting multi-colored "sprites" (small images) over the background without these affecting the graphics data below them. Programmers soon found out that it was possible to "multiplex" these sprites (the video chip only allowed for 8 of them natively), making them appear more than once per video frame and so effectively being able to use as many as 32 sprites at the same time, thus opening a whole new world of possibilities, mainly for action games.
Everything in the Commodore 64 related to video, sound, and consequently, games, was synchronized to the video frames. That way, the programmers needed to know how many processor clock cycles each instruction took to execute, and how many processor clocks "fit" within each video frame and even within each line of the video screen, in order to be able to perform these tricks. So, every routine was optimized to the extreme, and that's also the reason why the best C64 action games only worked on European C64's and not on American models. Since the European TV standards displayed 50 video frames per second and the American standard 60, programmers had more processor clocks per video frame (1/50 is greater than 1/60) to work with, besides having more lines on screen. When these games worked or were adapted to work on American C64's, they would play slightly faster, as would the sounds and the marvellous SID soundtracks - just try to grab a C64 or a SID sound chip emulator and listen to the themes of games like Cybernoid (by the Maniacs Of Noise), Cybernoid 2 (by MON's member Jeroen Tel), The Last Ninja, Delta and so many others (in 50 Hz, please!), to see what SID and some ace programming was capable of.
Memory was also very limited, because although the C64 did have 64 KB of memory and a 64 KB addressing space, only about 38 KB of RAM were initially available, because the kernel and BASIC ROM's shared part of the memory addressing space, and it was necessary to set some controlling registers in order to use the RAM underneath them.
My whole point here is: of course all technologies involved have evolved exponentially, but so has the programmers' carelessness towards code optimization. The much larger availability of memory and other computing resources has indeed resulted in most of the software produced nowadays being bloated, slow and buggy. Parts of programs that should be coded at the lowest level possible (that means, as close to native machine code as possible), aren't - much on the opposite. I would cite as a positive example Croteam's debut game Serious Sam, which through a highly optimized graphics engine was able to display massive amounts of entities on screen, and some of them huge. They lost the hand in the sequel, Serious Sam 2, which went programming-wise against everything that made the first game such an achievement. The same goes for most other games currently on the market, and of course, Windows in its various flavours since XP. Ever wondered why Vista was slower, used more memory and took so much more space on your hard drive than XP, without any really significant technology improvements to justify it? It was not because your PC was outdated as many loved to say - it was because of poor, lazy, careless design and programming. These people would certainly have a lot to learn from us old-timer ZX-81, ZX-Spectrum, Apple II, Commodore 64 and even Amiga programmers.