Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
XBox (Games) Programming IT Technology

First-Gen Xbox 360 Games Single-Threaded? 158

Scott Gualco wrote to mention a report at The Inquirer indicating that, despite the 360 itself being capable of multi-threading, first generation 360 titles will be single-threaded. From the article: "Every new machine has a nasty first set of games as the programmers work up to speed on the hardware. In this case, the up side is that there is about 6x the CPU power available and coming to a console near you in the second generation of games. The scary part is that everyone tells me that the PS3 is harder to program for than the Xbox360, and the tools are nowhere near the quality of Microsoft's. That means that even with an extra six months of design time, the initial PS3 games may be worse." Commentary available at Joystiq.
This discussion has been archived. No new comments can be posted.

First-Gen Xbox 360 Games Single-Threaded?

Comments Filter:
  • by AuMatar ( 183847 ) on Thursday October 27, 2005 @05:14PM (#13892411)
    Multi-threading doesn't actually buy you much with video games, not much can be done in parallel. About all you could do with it is run AI on a separate thread. That'd buy you an advantage for strategy games, but not much for anything else (where AI is light). Look at performance testing of games on multicore chips- they don't outperform single cores.
  • by Anonymous Coward on Thursday October 27, 2005 @05:16PM (#13892433)
    AI, Music, player input, networking, "worldkeeping"... hell, even rendering is parallelizable.

    Games are far more threadable than you think.
  • by applecrumble ( 910692 ) on Thursday October 27, 2005 @05:18PM (#13892446)
    What the hell? Not a single XBox 360 programmer can work out how to create new threads and identify at least some processes that are not dependent one each other? That sounds like complete nonsense to me. There are plenty of easy ways to separate your level setup, game logic, sound processing, graphics, AI, physics etc. into different threads. I'm not saying taking full advantage of all cores is easy, but the idea that none of the game developers have the ability to use more than one thread is stupid.
  • Not too surprising (Score:4, Insightful)

    by dividedsky319 ( 907852 ) on Thursday October 27, 2005 @05:23PM (#13892501) Homepage
    It seems like a lot of the things dealing with the Xbox360 have been rushed... I mean, here it is less than a month before it's released and I still don't think there's a 100% accurate list of games that will be available on the day of release.

    This seems like the easiest place to cut corners. If the game will run fine using single threads, there's no incentive to develop a more streamlined game when time is of the essence.

    This always seems to happen with systems, though... games coming out later in the system's lifespan look a lot nicer than games early on. As they use the SDK more they'll learn tricks to make things run and look better.
  • by lividdr ( 775594 ) on Thursday October 27, 2005 @05:36PM (#13892608) Homepage
    Current games don't run any faster on multiple cores than on single cores because these games are (for the most part) single-threaded. This isn't because they can't be, though - it's because the average home system is just a single core. It's a much more sophisticated problem to develop a threaded application, and the added development and QA expense isn't going to be worth it until there are a lot of multi-cored systems in use.

    Most games do have a lot of potential for taking advantage of multiple cores. Take advantage of the extra core to run another thread with a more sophisticated AI in your shooter, add more background NPC scripting to your RPG, or develop an über-realistic physics engine.

    As soon as multiple core systems start getting penetration within the consumer market, expect to see games take advantage of it. CPU speeds aren't increasing as fast as they have been in recent years. Software won't be able depend on running faster - it'll have to starting doing more things concurrently.
  • by AuMatar ( 183847 ) on Thursday October 27, 2005 @05:47PM (#13892687)
    Threading only makes sense if one of three conditions is true- either it allows you to do complex calculations early, a condition needs rapid handling, or the task is truely massive but can be handled with low communication by multiple threads. Very few things in games follow one of these.

    Music has no advantage to multithreading it. You decode it to wav and send it down to the OS to play (yes, there is an OS, even on a console these days). Its not even like the DOS era where you had to set up the DMA to interrupt you at the half buffer point to fill over the used data. Perhaps if the games were generating music this would make a difference, but they aren't- they just play pre-created files and add in a sound effect occassionally. You could uncompress on another thread, but thats not much of a gain, as levels/areas tend to just have 1 song you load upon loading the game/level/area.

    Player input is so rare an occurence (remember, we're at machine speeds here) that it doesn't make sense to give it its own thread. We're talking about something that occurs 2-3 times a second, to a GHZ processor. You'd have a thread with nothing to process 99.9% of the time, and who's time to process is extremely low priority (rememver, a long time to a CPU is a fraction of a second).

    Networking- maybe. Of course, networking really is just another type of IO, and after already dealing with a network latency, a few more ms to wait won't be noticable. So there's little advantage to it having its own thread. And the actual sending is interrupt driven by the OS, so you don't need a thread to handle writing.

    Worldkeeping and AI do make sense for complex AIs. Allowing decision making to occur on the player's turn would increase AI ability, allbeit at a cost in complexity (you'd have to guess at what the players turn would do). Good for turn based strategies like Civ and RTW. Not commonly done, though. Even Civ4 didn't multithread their AI off from the rest, and if there's any game that requires computational power its Civ.

    THe other problem is that all of these things are very tightly coupled- rendering, for example, requires input from networking, IO, AI, every time they make a decision. Music needs to know what AI is doing and what the player/network players are doing. Etc. Compare this to a multithreaded server or computer app, where threads basicly just take a request and go off, just telling the main thread when they're done. Games would require a lot more interprocess communication, and that makes multithreading hard. High cost, with very low returns.

    Now client server games are another matter- I'm sure MMO servers have multiple threads going. But notice how different that use case is- multiple loosely coupled computations, vs few highly coupled ones. ANd no rendering thread that basicly needs to know everything at all times.
  • by xgamer04 ( 248962 ) <> on Thursday October 27, 2005 @05:53PM (#13892735)
    This seems like the easiest place to cut corners.

    I guess I thought the place where most 360 (and Xbox) games cut corners, was, you know, gameplay. It's pretty easy to make a game with flashy graphics on hardware like this, and especially since your graphics programmers and artists are jizzing all over the place with their HD textures and such, but it's a lot harder to make a game that's actually good. I'm not saying this stuff won't sell, obviously it will (it's new and shiny, we love that), but the quality (and fun) will probably suffer until at least the 2nd generation of games.
  • by Anonymous Coward on Thursday October 27, 2005 @06:40PM (#13893063)
    YallaYalla ...

    Somehow you have to love the naive understanding that a given software technology can be optimized by throwing more threads at it. That's what all this marketing vodoo about multi-core and hyper-threaded hardware has got us into.

    Adapting a single-threaded technology to make use of multi-core, massivly parallel hardware is a daunting task. To be precise, the studio I work at as a gamedev professional just threw 5 years of technology out of the window and started from scratch. Doing realtime concurrent calculations in the context of 3D-applications is a bit different than writing a web application.

    And now we're supposed to replace and reimplement >5 years of hard-earned experience and existing code within the normal 18 month development schedule of a normal game title ? gimme a break ...


  • by oGMo ( 379 ) on Thursday October 27, 2005 @06:41PM (#13893068)
    How about some actual reporting, the last half of that summary was totally unneccessary.

    Seriously. What's with the XBOX-fanboy Sony-hating articles (or moderators, posters)? With "difficulty of development" we have to look at two different, but relavent points:

    • The PS2 was hard to code for. Harder, possibly, than any other platform, historically. It also has the largest library of high-quality games. So, being hard to code for doesn't mean much. It's not like the whiny gamers who moan about difficulty of development are actually doing development. Smart developers (which excludes Tim Sweeney) say things like "The PS2 is hard. But look at the cool things we're doing with it."
    • Sony is also not stupid or deaf. The PS2 required a lot of low-level programming right on the metal. Why? Because they listened to PS1 developers who said that's what they wanted. They are also aware of the PS2 difficulties out the door (which was later remedied by numerous devkits), so this time they've got [] numerous [] different [] kits [].

    How's that for some actual (factual) reporting? (Unfortunately, I can't find the link to the chart that shows how many orders of magnitude bigger the PS3 SDK is in terms of support libraries than the PS2/PS1. If someone can find this, please post.)

  • Re:Developers said (Score:2, Insightful)

    by Kazriko ( 526976 ) on Thursday October 27, 2005 @07:22PM (#13893307)
    Actually, The Playstation 2 actually had 3 threads running inside of the Emotion Engine alone. One on the MIPS main processor, and one each on the two Vector units. There was also a seperately programmed MIPS IO chip on the board as well. Asymmetric multiprocessing is a well known factor in video game development, going all the way back to the arcade machines that first had high end sound (The old arcade games frequently had a Z80 main processor and a 68000 sound chip.)

    Symmetric multiprocessing was tried before as well, back on the Sega Saturn. It wasn't nearly as successful.
  • by Tim Browse ( 9263 ) on Thursday October 27, 2005 @07:24PM (#13893327)
    Of course it's not true.

    In case it's hard to work out, here's an alternative (and, I suspect, wholly correct explanation):

    You've had real 360 dev kits for not very long - you've had to limp along with some half-way house that probably emulates many things until then. Your game is a launch title. This means it has a hard deadline. Either you launch when the Xbox launches, or you don't. This is a pretty binary state of affairs.

    You're under intense time pressure. Most of the tools you're using are new/revised, and you have to create assets that are a different level of detail/effort than the previous games you've made, so you need to learn a lot of new tricks again. While you're updating the game engine itself, of course. Everything's changing.

    Now, do you want to add to this volatile mix a bunch of multi-threading stuff for core game mechanics, with all the new code/mechanisms this will entail, and issues produced by multi-threaded access to game data, sync issues, race conditions, etc. and jeopardise the launch date of the game?

    Or do you want to do the best you can in the time you have available?

    I know which I'd choose.

    (Aside: I see a lot of comments about audio, etc - of course multi-threading for stuff like audio playback is a no-brainer. Trust me, that's not the sort of thing that game devs are talking about when they say multi-threading games is hard. Conversely, multi-threading audio playback is not exactly a huge win anyway. The chipsets on these consoles do all the hard stuff - all the audio playback engine is doing is filling buffers and updating playback parameters. Exactly how long do you think that takes anyway?)
  • That's funny... (Score:4, Insightful)

    by nobodyman ( 90587 ) on Thursday October 27, 2005 @09:43PM (#13894059) Homepage

    The PS3 is an utter dream machine for game programmers. The hardware and tools kick ass.

    Ah, I see. Mr... Anonymous, is it? Thanks for the insight. And I guess you would know, since you've developed on every console in existence. Except dreamcast and xbox, and any before the past 10 years.

      That's pretty funny, because there's this programmer out there named John Carmack who kinda disagrees [] with your views. Although, who the heck is that Carmack guy qnyway anyway? He's only written about a half-dozen 3D game engines from scratch and designs rockets in his spare time. He clearly doesn't have your level of expertise, what with your unknown work on these unspecified games at your unnamed employer.

  • Brave New Software (Score:3, Insightful)

    by vga_init ( 589198 ) on Thursday October 27, 2005 @10:05PM (#13894127) Journal

    I remember back in the day when games were making the transition from 2D to 3D graphics. At the time, 2D games in fact had much better graphics, but we suffered through the transition because after sufficient development had taken place the 3D would eventually surpass it. In the mean time, we were happy simply because 3D had a special kind of novelty, and it helped open up gameplay to new possibilities.

    I'm guessing that this works the same for any new technology. Console game developers are not familiar enough with the new hardware in order to milk it for all that it's worth, and until they can figure out how to do that then there will be that grace period where the older, single-threaded games or what-have-you are going to be more stable and better written. Once they are done catching up. however, the results will be worth the wait (hopefully).

    Actually, there is that part of me that really misses beautiful 2D games.

  • by Corngood ( 736783 ) on Thursday October 27, 2005 @10:39PM (#13894254)
    It's in all of microsoft's new C++ compilers, including xenon. Look it up.
  • by cgenman ( 325138 ) on Friday October 28, 2005 @01:02AM (#13894708) Homepage
    ...but it isn't like he's spent a lot of time programming PS2 or Game Cube games. He's spent years optimizing PC code. Of course it will seem simpler to him.

    Carmack also doesn't sound like he even has a PS3 dev kit. He's making an easy decision based upon the architecture he and his company is most familiar with. It's probably the right decision for him, recognizing that his company farms out console ports. But until a traditionally multiplatform developer speaks up, all judgement should be on hold, lest rampant fanboyism ruin business and artistic decisions.

    Being from a PS2 house that has dabbled in other platforms, the PS2 is just fine as a system. It has quirks, but it isn't like people come to work every day dreading touching the thing. All of the systems have their individual irritations. I'm guessing that the next generation will be similar: the systems will be similar enough (revolution controller excepted) that you make your game on whatever platform will ensure the most people experience it. Fanboyism has a place, but it shouldn't be in development decisions.

  • Re:That's funny... (Score:5, Insightful)

    by pslam ( 97660 ) on Friday October 28, 2005 @06:05AM (#13895395) Homepage Journal
    That's pretty funny, because there's this programmer out there named John Carmack who kinda disagrees with your views. Although, who the heck is that Carmack guy qnyway anyway? He's only written about a half-dozen 3D game engines from scratch and designs rockets in his spare time.

    Unlike the other reply, I do disagree with John Carmack. I don't think he really knows what he's talking about in this case. The Xbox 360 is based on multiple (mostly) symmetric general purpose cores, whereas the PS3 is based on having a single general purpose core and multiple DSPs. This is a huge difference!

    The DSPs on the PS3 are much, much faster than the PPC core, and your code will run faster even if you just farm a task to a DSP and wait for it to finish (i.e not parallel). They are harder to program than the PPC core, but hey that's what Devkits and proper code design were invented for. Probably the majority of your team doesn't need to know how to program it - they just call the appropriate API function like "BlendSpanLine" or "CopyBuffer" a couple of experts (or Sony) wrote for them.

    I think when Carmack commented on the state of parallelism in consoles, he didn't quite grasp how different the approach is on the PS3 and how much better a solution it actually is. Sony and friends correctly identified that (I'll hand-wave here) 90% of processing is taken up in 5% of your code, and that 5% is generally a tiny little loop you can hand optimise and shove on a DSP. I mean, FFS this is exactly what we're doing on PCs using the shader engines on graphics cards! Why complain when the PS3 offers the same thing but more versatile and more parallel?

If you suspect a man, don't employ him.