*Game Development Issues*

Status
Not open for further replies.
GTA 4 has a complexity that'd explain the delay on its own... no need to make this a platform related issue.
 
I thought the first trailer was a bit of a mixed bag. Some parts looked kinda bad... others better. There isn't enough information to stick it to a platform IMO.

But... what's up with all the PS3 UE3.0 games being delayed from Midway for instance?
 
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.

I'm not going to compare PS3 and 360, I have my opinions.

I tend to agree with this statement. I love it when I get an opportunity to bang bits, write asssembly language, count cycles and do all those cool micro optimisations.

But most days I'm trying to work out which checkin yesterday screwed the game up today, trying to get features off my plate and stay on top of the 100's (no I'm not exagerating) of checkins other people are making a day.

Give me a small team and time and I'll go back to the way things used to be, but that's become a hard sell as of late, the reality on larger teams, is that few things are optimal unless it's a necessity.
 
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.

I was thinking something similar, I mean all of the 3d GTAs:

GTA III, GTAVC and GTASA were all programmed first on PS2 and it wasn't until some years that GTAIII/VC got ported to XBox and GTASA was ported or released about 9 months after the PS2 version.

GTA stories that were ported from PSP were never ported to XBox or XBox 360.

Then Rockstar/TTI all of a sudden feel they can pull off both a PS3 and XBox 360 version of GTA4 at or around the same time as implied by all of the deals going on.

I can't help feel and wonder if Rockstar/TTI would have just chosen to make a PS3 version first or only as a focused effort, if they would have had the same problems that are being alleged.
 
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.
 
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.

Sure for now..

In the end however sales will pick up and the install base will grow.. & by the time the platform has a large enough following to make it viable to most/all publishers/titles, code bases will be mature enough to accommodate safe, *relatively*-painless development..

To be honest I see most of these issues as teething problems since you only ever *really* need to build one relatively good game engine for the platform.. Your definitely not going to run into the same issues the second/third/forth time around, first/second/third party or not..
 
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).

To make up some arbitrary figures, on a 1-10 difficulty scale, if developing for the Xbox360 first is 1 and porting afterwards to PS3 is 10, developing for the PS3 first is not another 1, but rather 7-8; then the porting cost back to the Xbox360 is not 1, but something like 5-6.

As about nAo's suggestion, I've had the dubious pleasure of a "job/task abstraction layer threwn together by several very smart people over the course of several weeks" - just to make the game run on the PS3. It made the entire codebase a mess, it made the PC and 360 versions considerably less efficient, and it has received at least one major overhaul since then.

And the original game for which it was conceived still ran like a dog on the PS3, and had to be cut in all ways possible, from graphical to AI. Granted, this was a first-generation title, but the team behind it is stellar, with many console titles under their belts.
 
After all nAo's team only implemented it on one platform.
Maybe you haven't carefully read my words, I was talking about a multiplatforms game, the abstracation layer runs on 3 different platforms.

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?
Emh..why do you think you can't use STL on SPUs?
And BTW..going back to your previous message, you complained about not being able to fit some code + debug symbols on a SPU.
Well..I'd like to tell you a story about a game that compiled with symbols and without optimizations doesn't fit on a certain console devkit cause some smartass decided that having a devkit
with the same amount of memory of a retail unit was a good decision.

I clearly remember a discussion few years ago about IBM's XL compiler and their auto-parallelizing auto-vectorizing efforts
Even kids know that auto-vectorizing compilers are a dead end.

What is better : people not using SPUs because programing them is too complicated, or using all of them all the time at 50% efficiency?
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.
According to you ppl can't use STL on SPUs or they need a master to put a breakpoint in the code or a PhD to do a dma transfer.

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).
Intel is not exactly pushing C or C++ as programming language for Larrabee so I fail to see your point here.

BTW...about the messsage you posted and deleted: at E32005 HS was not playable, PS3 devkits were not even around at that time.
 
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).
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.
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..)
If your job is to write a game that runs on 2 platforms but you design your code in a way that runs well on just one of the 2 SKUs then you've failed.
We are talking about multiplatform games here, games that most of the times are not going to be super optimized on each platform anyway.
 
Last edited:
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..)

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. Our lead wrote a very thin layer on top of spurs and we use that, simple. It's made even simpler by the fact that games this generation don't need that much cpu to begin with. In most cases games will be tried and true designs with typical cpu use expectations, partly for reasons like exploding costs which make taking risks on new types of games on these platforms simply not work gambling millions on. We would sooner gamble a new game design on the Wii that we would on PS3.

All this talk of spu this and spu that is just a smokescreen to hide what the real problem is, which to me is and has always been RSX. Getting a gpu that in some respects represents a 4+ year old design to match up with a relatively modern GPU like Xenos is not easy. As I've said before if you aren't multiplatform, you probably won't care. If you started on 360, then that product has set your baseline and you must match it. Newer titles will probably take the easier approach of just getting RSX to render it first, then match that on Xenos. Yup, the 360 build will probably have ununsed memory in that case, and Xenos will probably not be used to it's full potential since it keeping up with RSX is damn simple. But ironically, that scenario (a partly idling 360) is what would make all clients most happy since they won't know any better.

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.
 
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
I'm glad I'm not the only one living on *this* planet.
Said that I won't get again into the RSX debate as me and you already discussed the matter..
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.
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)
 
There is actually...we just aren't supposed to talk about it publicly ;)

You know what I meant then. :p Does that mean you/other dev houses have been in contact with R*? Are they seeking help or something? ;)

At any rate, they have extra time to polish things. :)
 
What confuses me Joker454 is how ratchet and clank which only uses the RSX for its graphics seems to contradict your argument.

I'm not saying that either GPU has its advantages and disadvantages but first party games seem to be showing some top draw graphics at a decent frame rate.
 
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.
 
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.

Perhaps not. Where is Insomniac using SPUs (in some non-standard or exotic manner) to get decent performance out of RSX?

Would you not say R & C would push Xenos? If not, how so?

----

In any case wouldn't it be a more valuable discussion to talk about potential solutions to problems than the hardware given the hardware is fixed and there is no way to change it now?
 
No I understand that he (his company) are having issues with the PS3, and that he (his company) are having a harder time with it than the 360. I can understand this from a Cell point of view.

However since the RSX is a known quantity (at least to devs) as its an Nvdia based GPU, it confuses me how Joker is seeming to point to the RSX being the weak link, when if insomniac can do ratchet and clank level of graphics on the RSX (which is a known quantity) where is the inherint weakness, i.e. surely the raw power of the diffrent graphics output (traingles, shaders, AA etc) must be available to all partys without the need for 1st, 2cnd party know how.

If all 1st and 2cnd party games were doing Killzone 2 like graphics (i.e. hevaily using both SPE's and GPU) then I would except his comments as read. However as far as I know motorstorm, ratchet and clank (not sure about heavenly sword) all 'just' use the RSX.

Joker seems to be implying that to get as good graphics as the XBox 360 SPE's need to be used. However as originally stated first party games seem to belie this statment. This is what I don't understand.

Is it that multiplatform devs find using GDDR and XDR for GPU that much difficult than the combined memory aproach of the XBOX 360?
 
However as far as I know motorstorm, ratchet and clank (not sure about heavenly sword) all 'just' use the RSX.
Same story for HS
Is it that multiplatform devs find using GDDR and XDR for GPU that much difficult than the combined memory aproach of the XBOX 360?
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..)
 
From a gamers perspective the games look equally great on both platforms (minus a few bad PS3 ports). It was known on these forums before the PS3 was even released that it would be a wash performance wise between the 2 consoles. It could be argued that COD4 is at the peak of graphics performance on the 2 machines (for now) and from everything I read looks nearly 100% identical. As a PS3 owner I wish the PS3 had more graphics performance than the 360... but to be honest it does not really matter. I bought the system for the exclusives (MGS4, FFXIII, etc.) and would have bought a PS3 even if it had been the weaker of the 2 systems.
 
Status
Not open for further replies.
Back
Top