Here are some of the questions I received after my GDC 08 talk, “How To Go From PC To Crossplatform Development“, and my answers to them. If you have any questions of your own, please feel free to leave them in the comments, and if I have a good answer, I’ll add it here.
Q: Will I need to author new UI assets for 16:9 high-definition as opposed to my PC UI assets?
A: Yes. You may not need to create new graphical assets, since your PC originals are probably be high-resolution enough, but you will likely need to author specific UI layouts for 4:3 standard definition as well as 16:9 high definition. You may even need to author versions specific to each language: we had to change our layout to accommodate German in The Orange Box. One way to make this easier is to make each TRC-mandated dialog its own full-screen display, as Guitar Hero does; that way you can adjust the layout for wideness or resolution simply by adjusting the art.
Q: Could you go into more detail about how to optimize CPU performance on the PowerPC?
A: Somewhere in the SDK shipped to you by Microsoft or Sony is a group of help files and white papers describing the pipeline of the PowerPC processor and suggesting best practices. I recommend that you take these papers, print them out, and put them in a large binder. You may wonder why a binder, when you could simply read the help file: well, you can read a binder some places where you cannot read a help file.
Less facetiously — your initial focus should be on cache. Data cache misses are extremely costly events and in many cases you will find that the CPU spends more time waiting on cache than it does on actual computation. Improving locality of reference and using prefetching will provide tremendous speed-ups: I often get all the performance improvement I need out of a function just by improving its cache characteristics. Don’t even worry about instruction scheduling and loop unrolling and other microoptimization until you’re sure you’ve done as much as you can to get all your data into cache before you use it.
Q: Do you keep the disc spinning continuously while the game is running?
A: No, that’s a cert violation. In my slide on IO threads, when I say “keep the disk spinning,” I only meant during the actual process of loading. The reason you need a thread for this is that if you do synchronous loading from the main thread, the disk may be spun down during the time it takes the main thread to process each piece of data. Devoting a thread purely to unbuffered DMA IO access ensures that the disk is kept spinning at optimum speed for as long as it takes to load your level archive file from start to finish. Once that’s done, you can let the disk spin down, unless you are streaming data while the level is running.
Q: When the IO threads have finished loading data, should they notify the main thread through an event driven system, or should the main thread poll for data?
A: Actually I recommend that the IO threads just go and fix up the engine assets whose data you’ve loaded — that is to say, have the thread that decompressed your texture go and update the engine’s resource handle to point to the new texture, without involving the main thread. That’ll cause less inter-thread synchronization issues which will be both faster and probably easier to program.If you can’t do that, then you should still adopt some system that doesn’t tie up the main thread while it’s waiting for data. If you just make the main thread sit behind a mutex while the IO threads are doing your work, you’re effectively back to being single threaded.