Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
XBox (Games) Programming IT Technology

First-Gen Xbox 360 Games Single-Threaded? 158

Posted by Zonk from the crying-shame dept.
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? More

First-Gen Xbox 360 Games Single-Threaded?

Comments Filter:
  • 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.

    • Re:Most video games are single threaded (Score:4, Insightful)

      by Anonymous Coward on Thursday October 27, 2005 @04:16PM (#13892433)
      AI, Music, player input, networking, "worldkeeping"... hell, even rendering is parallelizable.

      Games are far more threadable than you think.
      • AI, Music, player input, networking, "worldkeeping"... hell, even rendering is parallelizable.

        Exactly... Hell, for a 3-core Xbox360 chip, I'd say the smartest thing to do would be have two cores pretend they're doing SLI stuff. Core one does coordination and all the world bookkeeping, the other two cores are focused on rendering half the scene.

        • That might work with a three-core graphics card, but there's generally too much linkage between different parts of the code and different objects to somehow magically divide the CPU's work in half. Graphic cards inherently do many serial things, whereas CPUs do many things serially.

          • With current games that is true. However there is no reason new game engines cannot be made that do not have this limitation.

            Unfortunately for the programmers, getting multi-threaded programs right is hard. I've done it, but I spent more time killing the thread related bugs than all the other bugs. (at least I think I've got all the bugs worked out now) This despite designing the project in advance to be threaded. Getting the locks right is hard (unless you can live with far to many locks, not the c

            • Rendering a movie can be parallelized because for a 2-hour movie, you can predict what you need to process two hours ahead, and break up the frames among however many cores/CPUs you have. However with a game, as things change you need to respond right now, so you don't know what is happening in the next few seconds. With multiple cores you can do things like render on one core and process audio and AI on the other two. To some extent you might even be able to do some prediction and preprocess some game logi
      • Exactly, there's nothing special about computer games that means they cannot be multi-threaded. It just so happens that all major game platforms have been single-threaded so far so programmers don't have much experience with it.

        • Exactly, there's nothing special about computer games that means they cannot be multi-threaded.

          Yes there is - games require real-time performance, and to get the best out of the hardware. One of the most common uses of multi-threading is to make sure the UI of an app isn't unresponsive due to a large amount of CPU processing that is being done (or something else with high latency, like network code over the internet).

          As another poster has pointed out, a lot of the activities a game goes through are v

      • AI, Music, player input, networking, "worldkeeping"... hell, even rendering is parallelizable.

        Rendering is already done in parallel. The trouble is that it's the GPU that's doing it and not the CPU so having multiple threads/cores doesn't help much. Sure, you could switch to CPU rendering, but that is usually much slower than using the GPU.

        And with the exception of AI, most of the tasks you listed take very little time, even on a single threaded CPU. And even AI doesn't have to take that much more time. It

      • Re:Most video games are single threaded (Score:4, Insightful)

        by AuMatar ( 183847 ) on Thursday October 27, 2005 @04: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.
        • Ahh, I thought that the post meant that there was no threading at all. Obviously in this scenario there exist other threads to handle this stuff.

          If there is a threading API for the OS, why not one that is visible to programmers.

          I took the meaning of all of this to mean that the there is not multithreading across the cores, but that there is probably a threading substrate available to the programmers. This makes a lot more sense, since the OS would already have to provide context switching functionality.
          • The OS doesn't use threading for this, it uses interrupts. A hardware interrupt fires when network IO comes in, player IO comes in, music buffer almost empty, network done writing, etc. The interrupt does very little work- respectively its use DMA to read from network card, mark player IO in IO queue, setup DMA to write to sound card, setup DMA to write next frame to network card. Very small burst, because there isn't much to do. If you were to design a processor with no interrupts, it might be smart t
        • 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.

          Or, perhaps, threading also makes sense if the program compute-intensive and is running on a machine with multiple processor cores, so by multi-threading you can simply get more stuff done per second than you can by single

        • C'mon, you've got to be taking the piss. First you said;

          Multi-threading doesn't actually buy you much with video games, not much can be done in parallel.

          And now you're talking about there being no advantage in it. The advantage is thus: It's cheaper to make heaps of cores on last years process than it is to make a super fast core on todays process.

    • 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.
    • So, what you're saying is that you don't want real time operations like playing music to be run in a separate thread from things like the rest of the logic of the game.

      That way, we get nice, choppy noise in the background, rather than simple, clean, sound.

      Nobody would put up with single threaded development in 2005. Simple fact of the matter, everyone is developing in C++, and someone has probably implemented a threading API for XBox360. It's not like programmers hack this stuff in differently for every t
      • Music doesn't need to be handled in the background- its loaded at level start. Playing it is an OS call to set up DMA to the sound card from a given buffer. When the buffer is nearly done (in DOS we did it at the halfway point), an interrupt fires, and you overwrite the used section with new data via DMA on the interrupt. Total cost: some time on load plus a few microoseconds per interrupt. Throwing a thread in there is pointless.

        Given your other post, I'm curious- ever taken a course in hardware des
        • Yes, actually, numerous courses. I almost TA'd the operating systems course here this semester. I merely picked music as an example. I sort of regretted picking it when I said it for just the reasons that you mention, but at the time I wasn't thinking about the fact that music is handled by a sound card (I know, an odd thing to say).

          All I really meant to say is 1) Threads are useful, I know that I use them a lot, and 2) The OS can provide threading capabilities, so PROBABLY what they meant is no hardwa
        • FWIW, I also kind of regret my asinine tone. Good job handing it back to me. Still, I really just picked a stupid example, the principle stands true.
        • What you've described is the very bottom level of the sound system and is rather PC-centric. If your audio needs are extremely simple this is theoretically enough. However, next-generation console games (and even current-gen games) require much more sophisticated work than this.

          Music and speech is non-resident because there's just too big a variety in it to preload it all even on Xbox360 - besides, why spend time at a loading screen when we don't need to? A sports game will have literally thousands of speec
  • 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.
    • Threading well is harder than people seem to think. I've seen code written (not for video games, but for business applications) that makes extensive and very inappropriate use of threading such that the performance and scalability of the software is worse than if the programmers had just single threaded everything.

      And are there any consoles that support threading now? For that matter, how common is multithreading in PC games? Most gaming machines (PC) have single chips and don't do multiprocessing, so pr
      • I've said it before and I'll say it again, what is it with the slashdot fear of threading? Otherwise intelligent people seem to consider it (a) amazingly hard (b) brand new and cutting edge (c) only any use if you have multiple cores and (d) not really very useful at all to be honest. All four are false.

        Using an appropriate language (for example, Java), and provided you know what you're doing, threading is not hard. One of the apps I am responsible for routinely runs 800+ threads on 16 processor boxes. I'm

        • Otherwise intelligent people seem to consider it (a) amazingly hard (b) brand new and cutting edge (c) only any use if you have multiple cores and (d) not really very useful at all to be honest. All four are false.

          I have personally done threading. It is amazingly hard. I've spent as much time debugging thread related problems as everything else. In a single threaded design these problems wouldn't exist.

          Thread is not brand new anymore.

          If you have just one core you can do everything faster in a singl

          • You can have a GUI controlled by another process easily enough. Make the other process dump its data to stdout, and redirect its stdout to a pipe into your program before you call exec. This is how most GUIs on top of command line apps work (like linux cd recording tools). Or have it use shared memory, and send a message to the parent when its done with the memory so the parent can read it. ITs definitely doable.

            The ease of doing this in Unix, combined with the real fast process creation time, is why m
            • But there's really not much functional difference between multiprocess and multithread! If you want two threads which are totally independent you can have it. The advantage of threads over procs is that they are more lightweight. Of course this is on solaris/windows - I understand than on linux LWPs give you similar properties to threads (and indeed that's what Java uses under the hood) but I'm no Linux expert.
              • Threads and processes are the same thing in Linux (a thread is a process). The only difference is wether or not they share an address space. If they share an address space, they can access the same variables. If they don't, they need to message data back and forth. That sharing is multi-threadings advantage and disadvantage- the advantage is that it has very fast access to the data. The disadvantage is that you need to lock the data explicitly, which can be difficult.

              • If you want two threads which are totally independent you can have it.

                In theory you are correct. However in practice you are wrong. In the real world memory 'scribblers' tend to corrupt data for the other thread, so you start looking in the wrong place for them. Worse, they are intermittent, so they are harder to catch in the first place. All you know is your customers (because these bugs often don't show up in test) are complaining that your program randomly doesn't work.

                In practice processes se

        • Its what the threads are doing that makes it complicated. I would bet your 800 thread app there is doing request based threading- the threads each handle one type of request, requests are parallel, and requests only need to talk to the requestee at 2 times- at the begining and end of a request. That type of multithreading is trivial.

          Games don't have that luxury. Every subsystem needs to share data with every other subsystem. High degrees of coupling means high degrees of communication. They're also g

        • Using an appropriate language (for example, Java), and provided you know what you're doing, threading is not hard. One of the apps I am responsible for routinely runs 800+ threads on 16 processor boxes. I'm no rocket scientist, but it works.

          I've written theaded code, too. I've done it in several languages, including Java. The last Java app I wrote that routinely used more than 100 threads per proc was server software that used one thread for each connection, with many hundred simultaneous connections. So

    • Dude, have you ever heard of a little project called the HURD? Threading increases complexity so very much.

    • Re:Surely this isn't true (Score:2, Informative)

      by Anonymous Coward
      I wouldn't be surprised if it were true; first generation games do not have the luxury of time or access to working, complete, hardware. What you're given is performance estimates which are garbage (with the exception of the Gamecube and Dreamcast in the last generation), 'similar' (ie very different) hardware, and an exec who thinks it is possible to produce a game that is '10 times beter than half life 2 in 18 months (with 10% the budget).'

      How do they do it then?

      You licence existing technology (Unreal Eng

    • Re:Surely this isn't true (Score:2, Insightful)

      by Anonymous Coward
      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 con

    • Re:Surely this isn't true (Score:5, Insightful)

      by Tim Browse ( 9263 ) on Thursday October 27, 2005 @06: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?)
      • of course multi-threading for stuff like audio playback is a no-brainer

        Its also not something that's generally handled by the processor. There's a separate processor for that. On PCs they call them sound cards.

        Even my PDA has one. You send it the location of the audio stream in fairly large chunks and it takes care of the rest by interacting with the bus and memory controller. Making a thread for just that is a braindead decision. The only reason you'd want to do that is if you keep all your audio comp

        • of course multi-threading for stuff like audio playback is a no-brainer

          Its also not something that's generally handled by the processor. There's a separate processor for that. On PCs they call them sound cards.

          Well, yes, that would probably be why I went on to say...

          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 l

  • How can it get worse? (Score:5, Funny)

    by Qzukk ( 229616 ) on Thursday October 27, 2005 @04:22PM (#13892490) Journal
    first generation 360 titles will be single-threaded ... the initial PS3 games may be worse

    They'll be half-threaded?
    • OT but what did your sig bunny originally look like before the line limit maimed him?
    • Sorry to reply seriously to a joke, but my guess is they'll have the same problem as early PS1 and PS2 games. They may have threading issues just like the Xbox360 as well, but I'm still betting on graphics being the one that'll hurt.

      Remember the early PS1 games? A lot of them were 2D or mixed 2D/3D (Final Fantasy VII had 2D environments with chunky, lego-man 3D characters, many others had 3D environments with 2D objects in them). It was a good while before good-looking fully 3D games were the norm, and even

  • Not too surprising (Score:4, Insightful)

    by dividedsky319 ( 907852 ) on Thursday October 27, 2005 @04:23PM (#13892501)
    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.

    • Re:Not too surprising (Score:5, Insightful)

      by xgamer04 ( 248962 ) <(moc.oohay) (ta) (40remagx)> on Thursday October 27, 2005 @04: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.
      • There were a lot of VERY good games for Xbox with VERY good gameplay (Halo, Jet Grind Radio, MechWarrior, etc), not to mention they often had the best ports of multiplatform games, so I'm pretty sure you have no idea what you're talking about.

        As well, how can you judge 360 games? Have you played them? Or are we going to make the assumption that "systems from Microsoft suck", even though the Windows and Xbox divisions are so far apart they're almost like different companies?
        • There were a lot of VERY good games for Xbox with VERY good gameplay (Halo, Jet Grind Radio, MechWarrior, etc), not to mention they often had the best ports of multiplatform games, so I'm pretty sure you have no idea what you're talking about.

          Thats not often true, often multi platform games would be made for the PS2 (more cash potential) ported over to the Xbox and GC resulting in some games performing worse on the box (rarely the gc). Of games optimized for each platform, then the Xbox was often slightly b
        • There were a lot of VERY good games for Xbox with VERY good gameplay ...

          This is your opinion.

          Halo

          Re-hashed FPS with decent multiplayer.

          Jet Grind Radio

          JGR was a Dreamcast game. Its sequel appeared on the XBox (read: sequel).

          MechWarrior

          According to gamefaqs.com, there is no game named "MechWarrior" for the Xbox.

          As well, how can you judge 360 games? Have you played them? Or are we going to make the assumption that "systems from Microsoft suck", even though the Windows and Xbox divisions are so far apart they'
          • Halo revolutionized console FPS. It was the first FPS since GoldenEye that showed, given a proper control scheme, the genre could be successful. It introduced thousands of new gamers to FPS that wouldn't have played them, do to a much smaller PC gaming market. Give MS some credit here -- it took balls to take a non-established genre and have it be your launch title.

            The sequel argument is bunk. PS's biggest title was Final Fantasy VII. Nearly every game Nintendo makes is a sequel of a 20-year old series
            • First of all, I should clarify what I was trying to say in my original post (this one [slashdot.org]). I was attempting to say (with some sarcasm, which often doesn't help clarity) that from my analysis of Xbox releases, press regarding Xbox games, experience playing Xbox games, and the announced Xbox 360 games, that there are not many games with gameplay that is either breaking new ground, or refining already existing gameplay.

              With that said, you might now argue that I didn't "say" any of these thing in my original post
    • It seems like a lot of the things dealing with the Xbox360 have been rushed.

      That's no coincidence though, because MS knows full well that it's only the Xbox 360's 4-5 month launch lead over PS3 that might even up the odds a little. Remember that PS2 is so far ahead of Xbox1 in market share and in game count that Sony can pretty much ignore MS in this generation.

      MS doesn't want that to continue in the next generation, obviously, so I think they're right to bring out the new machine ASAP regardless of its s

  • Middleware (Score:3, Interesting)

    by Admiral Ackbar 8 ( 848624 ) on Thursday October 27, 2005 @04:23PM (#13892502)
    The middleware they all use probably isn't there yet. Once it is I think you will see more multi-threading.

    All I know is that doing it on you own is very challenging and adds so much complexity (race conditions and locking to name a few) that it's probably not worth the effort. Really all these systems need for great graphics is a kick butt graphics card!
  • Keep in mind how new this mutli-threading thingy is. Why is sarcasm so hard to get across in type?
  • Most of the first run games will probably be developed based on the engine of the single-threaded previous sequel.

  • Sounds familiar (Score:4, Interesting)

    by nevergleam ( 900375 ) on Thursday October 27, 2005 @04:33PM (#13892587)
    I'm suddenly reminded of that Anandtech article from a couple months back about how developers were:

    1) Not enthusiastic about using multiple threads and
    2) Very disappointed in both the 360's and the PS3's single-threaded CPU performance.

    It was pulled pretty quickly, and the story is that the article was pulled to protect the anonymous source.
    • Never mind the fact that the story was factually incorrect in several manners, mistakes that were quickly pointed out. That couldn't have been the case, since anything printed on TEH INTARNET is always 110% true.

      (At least two different people here inside MS with the knowledge pointed out glaring mistakes in that Anandtech gibberish within 15 minutes of that story being published. Essentially, the guy was talking out of his ass.)

  • SDK tools? (Score:4, Funny)

    by Red Flayer ( 890720 ) on Thursday October 27, 2005 @04:46PM (#13892678) Journal
    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

    I told Sony over and over again that they'd better include an IDE with their SDK... they really dropped the ball on this one.
    • They don't need an IDE, they just need better tools. ProDG gives them a good debugger (the PS2 one was, at least), and it can integrate with Visual Studio if you want. Now they just need to get IBM to give them a really good cell compiler(s) instead of that hacked up MIPS gcc. In fact, I don't really care if there's an SPE compiler or not, I can manage using an assembler for that, they just need a solid PPE C++ one.
      • It was just a joke... there was a very vitriolic thread about IDEs on Wednesday evening.

  • Not entirely true (Score:5, Interesting)

    by PIPBoy3000 ( 619296 ) on Thursday October 27, 2005 @04:48PM (#13892690)
    This has been discussed [evilavatar.com] on Evil Avatar for awhile now. It seems that for Oblivion at least, that statement isn't entirely true [elitebastards.com]

    Gavin Carter: The game's code takes advantage of the multithreaded nature of the Xbox 360 and multithreaded PCs to improve just about every aspect of the game. The primary function is to improve framerates by off-loading some work from the main thread to the other processors. We do a variety of tasks on other threads depending on the situation - be it sound and music, renderer tasks, physics calculations, or anything else that could benefit. Loading also gets spread across hardware threads to aid in load times and provide a more seamless experience for the player.

    That's not to say that writing software for multiple cores is easy. It's actually extremely hard to synchronize the various tasks that run on the different cores. I suspect that most early games will run slowly on a single core or somewhat inefficiently on multiple cores. It will be quite some time before developers can figure out how to use all of them efficiently enough.

    The developer's dream is a single processor console that has a very fast CPU. Unfortunately that's hard to manufacture, so they're stuck with something less than ideal that can be made cheaply with today's technology.
    • Also, show me a processor that has as much power as three 3GHz 64 bit PPC processors...
      • Depends on what type of work you're doing on them. The 360's processor doesn't have the level of branch predition that you can get in a general purpose CPU. This actually hurts things like AI.

        Now before your panties bunch up in your ass and you throw a hissy fit, I'm not saying that the 360's processor sucks. It just won't be as efficient as a general purpose CPU. Therefore some games may run the same on the 360 and PC while the PC supposedly has less power.

    • I have seen sample multithreaded apps, and they look crazy at times.

      Why not allow different processes to run on different cores? why not add an extra parameter to exec and fork so the child process is 'related' to the parent process and is run simultaneously or in close proximity with the parent, on another core?

      I think the libraries make things complex, in an attemp to stay posix compliant. Heck I dont know if posix is broken if exec("helloworld",JUSTANOTHERTHREAD); is valid, provided exec("helloworld"); i
      • Errm.

        Different processes generally do run on different cores, on most multiprocess OSs I know of.

        Child processes are related to the parent process (they have a parent-child relationship, the parent can pass some shared information into the child).

        A greater degree of sharing (e.g. a shared memory space) is exactly what an (OS-level) thread is...a seperate, schedulable execution context which shares a memory space with its parent.

        You're right in the pthreads API isn't the nicest one to work with. But in my ex
    • The developer's dream is a single processor console that has a very fast CPU. Unfortunately that's hard to manufacture, so they're stuck with something less than ideal that can be made cheaply with today's technology.

      My dream is to finally have a language that handles threads in a managable way, rather than me having to manually deal with synchronisation, race issues, locking, etc, etc, etc. Most main modern languages (including java and C#) are built to essentially be backwards compatable with single threa
  • http://igo.ampednews.com/platform/xbox360/news/281 9/ [ampednews.com]
    There's the correct link to that story.
  • This should not even be an issue. How hard is it for MS to create a multithreaded api/sdk.

    Microsoft could and should have designed the system around the technology.

    Granted I'm not a gamer and don't follow the industry as such, it seems to be that MS may have made a huge mistake trying to get this system out the door.

    Let's see.....
    Games approved for release by MS -> 0
    Games using systems biggest selling point (as in ultracool new multicore cpu) -> 0
    Then the WalMart interference problems ( yes I k
    • The SDK already must support multiple cores. There are two problems. First, the OS on the box is NT, right? Not the greatest OS for multithreading to begin with. Second, games have traditionally not been multithreaded because there is no particular gain. Only one console has ever had multiple symmetrical processors, namely the Sega Saturn, and it was commonly described as a programming nightmare or a "pile of chips on a board". The PS2 has three different processors (the CPU and the two vector units, which
    • It's in all of microsoft's new C++ compilers, including xenon. Look it up.

  • Developers said (Score:2, Interesting)

    by thegamebiz ( 925741 )
    Lots of developers said quite a while ago in something I read on either GameSpot or EGM that most, if not all, of the first generation Xbox 360 titles would be single threaded. Using multiple threads is still a new technology and one that many developers are still only beginning to learn. I remember them saying that around the third and fourth generation of games is when you'll begin to see them take advantage of multiple cores.

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

      by Kazriko ( 526976 )
      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 be
      • You've got it exactly right. People who are used to balancing the EE/VU0/VU1 are going to have no problem dealing with the 360. Even the PS3 is going to be a similar paradigm to PS2, just more general purpose, so there's no reason to be worried.
  • This story is false as a couple posters have already pointed out.

    Look, Slashdot, I know that if some idiot posted on a website how the 360 was made with tin cans and string and that everyone who buys one is going to mysteriously disappear from the face of the Earth while Microsoft's zombie army grows and grows. That doesn't mean you actually have to believe it.

    I don't think anyone's even been able to determine what "event" this clearly-false statement was made at.

    (next thing you know, they'll be posting ar
    • "(next thing you know, they'll be posting articles here about how the Xbox 360 is powered by DEAD KITTENS...)"

      So, if they ship with a couple discs of pr0n, the 360 will be self-powering? Sweet!

  • History repeats itself (Score:1, Interesting)

    by Anonymous Coward
    I remember when COLECOVISION first came out, everyone complained that the launch games were "written in Pascal" and so weren't as cool as games in assembly language. This was also something the apologists claimed to explain away the poor quality of the launch titles.. "yeah the games kinda suck, but that's because they're written in pascal. The next batch of games will be in assembly and will be a lot better". Then of course, the great fallout happened... "oops".

  • I've Worked On (almost)Every Console (Score:2, Interesting)

    by Anonymous Coward
    I've worked on almost every console over the past decade or so and worked on every area of game engineering - graphics,AI,physics, and even sound recently.

    It is clear to me that Microsoft is in full press damage control right now.

    I don't know where the hell this notion that "game developers will need to time to adjust to the scary new world of multithreading" came from. But wherever it did come from it is complete bullshit.

    Console game developers have been writing parallel code for a long,long time. Hell, I

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

      by nobodyman ( 90587 ) on Thursday October 27, 2005 @08: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 [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.

      • ...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, le

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

        by pslam ( 97660 ) on Friday October 28, 2005 @05: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?

    • Can you provide any details to what the game is about?

      Nothing major, but a ballpark, something like "First Person Shooter", or "Real Time Strategy" or SOMETHING. Exactly what kinds of games does your company produce?

  • I downloaded the PS3's SPU instruction set pdf from the IBM download page. After reading that doc I thought, "Wow, this instruction set looks FUN!" It kindof reminded me of when I moved from MOS6502 to Intel 8088 - how much more fun it was to bit fiddle with the 8088. I think PS3 games are going to be a lot of fun to write code for - for bit fiddlers and premature optimization freaks. Will it be harder to code PS3 for than the XBOX 360? Unless Sony does something amazing with their SDK, I would say yes
  • Gabe Newell, one of the main guys behind Half-Life and Half-Life 2, talked about this a while ago. He was really annoyed at all these consoles and their multithreaded nature, since it meant a game you write for one of them only works on that console, and it's a bitch to write the games at all, since multithreaded things over like 4 or 6 proccessors or something is a real nightmare for coders. I'm grateful I play all my games on a PC.

  • Brave New Software (Score:3, Insightful)

    by vga_init ( 589198 ) on Thursday October 27, 2005 @09: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.

  • I love that the Inquirer linked "single-threaded games" with "blocky graphics". It couldn't have been, oh, that these are demos with code from 4 months ago. Or, that Walmart is show casing these bad boys on run of the mill CRTs instead of HDTVs. No, the sole reason for blocky graphics: single-threading. They do realize that just about every game up until now has used single threads, right?

    Next they're going to be saying the controllers sucks because the USB ports aren't used.
    • I'm the mentioned member of the Inq that "got his hands on" an Xbox360. I walked into WalMart the night of the /. article myself, played with it for awhile, and was rather dismayed by the quality. It SAID I was playing in HD - so I think I can safely assume that NO CRT displays on the market can do HD, unless something's changed in the last oh, year or so, and no one told me.

      The games played well, but the graphics were the same as I've been playing for the last 6+ months. One would think Microsoft would
  • Their doing pre-release damage control for the fact that the first generation 360 games will suck. They explain it away as being "single threaded" when the real reason is that the software companies have only had real machines for a short period of time and that first wave of games for a system almost universally suck.

Slashdot Top Deals

Solutions are obvious if one only has the optical power to observe them over the horizon. -- K.A. Arsdall

Close