Well, I fully expected you'd strongly disagree, but trust me, in few years time you'd change your mind, because, guess what, I used to share the same opinion that you so well try to defend here. Maybe I'm getting old or lazy or both, but needless to say, the days when I enjoyed wrestling with the hardware are gone. I clearly remember being so happy manually optimizing my VU asm loops, to extract every last cycle. I still get a glimpse of that on SPUs and it's great and then I'm reminded how I have a giant pile of actual features that I need to finish, and that even if my code runs 2x faster on the SPU, nobody will ever notice. At the end some artist just needs to place few more "boxes" in the level and my efforts are wiped.
Its my belief that the culprit was Rockstar being overly ambitious with its title.
GTA has never been a visually pleasing title, usually forgoing the visuals and offering tons of content with a great storyline added in to produce a great game.
However, with the trailers it seems Rockstar wanted to offer all the great content and huge locale without sacrificing visuals at all.
Simply, I think Rockstar bit off more than it could chew and thus could not meet the release date.
Seems to me that this thread has confirmed what many cross platform developers have been saying. The extra worked required on the PS3 is fine for 1st party developers who can specifically bring people in to sort out specific problems (especially if the project is being bank rolled by SONY). But many 3rd parties will not have this facility due to budget, time and constraints that working on cross platforms puts on them. Seems to me 1st party developers probably don't realise the problems that cross party developent causes and even taking 3-4 weeks out to sort certain PS3 issues are time and more importantly cost factor that they can ill afford.
Maybe you haven't carefully read my words, I was talking about a multiplatforms game, the abstracation layer runs on 3 different platforms.After all nAo's team only implemented it on one platform.
Emh..why do you think you can't use STL on SPUs?A truly well developed abstraction proves itself when you test it against a second platform.
Second, on the topic of junior programmers - yes, they could write O(N*N) algorithms and no optimization can fix this, but they can also easily take advantage of STL/Boost or similar high level abstractions and will get O(logN) with no sweat. Tell me how would one leverage 10+ years of experience and C++ template power on an SPU?
Even kids know that auto-vectorizing compilers are a dead end.I clearly remember a discussion few years ago about IBM's XL compiler and their auto-parallelizing auto-vectorizing efforts
You keep saying that programming on a SPU is so complicated but you completely failed to show why, every time I ask you a question you just skip it and it disappears in the following reply.What is better : people not using SPUs because programing them is too complicated, or using all of them all the time at 50% efficiency?
Intel is not exactly pushing C or C++ as programming language for Larrabee so I fail to see your point here.Looking at Intel's Larrabee effort, it seems to me, Intel seems to agree that if you throw 64 cores at programmers,
they will definitely screw it up, so some of the complexity needs to be taken away, even at the cost of performance loss (from the point of view of one of these cores).
There isn't enough information to stick it to a platform IMO.
It's not about having a lead platform (PS3 or 360 ), is about writing code keeping PS3 in mind, cause it's the platform that requires special care as its programming model diverges from the the <common path> , even though it's not requiring you to do any crazy thing.This thread often repeats a common fallacy: that if you write for the PS3 first, then port to Xbox 360, you'll suddenly have zero problems. This is not true. Developing for the PS3 first is still going to be much, much harder than using Xbox 360 as a lead; it's just that the porting in that direction will be easier (or, possible at all).
I guess this is like the RS story..everyone heard multiple versions of it (at least I did..)There is actually...we just aren't supposed to talk about it publicly
I really don't get why a lot of devs metaphorically scream and run away just hearing the word SPU (especially when they don't know much about it..)
I'm glad I'm not the only one living on *this* planet.Cell, at least to me, is not the problem. I have no problem writing multithreaded code whatever the cpu design. Writing game logic to run on spu's is easy to me
Well..it doesn't really come as a surprise as no one would expect a single core (PPU) to match 3 cores, even when only one is used devoted to the renderer (and the other cores are probably working on something else)FYI, the only hard part of spu coding comes when you need to hook it to your render pipeline. That part gets very tricky. And I don't believe what anyone says here, if you max out Xenos, you *will* have to use spu's as part of the render pipeline to match it, plain and simple.
There is actually...we just aren't supposed to talk about it publicly
What confuses me Joker454 is how ratchet and clank which only uses the RSX for its graphics seems to contradict your argument.
You have either completely failed to understand what joker454 has been trying to say for the past few pages or so, or have seen a 360 version of Ratchet and Clank.
Same story for HSHowever as far as I know motorstorm, ratchet and clank (not sure about heavenly sword) all 'just' use the RSX.
It's just easier to reach peak performance on Xenos, moreover an unified ALUs GPU is very good at automatically fix certain art/contnet problems (too dense meshes for example, missing LODs, etc..)Is it that multiplatform devs find using GDDR and XDR for GPU that much difficult than the combined memory aproach of the XBOX 360?