Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

First-Gen Xbox 360 Games Single-Threaded?

Zonk posted about 9 years ago | from the crying-shame dept.

XBox (Games) 158

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

Sorry! There are no comments related to the filter you selected.

Most video games are single threaded (2, Insightful)

AuMatar (183847) | about 9 years ago | (#13892411)

Multi-threading doesn't actually buy you much with video games, not much can be done in parallel. About all you could do with it is run AI on a separate thread. That'd buy you an advantage for strategy games, but not much for anything else (where AI is light). Look at performance testing of games on multicore chips- they don't outperform single cores.

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

Anonymous Coward | about 9 years ago | (#13892433)

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 (1)

Vaevictis666 (680137) | about 9 years ago | (#13892489)

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 (1)

qbwiz (87077) | about 9 years ago | (#13892693)

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 (1)

bluGill (862) | about 9 years ago | (#13892906)

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 (1)

alan_dershowitz (586542) | about 9 years ago | (#13894069)

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 (1)

applecrumble (910692) | about 9 years ago | (#13892498)

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 (1)

Tim Browse (9263) | about 9 years ago | (#13893236)

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 (1)

mc6809e (214243) | about 9 years ago | (#13892586)

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 (4, Insightful)

AuMatar (183847) | about 9 years ago | (#13892687)

Threading only makes sense if one of three conditions is true- either it allows you to do complex calculations early, a condition needs rapid handling, or the task is truely massive but can be handled with low communication by multiple threads. Very few things in games follow one of these.

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

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

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

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

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

Now client server games are another matter- I'm sure MMO servers have multiple threads going. But notice how different that use case is- multiple loosely coupled computations, vs few highly coupled ones. ANd no rendering thread that basicly needs to know everything at all times.

Re:Most video games are single threaded (1)

NitsujTPU (19263) | about 9 years ago | (#13893104)

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 (1)

AuMatar (183847) | about 9 years ago | (#13893154)

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 (2, Insightful)

lividdr (775594) | about 9 years ago | (#13892608)

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 (1)

NitsujTPU (19263) | about 9 years ago | (#13893052)

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 (1)

AuMatar (183847) | about 9 years ago | (#13893186)

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 (1)

NitsujTPU (19263) | about 9 years ago | (#13893417)

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 (1)

NitsujTPU (19263) | about 9 years ago | (#13893442)

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 (1)

PGC (880972) | about 9 years ago | (#13893929)

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.

Surely this isn't true (2, Insightful)

applecrumble (910692) | about 9 years ago | (#13892446)

What the hell? Not a single XBox 360 programmer can work out how to create new threads and identify at least some processes that are not dependent one each other? That sounds like complete nonsense to me. There are plenty of easy ways to separate your level setup, game logic, sound processing, graphics, AI, physics etc. into different threads. I'm not saying taking full advantage of all cores is easy, but the idea that none of the game developers have the ability to use more than one thread is stupid.

Re:Surely this isn't true (2, Interesting)

Reality Master 201 (578873) | about 9 years ago | (#13892528)

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 (2, Interesting)

radish (98371) | about 9 years ago | (#13892880)

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 (1)

Reality Master 201 (578873) | about 9 years ago | (#13892916)

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 (-1, Troll)

Anonymous Coward | about 9 years ago | (#13893010)

Stop.

Just FUCKING stop.

I don't know why the fuck it has become hip to "be scared for teh scarry new world of multi-threaded game development no matter what anyone says cuz I know it is true"

Please shut the fuck up about a topic you clearly:

1) You clearly have no fucking clue about
2) No real life console developer, outside of dopes from Id and Valve, have problems with

Re:Surely this isn't true (1)

bluGill (862) | about 9 years ago | (#13892995)

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 (1)

AuMatar (183847) | about 9 years ago | (#13893058)

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 (1)

radish (98371) | about 9 years ago | (#13893374)

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 (1)

AuMatar (183847) | about 9 years ago | (#13893422)

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 (1, Informative)

AuMatar (183847) | about 9 years ago | (#13893032)

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 (0)

Anonymous Coward | about 9 years ago | (#13893184)

// 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 (1)

AuMatar (183847) | about 9 years ago | (#13893230)

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 (1)

radish (98371) | about 9 years ago | (#13893352)

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 (0)

Anonymous Coward | about 9 years ago | (#13893675)

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 (1)

forkazoo (138186) | about 9 years ago | (#13893152)

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 (0)

xgamer04 (248962) | about 9 years ago | (#13892681)

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

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

Anonymous Coward | about 9 years ago | (#13892874)

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 (2, Insightful)

Anonymous Coward | about 9 years ago | (#13893063)

YallaYalla ...

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

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

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

YallaYalla

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

Tim Browse (9263) | about 9 years ago | (#13893327)

Of course it's not true.

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

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

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

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

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

I know which I'd choose.

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

How can it get worse? (5, Funny)

Qzukk (229616) | about 9 years ago | (#13892490)

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

Gottjager (17214) | about 9 years ago | (#13892684)

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

Re:How can it get worse? (0)

Anonymous Coward | about 9 years ago | (#13893640)

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? (2, Interesting)

Ayaress (662020) | about 9 years ago | (#13892748)

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

Breakfast Pants (323698) | about 9 years ago | (#13893530)

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

Not too surprising (3, Insightful)

dividedsky319 (907852) | about 9 years ago | (#13892501)

It seems like a lot of the things dealing with the Xbox360 have been rushed... I mean, here it is less than a month before it's released and I still don't think there's a 100% accurate list of games that will be available on the day of release.

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

This always seems to happen with systems, though... games coming out later in the system's lifespan look a lot nicer than games early on. As they use the SDK more they'll learn tricks to make things run and look better.

Re:Not too surprising (4, Insightful)

xgamer04 (248962) | about 9 years ago | (#13892735)

This seems like the easiest place to cut corners.

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

Re:Not too surprising (1)

L0k11 (617726) | about 9 years ago | (#13893141)

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 (1)

ClamIAm (926466) | about 9 years ago | (#13893537)

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 (0)

Anonymous Coward | about 9 years ago | (#13894341)

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.

Middleware (2, Interesting)

Admiral Ackbar 8 (848624) | about 9 years ago | (#13892502)

The middleware they all use probably isn't there yet. Once it is I think you will see more multi-threading.

All I know is that doing it on you own is very challenging and adds so much complexity (race conditions and locking to name a few) that it's probably not worth the effort. Really all these systems need for great graphics is a kick butt graphics card!

Cutting edge stuff! (1)

chobee (555901) | about 9 years ago | (#13892504)

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

Re:Cutting edge stuff! (1)

X0563511 (793323) | about 9 years ago | (#13892689)

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

Re:Cutting edge stuff! (1)

xgamer04 (248962) | about 9 years ago | (#13892780)

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! (2, Informative)

Yocto Yotta (840665) | about 9 years ago | (#13892881)

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

No surprise (1)

DavidLeblond (267211) | about 9 years ago | (#13892532)

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

I call bullshit. (-1, Flamebait)

Anonymous Coward | about 9 years ago | (#13892560)

Don't ask how I know. They don't know what they're talking about.

'everyone' tells you, do they? (0, Troll)

Xarius (691264) | about 9 years ago | (#13892580)

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? (2, Informative)

Rayonic (462789) | about 9 years ago | (#13892908)

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? (2, Insightful)

oGMo (379) | about 9 years ago | (#13893068)

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

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

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

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 (4, Interesting)

nevergleam (900375) | about 9 years ago | (#13892587)

I'm suddenly reminded of that Anandtech article from a couple months back about how developers were:

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

It was pulled pretty quickly, and the story is that the article was pulled to protect the anonymous source.

Re:Sounds familiar (1)

Saige (53303) | about 9 years ago | (#13892763)

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 (0)

Anonymous Coward | about 9 years ago | (#13894258)

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

Re:Sounds familiar (0)

Anonymous Coward | about 9 years ago | (#13892776)

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.

SDK tools? (3, Funny)

Red Flayer (890720) | about 9 years ago | (#13892678)

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.

Why? (1)

Corngood (736783) | about 9 years ago | (#13894223)

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? (0, Flamebait)

Anonymous Coward | about 9 years ago | (#13894288)

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

Not entirely true (4, Interesting)

PIPBoy3000 (619296) | about 9 years ago | (#13892690)

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

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

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

The developer's dream is a single processor console that has a very fast CPU. Unfortunately that's hard to manufacture, so they're stuck with something less than ideal that can be made cheaply with today's technology.

Re:Not entirely true (1)

drinkypoo (153816) | about 9 years ago | (#13893225)

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

Re:Not entirely true (1)

SScorpio (595836) | about 9 years ago | (#13893394)

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 (1)

mnmn (145599) | about 9 years ago | (#13893389)

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.

sdk? (1)

dlockamy (597001) | about 9 years ago | (#13892701)

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

drinkypoo (153816) | about 9 years ago | (#13893300)

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

It's called OpenMP... (1, Insightful)

Corngood (736783) | about 9 years ago | (#13894254)

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

Developers said (2, Interesting)

thegamebiz (925741) | about 9 years ago | (#13892723)

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 (2, Insightful)

Kazriko (526976) | about 9 years ago | (#13893307)

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

Symmetric multiprocessing was tried before as well, back on the Sega Saturn. It wasn't nearly as successful.

Holy shit, a coherent post! (1)

Corngood (736783) | about 9 years ago | (#13894242)

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.

FALSE!! (1)

Saige (53303) | about 9 years ago | (#13892814)

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!! (1)

Senzei (791599) | about 9 years ago | (#13892994)

(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!! (1)

Red Flayer (890720) | about 9 years ago | (#13893312)

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

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

History repeats itself (1, Interesting)

Anonymous Coward | about 9 years ago | (#13892858)

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 (2, Interesting)

Anonymous Coward | about 9 years ago | (#13892870)

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 (0)

Anonymous Coward | about 9 years ago | (#13893368)

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 (0)

Anonymous Coward | about 9 years ago | (#13893758)

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 (0)

Anonymous Coward | about 9 years ago | (#13893816)

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.

That's funny... (4, Insightful)

nobodyman (90587) | about 9 years ago | (#13894059)


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


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

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

Re:That's funny... (0)

Anonymous Coward | about 9 years ago | (#13894066)

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

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

Anonymous Coward | about 9 years ago | (#13894190)

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

Single-Threaded? No way. (0)

Anonymous Coward | about 9 years ago | (#13892975)

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 (0, Troll)

AzraelKans (697974) | about 9 years ago | (#13892986)

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 (0)

Anonymous Coward | about 9 years ago | (#13893215)

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

Total Crap (-1, Redundant)

Anonymous Coward | about 9 years ago | (#13893005)

This is actually total crap. The opposite is, in fact, true. Every single game on the Xbox 360 will be multi-threaded. The system is very inteligent about what it does for you. For example, if you are sampling an audio source, and you take callbacks to do post-processing effects, or run a DFT on that sound data or whatever...you are running in a different thread. Direct3D...different thread. There is a lot more that goes on with the multi-threading but the problem with reading articles like this one and being under NDA is...you're under NDA. Our title, on a total crunch schedule, is using 3 threads...and that functionality was coded from scratch, not pre-existing. Throw all the files you want to load into a priority queue, have a read-thread sit there and read data off the disc, and change status to awaiting decompression. Have a decompress thread working on that queue of files. There, you have a multi-threaded game.

What the story *may* have meant to say is that no first generation Xbox360 titles will make full use of the multithreading tools and functionality available. Well no shit. Why is this news?

Get Ready for Crappy Games (1)

Albigg (658831) | about 9 years ago | (#13893259)

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 (0)

Anonymous Coward | about 9 years ago | (#13893315)

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 (0)

Anonymous Coward | about 9 years ago | (#13894096)

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 (2, Interesting)

BeforeCoffee (519489) | about 9 years ago | (#13893473)

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 (0)

Anonymous Coward | about 9 years ago | (#13893523)

"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 (1)

r_benchley (658776) | about 9 years ago | (#13893712)

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.

Gabe Newell Called It (1)

TychoCelchuuu (835690) | about 9 years ago | (#13893939)

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.

Worse Ps3 (1)

sowdog81 (739008) | about 9 years ago | (#13893984)

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

Brave New Software (2, Insightful)

vga_init (589198) | about 9 years ago | (#13894127)

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.

PS3 is harder to program etc (0)

Anonymous Coward | about 9 years ago | (#13894256)

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...
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?