Colin Piggot <[EMAIL PROTECTED]> scribbled: >> I'd rather concentrate on the game design part of it myself, for me >> that's the interesting bit about making games. :) > > Well, that has to be the main part.... but on the other hand, saving > a few t-states isn't important when you have some 2GHz + monster to > work with!
Ah yes... a whole host of other problems come to the fore though. If you're using VC++ or Intel's compiler, their optimization algorithms are pretty damn good. Provided you don't deliberately jerk them around or anything (and sometimes, even if you do). The things to worry about these days are efficiently shoving IO data around, memory allocation, and the correct choice of algorithms. (My SAM heritage does still show through though... the app I'm working on at the moment is 200kb in size when compiled (including graphics), and takes up less than 1/10000 of the available CPU power of the system. Not bad for a remote control, logging, diagnostics and analysis package for a mass spectrometer). *sigh* However. Let's be clear here; there are those who had the good fortune to grow up doing SAM stuff (or any earlier machine), and those who didn't. The ones who did? Well, they make games like Quantum Redshift, where everything runs at 60fps, and there's nary any slowdown or flicker. The ones who didn't? They make games like Splinter Cell, which are difficult to watch on an HDTV because the graphics tear all over the place. You'd think they'd never heard of double buffering, or waiting for the frame sync. And they've never changed the border color to optimize their display in their lives! When I were a lad... it were all different. All green fields! And we only programmed using 0's - we couldn't afford 1's. Seriously though... there's something to be said for paying attention to the small stuff. There's a large number of XBOX games which have come out recently where I'd love to meet the developers and shake them by the neck. Or the eyeballs -- take your pick. Simon
