First-Gen Xbox 360 Games Single-Threaded?

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.

Comments

Most video games are single threaded

[AuMatar]

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

[Anonymous Coward]

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

Games are far more threadable than you think.

Re:Most video games are single threaded

[Vaevictis666]

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.

Re:Most video games are single threaded

[applecrumble]

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.

Re:Most video games are single threaded

[mc6809e]

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 depends on what algorithms you use.

Now a scene with a lot of vertices might benefit from extra threads/extra cores, but now you've increased the burden on the GPU. It soon becomes the bottleneck.

Researchers have spent a lot of time trying to find ways to make it easy to take advantage of parallel processing. The fact is that their efforts have been fruitless.

Re:Most video games are single threaded

[lividdr]

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.

Re:Most video games are single threaded

[AuMatar]

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.

Re:Most video games are single threaded

[qbwiz]

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.

Re:Most video games are single threaded

[bluGill]

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 case for a fast video game)

Re:Most video games are single threaded

[NitsujTPU]

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 title.

What probably is true is that it's not multithreading in hardware, across the processors, which is a completely different issue. Again, software houses probably wouldn't deal with this, since MS would release and API for it. Not having release one with the initial development kits seems a bit backwards though. There probably is a threading substrate, however, provided with the development kits that at least implements some variety of software threading.

IE, "the XBox360 is tricky to program for" is kind of a silly statement to begin with. Most people writing this software are not dealing with the underlying hardware.

Re:Most video games are single threaded

[NitsujTPU]

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. Exposing it through an API would be a no brainer.

Re:Most video games are single threaded

[AuMatar]

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 to do threading for this, as it would make for a very complex poling mechanism at the begining of a frame loop. But with interrupts there, there's no need to have a user level thread sitting around to basicly just hand off to the OS.

And modern console OSes definitely provide threading support- devs just don't take much advantage of it, due to the reasons in my post. There just aren't many good reasons to use it.

Re:Most video games are single threaded

[AuMatar]

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 design, OS design, or assembly? This type of thing would be taught in any of them. Basicly, if your processor has DMA and interrupts (anything in the past 20 years, including embedded chips), you don't need a thread to handle data writes to hardware.

Re:Most video games are single threaded

[Tim Browse]

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 very strongly linked (temporally, and with the amount of shared data). Just saying "use threads" is a good way of slowing this stuff down.

You have to use threads sensibly, obviously, but you also have to know that games are 'special', in that some things you'd think could be multi-threaded would actually be a big performance hit.

Re:Most video games are single threaded

[NitsujTPU]

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 hardware SMT/SMP support, not that there was no threading API.

I should have settled for just saying that, rather than trying to name an example in a problem domain about which I know little.

Re:Most video games are single threaded

[NitsujTPU]

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.

Re:Most video games are single threaded

[PGC]

Coming from a person who probably never made any program that required heavy processing for the models that needed to be displayed... you definitly want the control/navigation thread to be seperate from the thread updating the models. Even though the resulting graphics move choppy, the user won't have the horror of choppy controls.

Re:Most video games are single threaded

[alan_dershowitz]

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 logic frames (count on doubling or tripling your ram usage.) But in a game you are never going to get the kind of performance boost from parallelization that you do from any sort of batch processing, simply because you are being fed your "job" in realtime instead of in one giant glob that you can just break into multiple pieces.

If you want, you can put your game loop in one thread, your audio into another and your rendering in the third, but it's not going to help you any more than just a really fast CPU when you can't render any further ahead than the current iteration in the game loop. You're just going to have a mutex in your game loop that halts all the other threads until the current iteration is finished, or everything will get all out of sync, so the benefits of multiple cores just got blown.

Re:Most video games are single threaded

[grahamwest]

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 speech calls and these days games have hours of background music. Music is streamed so there's a double-buffer in system RAM in addition to the double-buffer you describe. Speech is load-on-demand so we just slurp it all into memory, play it as if it was resident and then flush it. More sophisticated choreography of audio such as stitching together speech calls, transitioning from music intros to looping mainplays or changing hardware effects processing when sounds start or stop (eg. a sound might duck the volume on other voice channels) all require monitoring of the hardware state with fairly high precision and doing more work than is advisable from an interrupt callback.

Better yet, the next-gen consoles audio hardware is basically just a DAC. All the mixing and effects processing (reverb, 3d spatial, etc) is done in software. The CPUs are crazy-fast at math so why put dedicated hardware on the board for that, I guess?

Re:Most video games are single threaded

[Anonymous Coward]

That maybe true for basic games, but more and more 3d games use 3d positional sound, usually with environmental effects. This involves a non-trivial quantity of calculations between the basic sound being loaded in the ram and the sound being played to the sound card. Now, true, expensive sound cards can do this themselves in their hardware (EAX & A3D), but that does not seem to be the case for Xbox360 and many games on platforms that offer hardware sound don't use such hardware implementations because of their limitations (like Doom3 was going to do before the legal wranglings).

Re:Most video games are single threaded

[StrawberryFrog]

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-threading.

Like oh, games on the xbox 360 maybe?

Re:Most video games are single threaded

[Anonymous Coward]

That only works if the computations are independent of each other like he already said. If it relies on data from another thread then the first one is forced to stop and wait, net gain is 0, you might as well have made it single threaded to begin with. If anything depending on the amount of interaction a multi-threaded program CAN perform worse than a single threaded, like all tools it has to be used approprately

This is the key thing about Threads, They have to be reasonably independant of each other to actually function. This is why a lot of games are single threaded, almost everything interacts with each other.

You also can not use threads for quick little bursts either, it does take time to create and setup a thread so unless the task is sufficiently large you will take a performance hit.

Re:Most video games are single threaded

[mewphobia]

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.

Re:Most video games are single threaded

[StrawberryFrog]

Games almost always do several loosely-coupled things at the same time. Sound, rendering, opponent AI, reading player input etc....

Surely this isn't true

[applecrumble]

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.

Re:Surely this isn't true

[Reality Master 201]

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 probably people haven't got much experience in writing efficient, performant code for games that uses threading capabilities.

Not to say that threading games is impossible, or even particularly hard, just that when you bring a new technique/capability to a programming realm, it takes time to learn how to exploit it properly.

Re:Surely this isn't true

[xgamer04]

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

Re:Surely this isn't true

[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 Engine,Doom Engine, etc.) which for the most part have focused on a single threaded environment, and create content that runs at a 'acceptable' rate on the crappy hardware you've been provided (ie. 20-30 FPS) and hope that the real harware will provide better performance.

Re:Surely this isn't true

[radish]

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 no rocket scientist, but it works. Threading is also not new, or rare. Taking a look at task manager on the XP box I'm using right now shows over 300 threads running, with some apps taking as many as 50. This is on a single processor box - threading works on a single processor because it allows you, the application programmer, not to have to write your own scheduler (for example, to handle blocking IO without locking up the GUI). The OS is usually better at these things than you.

Re:Surely this isn't true

[Reality Master 201]

Well, for one, games for consoles aren't written in Java. For two, I've seen some particularly nasty bugs in Java applications (expensive, commercially available, "mission critical" applications) that involve threading problems. And that, furthermore, these issues didn't show up in nearly as severe a way on a single processor machine.

I don't fear threading. I've used it, would use it again, and understand how it works.

However, as I stated before, the problem of incorporating a completely new feature into an application is not as simple as one might think, and that some conservatism in adopting the new techniques is often warranted.

Re:Surely this isn't true

[bluGill]

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 single thread. Of course this can make for ugly code, and has a large number of problems in many cases. It is still faster because you don't have to deal with locks. It might or might not be easier depending on what other tasks you have to do. (the obvious example is it is much easier to have one thread handle GUI events while the other does long processing)

Threads are useful for those cases where you have very separated tasks. However in most cases you can save all the hassle of threads by just using a different process and thus ensure you never have locking problems. Obviously this cannot work if you have a GUI controlling a long process though. (I'm sure there are other examples.)

Yes you can make threads work. However in many threaded programs there are 1 time in a billion bugs that are really hard to fix. Thus good programmers recommend that you avoid threads if you can.

Re:Surely this isn't true

[AuMatar]

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 going to be updating the same objects (both for efficiency and due to that high degree of coupling). This is a locking nightmares.

On a side note- the locking mechanism in Java is poor. Firstly, it defies the most important concept in multi-threading- lock the data, not the code. Java locks code, via the synchronized command. But what you really want to do is lock the data- keep only 1 person accessing a given piece of data at a time. Doing this by functions requires a lot more code to be locked than need be, and confuses what is actually being protected (thus increasing the likelyhood that bugs will come when you add new methods or change what internal data existing methods touch). Secondly, it has no real locking on a scope less than function. Thirdly, its not possible (unless its changed since last I touched Java, which has been a few years) to say, lock method A and B of a class with one lock and C with another. Or use the same lock on 2 instances of a class. THis is easily doable with semaphore(s). Not allowing this requires a lot more locks, which lowers efficiency even more.

Re:Surely this isn't true

[AuMatar]

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 most Linux servers go multi-process instead of multi-threaded. Communication is a bit harder, but you avoid a minefield of bugs.

Re:Surely this isn't true

[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 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:Surely this isn't true

[forkazoo]

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. Sounds like it was probably similar to your app.

In that case, the move to threads wasn't a performance issue. Having that many threads involves quite a lot of overhead, so it would have run much more slowly than something with a more modest number of threads. It was a matter of convenience. I had a single chunk of state data, and it needed to be fed to all the clients. None of the threads had to interact with each other.

Now, let us imagine a game. The renderer needs the geometry in place before it can send it to the graphics card. The physics engine will move the geometry. The physics engine needs to work out the results of the AI. There are lots of relationships like this where it is easy to say that each task should be its own thread, but done with a simple implimentation like in my server software (and I assume your software), the various tasks would be clobbering data, leaving data in an inconsistent state, using extra memory for multi-buffered state, or losing lockstep per-frame synchronisation.

Also, you need to work with single threaded libraries and API's. You can't have two threads trying to render to the same DirectDrawSurface or OpenGL context. That'll run you into a world of hurt (if it does anything at all!). You need to deal with locking and mutexes, and all that fun stuff.

No, threading isn't fundamentally that hard. There are many cases where it is very easy. Making a game ain't one of them.

That said, there are certainly quite a few straightforward ways to take advantage of multiple threads. Audio and Graphics rendering don't need to make significant changes to state, and they can run in parallel as soon as all the geometry is in place. (Audio needs to run after physics so that collisions can trigger audio sound effects.) If you have ten monsters who all need to have AI computed, you can give each monster his own thread. Unless they have gauntlets of psychic communications +2, the threads won't need to interact. Of course, if you are trying to leverage an existing code base to get the game out by the time of the console launch, it may be very difficult to make all that actually happen in practice. I expect that as time goes on, the middleware will become more thoroughly threaded, and we'll see better use of the hardware.

Re:Surely this isn't true

[Anonymous Coward]

// impossible examples
class foo {
  private Integer lock1 = new Integer(0);
  private Integer lock2 = new Integer(0);
  private static Integer globalLock = new Integer(0);
 
  void methodA() {
      synchronized(lock1) {
// do A stuff here
      }
  }
 
  void methodB() {
      synchronized(lock1) {
// do B stuff here
      }
  }
 
  void methodC() {
      synchronized(lock2) {
// do C stuff here
      }
  }
 
  void methodD() {
      synchronized(globalLock) {
// put code you want to protect across instances here
      }
  }
}

Re:Surely this isn't true

[AuMatar]

Hmm. Some new stuff here, when I used Java synchronized was a keyword used in function calls only- public synchronized foo(). So basicly you say synchronized(blah) instead of semTake(blah). That ups Java to be more or less the equivalent of C/C++/etc, except it calls semCreate for you. Interesting to know, but no real advantage for Java.

The rest of my point still stands- threading in tightly coupled environments is hard. The 800 thread guy is most likely doing trivial request based threading, as I said (if he's not pulling 800 from his ass).

Re:Surely this isn't true

[Tim Browse]

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?)

Re:Surely this isn't true

[radish]

I'm certainly not pulling it from my ass. Of the 800, around 100 are directly handling incoming requests. These hand off to threaded execution engines which further paralellise (sp?) the request processing. Those engines account for maybe another 300 threads. Then you have system threads, cullers for caches, messaging transceivers, and the like. It's not a game for sure (no vsync to worry about!), but we certainly do have areas of sensitivity to locking, sync, etc where multiple threads share state.

Re:Surely this isn't true

[radish]

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.

Re:Surely this isn't true

[AuMatar]

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.

Re:Surely this isn't true

[Anonymous Coward]

I think you need to look again. You can have synchronized blocks smaller than functions and you can even specify what object they are using for a lock. Never is the lock the code. At the worst case with things like synchronized static functions the lock object is the class, which you can lock on yourself too to interoperate. But you can easily just have a synchronized section inside a function to lock on something else.

Re:Surely this isn't true

[Anonymous Coward]

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?

As a developer working on a non-launch 360 title (posting anonymously for the obvious reasons), I can say that you have the most sensible explanation. I can't confirm that the launch titles will all be single-threaded, but given that the teams would've only had the final kits for about a month before submission (which should've happened already), they'd have been insane to try anything fancy.

That said, the game I'm working on -- which I would call first-generation, we'll be finishing development shortly after launch -- is definitely multithreaded and probably gets something like 75% utilization of the three CPUs. So when they say "the first crop", they really only mean launch titles; titles coming out next year, or at least the ones that need the power, will use all CPUs.

Bottom line, this really isn't a big deal.

Re:Surely this isn't true

[gedhrel]

Java's original design (the langauge, not the JVM) was centred around the monitor, but that's a long time ago. As others have pointed out, a synchronized(foo){ ... } block works well, and locks on foo (not the code).

The problem with attaching locking directives to members rather than wrapping code with blocks that lock on data members is that it's much harder for a compiler to determine when it can relax locking constraints. Mind you, Java developers get it wrong too (google for the double-checked locking idiom and why it's broken).

Incidentally the latest editions of Java include some more of the "usual suspects": reader/writer locks, semaphores, etc, which have relatively efficient implementations in terms of the underlying synchronized(){} primitive. Look for the java.util.concurrent and java.util.concurrent.locks packages for details.

Re:Surely this isn't true

[bluGill]

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 separate your memory access, which makes the bugs much easier to find and fix. (Note that I said easier, not trivial. These bugs are still very hard to single threaded programs)

Re:Surely this isn't true

[Anonymous Coward]

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.

Please don't tell me you work at 3D Realms on the DNF team.

Re:Surely this isn't true

[fireboy1919]

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 compressed and decompress it constantly.

Re:Surely this isn't true

[Tim Browse]

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 long do you think that takes anyway?

I'm not entirely sure what your point was. Or are you agreeing with me?

How can it get worse?

[Qzukk]

first generation 360 titles will be single-threaded ... the initial PS3 games may be worse

They'll be half-threaded?

Re:How can it get worse?

[Gottjager]

OT but what did your sig bunny originally look like before the line limit maimed him?

Re:How can it get worse?

[Ayaress]

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 then, there were 2D games that came out like Valkyrie Profile and various fighters that looked much smoother than simmilar 3D games.

Then the PS2. A lot of the early games looked butt ugly when compared to the recent releases. To look back at GTA3 next to San Andreas on the PS2, it's hard to believe they're on the same system. Do the same with the PC or Xbox, and although there's a difference, it's not nearly as marked.

When the Game Cube and Xbox each came out, they both looked (at least to my taste) a fair bit better than the PS2. Before long, though, the PS2 games were a good match with the other consoles.

With the lackluster screens being shown so far and the quantity of "bullshots," I don't think the PS3 titles will live up to the system's touted graphical power.

Re:How can it get worse?

[Breakfast Pants]

Very true. Soul Calibur 1 for Dreamcast looked better than Tekken Tag for PS2.

Re:How can it get worse?

[Anonymous Coward]

Actually, the line limit wasn't the problem. There was another guy posting with a sig of "bunny feet from the bunny sig for sale". We actually ran into each other in the same thread once. Was pretty amusing. No idea if the guy's still using that sig, but as amusing as the thought of some futuristic sociologist looking through "this slanted-line period thing" would see the interchange without the original sigs and have no clue whats going on, I haven't found anything else interesting enough to overcome my laziness to bother changing it.

Re:How can it get worse?

[DrEldarion]

FF7, FF8, and FF9 were ALL 2D backgrounds with 3D elements on top of them. Sure, the character models were a big clunkier in FF7, but since they all were 2D/3D instead of full-3D, it most likely wasn't due to initial programming difficulty as much as just plain not enough power period.

Not too surprising

[dividedsky319]

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

[xgamer04]

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.

Re:Not too surprising

[L0k11]

yeah, because the first generation of xbox games had pretty crappy gameplay.

I remember this game called halo, what a shocker!

(sorry for being sarcastic, I haven't had much sleep) And to prove I dont have anything against xbox i'll tell my little ps2 story (again). I got the console the first christmas of its release and kept it for 2 years, In that time (1st gen games) I was not inspired to buy a single game. It was an AU$700 dvd player.

Then someone took a risk (I might have grown out of video games) and bought me a gamecube. And the games were actually worth buying (especially because nobody else was buying them and they were cheap). [/nintendofanboy]

Re:Not too surprising

[ClamIAm]

yeah, because the first generation of xbox games had pretty crappy gameplay. I remember this game called halo, what a shocker! Well, I guess the original XBox was a bit different, since most PC developers could port rather easily. Halo was also in development way before the XBox. And I don't really like Halo all that much. Sure, it's a well-polished FPS, but the only huge breakthrough it brought was the LAN-party-in-a-box aspect.

Re:Not too surprising

[Anonymous Coward]

I remember this game called halo, what a shocker!

You sure about that? I remember it too, except it came out on the PC years earlier, had a better story, better AI, and they called it Half-Life.

Re:Not too surprising

[SilentChris]

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?

Re:Not too surprising

[king-manic]

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 better then the GC while drastically better then the PS2, this all hlding more true with games displayed in HD.

Re:Not too surprising

[Intocabile]

I don't think I've ever read a review that said the Xbox port was worse.

Re:Not too surprising

[Delphiki]

About all Half-Life and Halo have in common is that their sci-fi themed FPS's which were extremely well done and extremely popular. The gameplay feels completely different. But then again, you'd know that if you weren't just a PC game fanboy troll.

Re:Not too surprising

[SilentChris]

I've never seen an Xbox game that somehow ran more poorly than a PS2 one. Please identify.

Re:Not too surprising

[xgamer04]

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're almost like different companies?

Now you're just getting ridiculous. You're taking an opinion that some people might have and pushing it onto me. Never mind the fact that I never said anything like this. What I should've said is that there really hasn't been much (if any) innovation in gameplay on the XBox platform (Live doesn't count, PCs had good internet play first). The next generation looks to continue this, with shinier FPSes and such.

Re:Not too surprising

[SilentChris]

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. Sequels drive the entire market, not just Xbox.

Regarding Mechwarrior, don't be a prick. I meant the Mechwarrior series. Any gamer who's been around knows what I'm talking about.

As to the "where did I say that" comments:

"I guess I thought the place where most 360 (and Xbox) games cut corners, was, you know, gameplay."

*I*. As in your opinion. As in your completely wrong, unsubstaniated, blatantly fanboy opinion. Try going to E3 or a con and PLAYING the next generation of games before passing judgment.

Re:Not too surprising

[xgamer04]

First of all, I should clarify what I was trying to say in my original post (this one). 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. When I post on internet forums, I generally don't put a lot of thought into posts that are a large paragraph long or smaller. These "one-off" type posts are just my raw opinion and/or analysis of the issue I'm writing about, and my writing style in this mode often uses much sarcasm and generalization. I often imply many things, such as my assumptions or conclusions. Now, I'll move on to address your points.

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.

We must have different ideas on what "revolutionizing" a genre means. My interpretation of this word in regards to the analysis of videogames is when a game introduces a radical new concept. The only thing, in my opinion, that Halo introduced that was radically new wasn't really radically new, and that was the LAN party. You could argue that this is radical because it was a console and not a computer, but consoles are computers. They're just a different form-factor.

I really don't understand how GoldenEye and Halo were successful because of their control schemes, or the more bizarre claim that good control schemes somehow validate the FPS genre on consoles. Certainly play control is an important part of whether or not a game is "good" and/or successful, but there are plenty of games that have good control and are not good games.

While it's true that Halo introduced the FPS genre to a much larger player-base (and I can say with some certainty you could probably claim *millions* more and not be wrong), this does not itself make a game revolutionary, in my definition of the word. I'm sure marketing teams think your usage (and application) is fine.

I don't think that the FPS genre was unestablished on consoles prior to Halo. PC FPS games have been ported to consoles since console specs were good enough, as an example Doom was ported to pretty much everything in the early-mid 90s, and there were many console FPS games as well, including one you mentioned, Goldeneye. So on the one hand, you state that the FPS genre on console was proved successful because of Goldeneye, and then state that Halo was released at a time when FPS on console was unproven. If I give MS any credit for Halo, it would be for their realizing that Halo would make a good launch title, not for having "balls", which I do not believe they have, at least in this sense.

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. Sequels drive the entire market, not just Xbox.

When I said "sequel", it was in response to your argument that JGR was a "good game". I was not arguing whether or not it was a good game. I was continuing my (now clarified) argument from my original post that the Xbox does not have many games that are groundbreaking in the gameplay area. Following my argument, calling out a game as a sequel is perfectly fine, because most sequels generally don't introduce very fresh concepts. Unless the JGR game on the Xbox introduced some radical new gameplay concept I've never heard of, it can't be considered a game that furthered or refin

Middleware

[Admiral Ackbar 8]

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!

Cutting edge stuff!

[chobee]

Keep in mind how new this mutli-threading thingy is. Why is sarcasm so hard to get across in type?

Re:Cutting edge stuff!

[X0563511]

Tone of voice doesn't carry over text very well. Neither does facial expressions.

Re:Cutting edge stuff!

[xgamer04]

Also, does anyone know how long developers have actually had *final* dev kits? I think it would be pretty hard to optimize for things like threading when you have beta hardware.

Re:Cutting edge stuff!

[Yocto Yotta]

You should of hyperlinked the word "new" to a site that talks about how long multi-threading has been around. That actually would have done the trick quite well. Your welcome. =)

Re:Cutting edge stuff!

[mackman]

Stop smirking dammit.

No surprise

[DavidLeblond]

Most of the first run games will probably be developed based on the engine of the single-threaded previous sequel.

'everyone' tells you, do they?

[Xarius]

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 wasn't aware that everyone had PS3 development kits. Development kits for a console that is nowhere complete yet.

Are you sure by "everyone", you don't mean "the fanboy gremlin that lives in my arse"?

And as these systems get more complex, the development is going to get harder. I am a Sony fanboy, buy I am interested in hearing about what it's like to develop for Nintendos new system. I'm not interested in hearing "omgz teh XBOX has best hax tools for game making!" or "stfu m$ noob, ps3 pwnz joo cell!".

How about some actual reporting, the last half of that summary was totally unneccessary.

Re:'everyone' tells you, do they?

[Rayonic]

I wasn't aware that everyone had PS3 development kits.

Don't act silly, he clearly means 'everyone who has a PS3 dev kit'.

You're right that the dev kits are still beta, but you have to realise that the launch titles are being developed right now.

Re:'everyone' tells you, do they?

[oGMo]

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.)

Sounds familiar

[nevergleam]

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.

Re:Sounds familiar

[Saige]

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.)

Re:Sounds familiar

[Anonymous Coward]

The hardware of the xbox360 and the ps3 are very different.
The xbox has mulltiple cores while the cell-processor uses
some kind of limites coprocessors.
I think this will be a major problem with the nice, shiny, glitzy
hardware of the next generation consoles since porting games
will become very difficult. Probably the full power of the
hardware will be used only by the middleware (rendering,
phisics simulation) while the games will be single threaded
for a long time.

Re:Sounds familiar

[Anonymous Coward]

So what are your references? Why should I believe you? Link me, O Saige!

Re:Sounds familiar

[Anonymous Coward]

anything printed on TEH INTARNET is always 110% true

Taking the sarcasm into account, this is sort of like a Cretan saying that all Cretans are liars.

Re:Sounds familiar

[rAiNsT0rm]

Yep. I was the submitter of that article to /., and I knew it would get pulled quick... however it was all true. I have worked in this industry for some time and have a number of developers that I speak with regularly, not a single one of them is excited or enthusiastic to work on the PS3 or 360. Almost to a tee they all give the same reasons why all this multi-thread talk is just crap. I've been saying it for months on /. and always get flammed and modded down, but lo and behold it is the truth *gasp* amazing.

Wait until people start to see how slow the releases come out, and the massive lulls in new releases in times when gamers expect many. The cost and development times are just out of hand, and when sales don't keep up with the massive development costs the PS3 and 360 become expensive multi-media centers. The only true hope this round is that Sony and MS take huge financial hits (which they are already feeling, check out todays business news about MS and the stock issues and Sony cutting jobs left and right) Nintendo is perfectly placed to once again pick up a broken videogame industry and run with it. I wish them the best, and I hope for gaming's sake that innovation, fun, family, and gameplay once again become the core focus.

SDK tools?

[Red Flayer]

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.

Re:SDK tools?

[Anonymous Coward]

The PS3 devkit comes with Eclipse IDE, compilers, debuggers and import/export tools that handle most used sfx/gfx/muzak packages.

Even though the different API's are kept quite simple and relativly easy (compared to PS2) - I guess many developers choose to use one of the bundled frameworks/engines (comes with the kit for free but they have to be licenced if you use them to make your software).

Not entirely true

[PIPBoy3000]

This has been discussed on Evil Avatar for awhile now. It seems that for Oblivion at least, that statement isn't entirely true

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.

Re:Not entirely true

[drinkypoo]

Also, show me a processor that has as much power as three 3GHz 64 bit PPC processors...

Re:Not entirely true

[mnmn]

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"); is also valid. When you make developers do

#define _THREADY_APP_
_init_lib_threads();
_init_thread(THREADTYPE,THREADNICE,"thread",THREAD OPTIONS);
_enable_thread();
_execute_thread();
_clean_junk(); ..instead, youre asking them to just buy faster single cores to work with. Hence the sale of the Athlon FX-57 and P4 EE, rather than the latest Tyan Quad-cpu board.

Re:Not entirely true

[SScorpio]

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.

Re:Not entirely true

[Kayamon]

It's not just extremely hard to synchronize the various tasks - it's INCREDIBLY hard! At least the PS3 has the advantage that the separate threads run in separate address spaces, which actually means it's harder to get problems due to threads randomly accessing bits of memory. On PS3 you have to explicitly send data from each processor to another. On Xbox 360, it's pretty much a free-for-all, which means no end of debugging fun. Oh joy.

Re:Not entirely true

[jbert]

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 experience that isn't the main problem with threading. The main problem with threading is that by default *everything* is shared. All the dirty little global, file scope and static variables in all the little libraries your app loads to get things done. And any write access to such shared data by multiple threads without appropriate locking is quite likely to be a hard-to-reproduce-and-find fault waiting to happen.

But your new API doesn't make much sense to me. Your additional parameter to 'exec' isn't about threading, in that you've specified an exe name. If you're creating another thread, you'd be in the same exe as the one executing the call - thats a redundant parameter.

The nearest thing to what you suggest would be a new parameter to fork() which shared the VM between the two processes. Funnily enough thats pretty much what fork() is implemented on top of in Linux. Underneath it all there is a 'clone()' system call which is used to create a new execution context. The flags to clone() determine how much is shared between the parent and child. If you share VM, you get something close to a new thread, if you don't, you get something close to a new process.

[The 'something close' is in there to guard against any pedants pointing out that if you are so inclined you can specify odd combinations of CLONE_ flags and get some weird entities which don't correspond to traditional threads or processes.]

See 'man clone' on a Linux box for details of a library level clone function built on top of the clone syscall.

But on the face of it, using clone() to create a thread isn't too different from a plain pthread_create(). And that doesn't get you too far, because you then need some locking mechanisms. All of a sudden you're adding API for mutexes, semaphores, condition variables and all that guff. And then you're back with something as unpleasant as the pthreads API. Well actually, you're not. Because that API does suck pretty hard.

Basically threading is something which probably benefits from language-level support. Java (and I assume C# and probably others) have some of this. But that doesn't help game developers who I assume will be writing their performance critical code in something a bit closer to the metal.

Re:Not entirely true

[ObsessiveMathsFreak]

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 threaded application, and so programmers fall down when using them to make multi-threaded apps.

People keeps saying that programmers don't "grok" threads. I'd argue that programmers do "grok" thread, they just don't have a language that can deal with them appropriately. Just like people said that programmers didn't "grok" objects. Well, at the time, the most popular languages simply didn't have appropriate object support, so programmers simply didn't use objects.

My wet dream of course is a compiler that will examine my code written for single threads, and automagically seperated parallelisible processes into seperate thread. This obviously, isn't going to happen.

Re:Not entirely true

[digital.prion]

Interesting. I was just think about the same thing this morning which is a programming language designed from the ground up to be multi-threaded. Here's a few ideas, let's see if we can get some other intelligent folks to join in. ** Contracts I imagined having "contracts" much like C# has with interfaces. With a threaded "contract" code is checked at compile time instead of having runtime "gotchas". "Contracts" would prevent any piece of code from spawning a thread and those objects/functions that did spawn threads would have coinciding "contracts" for the object/thread being called. ** Intelligent IDE In Eclipse (not the best I know) there is a built in refactor. I can do all sorts of stuff like pull out a class, create stubs, infer generic types, convert anonymous to nested class and the like all with an automated process! Now imagine if the IDE could check a class for it's thread safety-ness(sp) all before compiling. All a programmer would have to do is highlight a section of code and select the TYPE of thread (1 processor/multi thread, Dual processor single thread,etc) and then the IDE would use game theory to adjust the classes members all on the fly! Possible? Ok that's just two, lol, but the whole emphasis is on: *Compile time, safety for threads *IDE on the fly thread contract correcting,regression and basic race condition checking *Intelligent compiler warnings regarding possible inappropriate thread usage *Thread Cases(?) - A restricted system of compile time thread safety where various *types* of threads have different access to other threads.. (private, public, protected) similar to classes. Prevents certain objects under this TYPE of thread from calling another TYPE of thread.. basically, more compile time safety *Thread hierarchy(?) a strict system of enforcing what threads and objects (within a given thread) can call or pass/share data with another thread and object in another thread. Helps the compiler know how to optimize and the programmer find tricky logic errors Ok that was wordy. Did it help to explain the vision I was having? Does this coincide with trends or ideas you had? Cheers!

Link

[BizInside]

http://igo.ampednews.com/platform/xbox360/news/281 9/
There's the correct link to that story.

sdk?

[dlockamy]

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 know they're fixed) and all yeah....And then there's still the complains from the industry of still using dvd instead of a bigger media.

Re:sdk?

[drinkypoo]

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 are different from one another, not counting the GS) and so on. So, people are not used to writing multithreaded games. On the Saturn, the second CPU was generally used for a single task, like handling transparency or water effects, which meant it was often underutilized. (Saturn had no HW transparency effect.)

Developers said

[thegamebiz]

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

[Kazriko]

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.

FALSE!!

[Saige]

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 articles here about how the Xbox 360 is powered by DEAD KITTENS...)

Re:FALSE!!

[Senzei]

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

Now that is just silly, PETA would be all over them for this. Microsoft instead makes the system about six months in advance with a fully healthy live kitten, seals the whole deal up, and lets quantum physics take care of the argument as to if the kitt^H^H^H^H xbox power source is alive or dead.

Re:FALSE!!

[Red Flayer]

"(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!

Re:FALSE!!

[dimfeld]

The event was the Fall Processor Forum, which just occurred. A Microsoft employee supposedly made this claim. Herb Sutter was the only Microsoft employee to give an official speech (it was the keynote), so it might have been him if it's true.

His speech was about multi-threading and things that he's been working on to create more transparent and easy-to-use multithreading. I'm not sure where you get can get the PDF of his presentation, but it was passed around where I work, and it was interesting stuff, involving parallelization even of things like individual loops, activated using nothing more than a bit of special compiler syntax.

Anyway, Herb is doing a lot of neat work on multi-threading, but he isn't in the Xbox division. So it's not as if he really would have first-hand knowledge of everything going on Xbox-related. Furthermore, statements like this have a tendency to be misheard. I wasn't there, but maybe he said that most of the first Xbox 360 games will be single-threaded, and that's probably true. But it's pretty easy for that "most" to change to an "all" as it passes from person to person and on to the Internet.

Re:FALSE!!

[Saige]

I still wonder if he was meaning to compare games from the first Xbox, which were all single threaded, to the Xbox 360 games. Read the article again with this in mind, and it looks like that may have been what was intended.

History repeats itself

[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

[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've been writing multi-threaded game code on my dual G5 for two years now. It took me maybe ten to fifteen minutes the day I got mine to look up how to spanw off a new thread in OS X and throw a huge chunk of code off in its own thread running on the second G5 chip resulting in a huge performance jump.

Not only have we been writing parallel/multi-threaded code, it just isn't an area of game development that is that interesting. My latest console game we spent about a half day moving code around to maximize parallelism. And then we got right back to working on the actual difficult stuff in making a modern console game.

The performance of the 360 has been shockingly underwhelming. The seemingly endless excuses about devkits or only using one core and so on indicate Microsoft knows they have really botched the 360 hardware and software tools. I am glad my company is skippng the 360 like we did with the Dreamcast.

The PS3 is an utter dream machine for game programmers. The hardware and tools kick ass. If you do graphics programming, you NEED to find some way to get your hands on one. I'm not saying break the law to get your hands on one, but I'd understand if you did...

Re:I've Worked On (almost)Every Console

[Anonymous Coward]

You were the chap that made Pong use multiple threads?

And now you're off to deliver us top-notch quality games on the PS3?

In a Game Development Studio not so far away, I call utter BullShit(^TM) ...

Re:I've Worked On (almost)Every Console

[Anonymous Coward]

The parent post is obviously lying; he claims to write games and have worked on most every console, yet he also says he uses a Mac...

That's a contradiction if ever there was one!

Re:I've Worked On (almost)Every Console

[Anonymous Coward]

Yes, after all why would a console programmer have any use with a PowerPC system?

Who uses PowerPC systems other than:

1) Sony
2) Nintendo - twice
3) Microsoft

Way to make yourself look like an idiot guy.

Re:I've Worked On (almost)Every Console

[Anonymous Coward]

I think I'll listen to John Carmack over some random anonymous game programmer, thank you very much.

Re:I've Worked On (almost)Every Console

[AlexMax2742]

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?

Single-Threaded? No way.

[Anonymous Coward]

I don't BUY this single-threaded games stuff at all. Almost every application you come across nowadays is multi-threaded. I think either there is some funny definition of threads being used here, or it's just a load of garbage.

Hmm.. this is the FA

[AzraelKans]

Dont bother clicking on the inquirer heres the entire article in full glory:

MICROSOFT'S VOLE DRAMA ARMY DROPPEDa bombshell today in a backhanded way.

During a talk on multithreaded programming, Microsoft used the three core, two thread per core Xbox360 as an example.

The bombshell was that the first generation of Xbox titles, all of them, are single threaded. Not good.

The INQ has gotten its hands on an Xbox360, yes, there is a Wal-Mart near us, and was completely underwhelmed by the quality of the games. Graphics quality was poor, and pixels were showing up blocky, ruining the wow-factor of the new console.

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.


Translation: We went to wall mart played the thing for 5 seconds then wrote an article based on that and 90% guessing, since the PS3 is also a hot item we speculated it will be worse. since well... Jeff from accounting say it will.

You know Zonk, next time you read "MICROSOFT'S VOLE DRAMA ARMY" as the source of the article, you probably shouldn't even read it, much less post it here.

Re:Hmm.. this is the FA

[Anonymous Coward]

The bombshell was that the first generation of Xbox titles, all of them, are single threaded. Not good.

First generation Xbox 360, or the first generation Xbox console?

That's a little bit of a difference, and from the statement here, it sounds more like the latter to me.

Sounds almost like this might be a misinterpretation that's gotten out of control...

Get Ready for Crappy Games

[Albigg]

Writing multi-threaded anything is hard. If developers have been used to designing and implementing single-threaded games, then there is going to be a serious learning curve. I'll take single-threaded games over crappy multi-threaded games with deadlocks. Actually I probably won't take either since I'm not going to get a 360 or PS3 for quite a while.

Re:Get Ready for Crappy Games

[Anonymous Coward]

SHUT UP!!!

What the fuck is wrong with you idiots???

I am so sicked by idiotic comments like yours I can't concentrate on work.

Everyone who is not a console engineer please STFU about the following topics:

1) Cores
2) Threads
3) How N cores is N times harder to program
4) Locks, semaphores
5) Java
6) What you heard some guy who makes pc games said
7) Complex interrelationships between various subsystems of game code

Please, for the mental health of console engineers just FUCKING STOP.

Re:Get Ready for Crappy Games

[Anonymous Coward]

Threading is a very common software development technique. I think it's safe to say that this topic is fair game and not just for experts.

I've seen the PS3 Instruction Architecture

[BeforeCoffee]

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. But the rewards will probably be much higher with the PS3. I read something about being able to drop code sequences onto a SPU stream for scheduling execution, I thought that was a nifty idea. There's all these nifty buses on the Cell processor, connecting SPU's, for data sharing. Complicated, but allows for sophisticated designs.

Re:I've seen the PS3 Instruction Architecture

[Anonymous Coward]

"Will it be harder to code PS3 for than the XBOX 360? Unless Sony does something amazing with their SDK, I would say yes. "

Idiot.

Give the 'hard to program' bullshit a rest.

Xbox fanboys tried that line for four straight years for naught.

Re:I've seen the PS3 Instruction Architecture

[r_benchley]

You sir, are a complete fucking moron. Based on your comments, it looks like you only read one goddamn sentence in the parent post. If you bothered reading the entire post, you would notice these little tidbits:

I think PS3 games are going to be a lot of fun to write code for - for bit fiddlers and premature optimization freaks.

And immediately following the part you quoted from the parent post:

But the rewards will probably be much higher with the PS3. I read something about being able to drop code sequences onto a SPU stream for scheduling execution, I thought that was a nifty idea. There's all these nifty buses on the Cell processor, connecting SPU's, for data sharing. Complicated, but allows for sophisticated designs.

The gist of the parent post is that although coding for the PS3 might require extra effort, it's completely worth it because the finished product will allow for superior results. The parent seemed stoked by the complexity of the PS3 development kit because any drawbacks that it might have are far outweighed by the advantages it offers.

Re:I've seen the PS3 Instruction Architecture

[Kayamon]

Um. Seeing as they'll be programming the SPUs in C, how does this matter?

Gabe Newell Called It

[TychoCelchuuu]

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.

Re:Gabe Newell Called It

[be-fan]

Not for long. The next generation of PC tech will rely heavily on multicore CPUs as well.

Worse Ps3

[sowdog81]

That means that even with an extra six months of design time, the initial PS3 games may be worse.

Doesn't mean the games will be less fun

Re:Worse Ps3

[Teemu Alviola]

Maybe by that time we will have NetBSD booting on the Xbox 360 :)

That's funny...

[nobodyman]

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.

Re:That's funny...

[Anonymous Coward]

Great, a fucking Id fanboy pipes in about console engineering...

Re:That's funny...

[pslam]

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?

Re:That's funny...

[jlarocco]

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.

Noooo... It's been well known for decades that 85-90% of time is spent in 5% of code. "Sony and friends" had nothing to do with coming up with that. They might have added DSP to the PS3 in response to it, but they certainly didn't "identify" it.

Re:That's funny...

[Troglodyt]

Argumentum ad hominem?

Brave New Software

[vga_init]

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.

Why?

[Corngood]

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.

Re:Why?

[Anonymous Coward]

"it can integrate with Visual Studio if you want. "

Uh, Eclipse. Why the fuck would someone willing use Visual Studio when they don't have to.

"ProDG gives them a good debugger (the PS2 one was, at least),"

I'm sorry, that is just an idiotic comment to make. You sound like you were one of those sad teams trying to do PS2 development with Visual Studio and the SN garbage. Fucking sad. The SN crap was bad like bad Windows shareware. This is the one area were Sony did blow it for tools. It's too bad they didn't bite the bullet and overcome the politics involved and gone with the gold standard Metrowerks console tools.

Re:Why?

[Red Flayer]

It was just a joke... there was a very vitriolic thread about IDEs on Wednesday evening.

Re:Why?

[Corngood]

I agree that the SN systems tools lack a certain amount of polish, so they stick out when compared to visual studio's compilers, debugger. They do, however, get the job done admirably. You can easily debug all 4 processors and the dma controller with the one tool, and I've never found that it's missing any critical features.

As for using visual studio, I hope that comment was why you were modded flamebait. Aside from the fact that some people just prefer it, it's possible to use it to build and debug a single project for Windows, Xbox, and all SN platforms. Why do I get the feeling that Eclipse wouldn't be quite as adept at working with the Xbox platform (feel free to prove me wrong)?

Holy shit, a coherent post!

[Corngood]

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.

It's called OpenMP...

[Corngood]

It's in all of microsoft's new C++ compilers, including xenon. Look it up.

PS3 is harder to program etc

[Anonymous Coward]

Didnt they say this about the PS2 vs PS1 and the then PS2 rivals?
Looks like Sony cares as much about its corporate customers as retail consumers.
You'd think almost going bankrupt + major restructuring they woulda learnt by now...

Odd

[SmallFurryCreature]

Sony's own games EQ2 and SWG both support multiple CPU's so whats the problem?

Then again isn't this always a problem with the release of new hardware both for PC and consoles? When you get that brand new graphics card or soundcard it takes some hard searching to find a game that actually supports its new features. At the time of the Matrox G400 it was only a handfull of games that supported bumpmapping.

The x-box is now of course obsolete. After all it is already a few years old and we know that is succesor is to be launched soon. So exactly why are top games still being developed for it? Wouldn't it have been smarter to say, okay six months before the launch of a new generation console we stop releasing games for the old and concentrate on making games for the new one. Especially with the x-box 360 wich can't run existing x-box games this would really help during launch.

I can only imagine that for developers working 3 years on a top game the vague launch date of a new generation console is not enough to bet their own launch date on. Would you really want your Jade empire to be delayed a year because the 360 is delayed a year?

Every console ever launched needed time to come to full bloom. I am personally only interested in handhelds and at launch none of them had, for me, must have titles. The DS or PSP choice is not yet made for me as neither has a game I must have.

On the PC it is the same, when windows 95 hit many a game still had to run in dos mode. XP was not immidiatly supported as I am sure neither will Vista be.

As for the whole multi-threading bit, any big game has had to have been in production well before test units were around so they would have to have been developed on "normal" pc's. Multi-threading I am told by real programmers is a very different beast on different pieces of hardware so wouldn't it be sensible for a game developed mostly on non-existent hardware to be conservative in its reliance on hardware features? You wouldn't want to make a top game and then only find out that "shock and horror" a new consoles hardware doesn't live up to claims made by its creator?

As for the PS3 being harder to develop for then the X-box 360. Wasn't the same said about the PS2 vs the x-box? /me looks at PS2 vs X-box sales figures. Riiiight.

Re:Odd

[BenjyD]

Developers still release games for 'obsolete' consoles because of their large installed base. Old consoles don't cease to exist just because their succesor is released.

I'm not saying Carmack is wrong...

[cgenman]

...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.

Inquirer = idiot

[SilentChris]

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.

Re:Inquirer = idiot

[Kayamon]

CRTs actually look less blocky than HDTV, due to the extra gaussian blur. True.

Re:Inquirer = idiot

[kcb93x]

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 make sure that I couldn't see the pixels at least, but apparently not. That or Wal-Mart picked the HD displays to use, but I doubt that.

Re:Inquirer = idiot

[mink]

I'm confused.
CRT=Cathode Ray tube
HDTV=Hi Definition TV

A CRT is a display type, Front/rear Projection or Direct View.LCD and Plasma are it's brothers at the base level of how an image gets to your eyes.

HDTV is something that all display types can be designed to do, there are HDTV CRT as well as Plasma and LCD.

I am not understanding how it can be said that a technology is comparable to a sub feature of the technology?

Re:Inquirer = idiot

[mink]

"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."

Huh, there have been CRT HDTV displays for years. Am I missing something in the way you people are using the terminology?

Reason for this article

[king-manic]

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.

Xbox 360 rush to market is very important

[Morgaine]

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 state. People will complain a little, but they'll still buy it, especially over Xmas.

Use the right methodology, Luke!

[Morgaine]

It's not just extremely hard to synchronize the various tasks - it's INCREDIBLY hard!

I know where you're coming from, and yes, it can be incredibly hard. However, this applies only when people use the WRONG methodology, ie. the one that they learned for single-task programming. Unfortunately, that's 99% of programmers, and therein lies the problem.

Let me give you a trivial little example to show that the difficulty is not inherent: any newbie programmer can create a long pipeline of Unix filters and run it with total success on a multi-CPU and hyperthreaded big-iron box with not a hint of race conditions, deadlocks, or data corruption. It's not because they're highly competent, but because the framework of Unix pipes hides all the necessary synchronization.

And it's just the same with multi-core games consoles. Of course, a simple pipe abstraction won't be enough there. The programming framework will require client-safe job queues, free process pools, task schedulers with variable policies, a routed and prioritized messaging system, and a whole host of internally-synchronized communication methods. And all of this infrastructure must hide the complexities of concurrency and multiprocessing behind opaque interfaces, so that people without a PhD in concurrency nor equivalent experience can still use them safely.

It's not actually hard at all given the right framework. But it's pretty close to impossible to build a reliably working product when concurrent programming is done in an ad hoc fashion.

Not true

[Anonymous Coward]

This is quite not true. I work for EA (choose now: treat me as downtrodden abused worker, or as member of global conspiracy?) and all the Xbox360 sports launch titles are using multi-threading to some degree.

Admittedly, some are using it more than others -- not every game is using 6 threads, that's for sure. But they're definitely far from single-threaded.

I'm sure the second wave of X360 titles will more expansively make use of the multiple threads. Obviously I can't speak for other companies, but EA's games aren't single-threaded.

Sorry to post anonymously, but you probably would too in my position.

Re:Not true

[Saige]

Sorry to post anonymously, but you probably would too in my position.

Considering your company can't even FOLLOW THE DAMN DOCUMENTED PROTOCOLS when dealing with Xbox Live, I'd be embarassed to admit working for such a company too. And yes, I know this to be the case, after bitching to someone about Burnout Revenge not being able to show my friends list on Live properly after the recent upgrade.

EA = Entirely Adequate.

Theadz

[digital.prion]

Is it just me or are threads the new pointers?

Thread safty solution

[digital.prion]

Interesting.

I was just think about the same thing this morning which is a programming language designed from the ground up to be multi-threaded.

Here's a few ideas, let's see if we can get some other intelligent folks to join in.

** Contracts
I imagined having "contracts" much like C# has with interfaces. With a threaded "contract" code is checked at compile time instead of having runtime "gotchas".
"Contracts" would prevent any piece of code from spawning a thread and those objects/functions that did spawn threads would have coinciding "contracts" for the object/thread being called.

** Intelligent IDE
In Eclipse (not the best I know) there is a built in refactor. I can do all sorts of stuff like pull out a class, create stubs, infer generic types, convert anonymous to nested class and the like all with an automated process!
Now imagine if the IDE could check a class for it's thread safety-ness(sp) all before compiling. All a programmer would have to do is highlight a section of code and select the TYPE of thread (1 processor/multi thread, Dual processor single thread,etc) and then the IDE would use game theory to adjust the classes members all on the fly! Possible?

Ok that's just two, lol, but the whole emphasis is on:


*Compile time, safety for threads

*IDE on the fly thread contract correcting,regression and basic race condition checking

*Intelligent compiler warnings regarding possible inappropriate thread usage

*Thread Cases(?) - A restricted system of compile time thread safety where various *types* of threads have different access to other threads.. (private, public, protected) similar to classes. Prevents certain objects under this TYPE of thread from calling another TYPE of thread.. basically, more compile time safety

*Thread hierarchy(?) a strict system of enforcing what threads and objects (within a given thread) can call or pass/share data with another thread and object in another thread. Helps the compiler know how to optimize and the programmer find tricky logic errors


Ok that was wordy. Did it help to explain the vision I was having? Does this coincide with trends or ideas you had?

Cheers!

Re:Thread safty solution

[Anonymous Coward]

I think it's called Erlang.

Wrong!

[mister_slim]

Dead kittens have very little potential energy. As MS is well aware, only extracting the souls of live kittens provides the power the 360 needs.

Admittedly, Nintendo is busy replacing dogs with virtual pets, as puppy souls provide even more juice.

Re:How can it get worse? THIS WAY!

[Anonymous Coward]

THREADBARE!