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.
Most video games are single threaded (Score:2, Insightful)
Re:Most video games are single threaded (Score:4, Insightful)
Games are far more threadable than you think.
Surely this isn't true (Score:2, Insightful)
Not too surprising (Score:4, Insightful)
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.
Re:Most video games are single threaded (Score:2, Insightful)
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.
Re:Most video games are single threaded (Score:4, Insightful)
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.
Re:Not too surprising (Score:5, Insightful)
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.
Re:Surely this isn't true (Score:2, Insightful)
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
YallaYalla
Re:'everyone' tells you, do they? (Score:3, Insightful)
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:
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)
Symmetric multiprocessing was tried before as well, back on the Sega Saturn. It wasn't nearly as successful.
Re:Surely this isn't true (Score:5, Insightful)
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)
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 [google.com] 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)
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.
It's called OpenMP... (Score:2, Insightful)
I'm not saying Carmack is wrong... (Score:3, Insightful)
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)
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?