How To Go From PC To Crossplatform Development : Q&A

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.

3 Comments

  1. imays says:

    Your slides mention virtual routers. I’ve googled it, however, I could not find any appropriate one. Would you let me know any? Thanks.

  2. Ruskin says:

    Hellow imays, that’s a great question!

    The short answer is that you might find what you need in a BSD tool called dummynet. I haven’t used it myself but I found some tutorials here and here.

    The slide you’re referring to is actually the work of Ben Stragnell, who as far as I can tell invented the technique. Essentially he custom-built his own router that managed all the traffic between the consoles we were testing with.

    He put all of the consoles on a local network, along with a PC application that sniffed all the traffic it saw on the ethernet. Our “virtual router” on the PC knew the MAC addresses for all the consoles we were testing with, and it acted as a DHCP server for them. When the consoles booted up, our router picked up the DHCP request and assigned each console a fixed IP of the form 192.168.X.2, with a subnet mask of 255.255.255.0 . That gave each console its own subnetwork. We also told each console that its router was 192.168.X.1 .

    Because each client was on its own network, the only way it could communicate with any other client was through the router; our application masqueraded as 192.168.X.1 for all values of X. Thus it could intercept every packet sent by every client, and do all sorts of things before sending its on to its destination, such as putting it in a delay queue, or randomly drop it, or fragment it, or so on.

    All of this entails a lot of low level network programming, hand-assembling UDP/TCP packets, responding to ARP, and so on, so it’s quite a bit of work. That’s why it might be easier for you to set up BSD on a PC, configure it as a router, and use the off-the-self Dummynet.

    If you are writing an XNA game, you get some nice latency simulation tools with Game Studio 2.0.

    Another thing you can do is simply delay the sending and receiving of network packets inside your own game software. You could set up some kind wrapper for the network libraries in your game, and a debug variable that tells it how long to delay each packet, or chop it up, or so on. That works great for strictly message-based protocols, but is harder to do with more exotic network libraries, and it makes the accuracy of the simulation more dependent on the performance of the game client: if your framerates are highly variable, it’ll be harder to accurately simulate latency and so on.

  3. Daniel C Wessel says:

    Hi
    I am not a developer but interested in translation.
    Can you give me an example for UI-problems. You mentionend German a lot.
    What about Right-To-Left-written languages

Leave a Reply