Slashdot Mirror
The Technical Difficulty In Porting a PS3 Game To the PS4
An anonymous reader writes "The Last of Us was one of the last major projects for the PlayStation 3. The code optimization done by development studio Naughty Dog was a real technical achievement — making graphics look modern and impressive on a 7-year-old piece of hardware. Now, they're in the process of porting it to the much more capable PS4, which will end up being a technical accomplishment in its own right. Creative director Neil Druckmann said, 'Just getting an image onscreen, even an inferior one with the shadows broken, lighting broken and with it crashing every 30 seconds that took a long time. These engineers are some of the best in the industry and they optimized the game so much for the PS3's SPUs specifically. It was optimized on a binary level, but after shifting those things over [to PS4] you have to go back to the high level, make sure the [game] systems are intact, and optimize it again. I can't describe how difficult a task that is. And once it's running well, you're running the [versions] side by side to make sure you didn't screw something up in the process, like physics being slightly off, which throws the game off, or lighting being shifted and all of a sudden it's a drastically different look. That's not 'improved' any more; that's different. We want to stay faithful while being better.'"
You realize the PS3's hardware WAS exotic right? That's exactly why it's hard! Write code optimized for multiple SPE units, and see how well you can get it to run on x86.
The PS4 is x86, the PS3... not so much.
Anything assembler-level optimized for the cell architecture would be absolute hell to port.
I'm super stoked about this game! Never had a os3 so I missed out on it before.
That is what you get if try to lock-in customers into a restricted platform. What about all those games consumers bought for their ps3 that are now obsolete.
Mainly because the PS3 was a radically different architecture, and when the company had to do assembler-level optimisations to get the game working well, and now they're trying to recode those optimisations for x86, while ensuring the shaders, physics, lighting etc all work perfectly, it's an impressive project.
I don't know about that. Sometimes there is an inherent trade-off between being machine-friendly and human-maintainer-friendly. Tuning for machine performance sometimes gets in the way of high-level abstractions that make porting to a different architecture easier.
Reminds me a bit of the Story of Mel:
http://www.cs.utah.edu/~elb/fo...
Table-ized A.I.
That's easy! I wouldn't try to run SPE units code on x86 but x86 code on x86. The "optimization" shouldn't have affected the Game or it's portability and that's why it's their own damn fault.
Optimized PS3 code is not what you think it is. Its not taking some general C code and rewriting it a bit to be friendlier to the underlying CPU architecture or rewriting it completely in assembly. The PS3's Cell processor is, in simplified terms, a general purpose CPU and six special purpose coprocessors. So optimization is really figuring out how to pull major pieces of code out of the general purpose and move it to the appropriate specialized coprocessor, and then add the control code necessary to coordinate the two. Or to put it even more simply, optimizing for the PS3's cell processor is really an exercise in parallelizing code 7 ways.
Mainly because the PS3 was a radically different architecture, and when the company had to do assembler-level optimisations to get the game working well, and now they're trying to recode those optimisations for x86, while ensuring the shaders, physics, lighting etc all work perfectly, it's an impressive project.
Its not about assembly code, this mischaracterizes the problem.
Optimizing for the PS3's Cell architecture is not simply rewriting some critical code in assembly. Its more of a parallel processing effort. To greatly simplify things the Cell has a general purpose CPU and six specialized coprocessors. The trick to Cell optimization is moving code from the CPU to the coprocessors and keeping those coprocessors as busy as possible. Now add the complication that the coprocessors are not interchangeable.
Assembly has little to do with it. Its architecting the code to keep 7 parallel processors going, whether the underlying code that implements this software architecture is C or assembly doesn't matter a whole lot.
You realize the PS3's hardware WAS exotic right? That's exactly why it's hard! Write code optimized for multiple SPE units, and see how well you can get it to run on x86.
There's actually some validity to the GP's post.
Ideally, you would write the game portably, knowing that you will need to potentially take it to market on a lot of platforms, if it ends up being a popular title, and so as a result, you'd have a minimal porting set that could just be compiled and run, with additional optimizations on top of that tuned for the platform on which it's going to run.
Although not done a lot recently, the implementation of the original libc had C versions for all the code contained therein, and then had hand optimized assembly versions that would replace the C versions on a specific platform.
The intent was to be able to get it up and running on a new platform fairly quickly by having a small *required* assembly language footprint in the context switch, bootstrap, and CRT0 code, and then optimize the C code to assembly on a platform specific basis once you wer up and running self-hosted on the platform. This also gave you the opportunity to check assembly optimizations in user space first, without breaking everything by trying something that wouldn't work because of some mistake, and ending up with a lot of work to back the changes out (this was back in the RCS/SCCS days, where source code control systems weren't as capable as they are today).
It makes sense to do the same thing for games; minimally, the complaints they had about shaders should have been totally workaroundable, given that Direct X doesn't allow indefinite termination shaders, and requires the code to be fully unrolled compared to, say OpenGL, where there's no guarantee that a shader terminates (one of the reasons a game can crash a Mac or Linux using OpenGL, but can't crash Windows, using the OpenGL compatibility layer -- if it won't unroll, then it's discarded by DirectX).
In any case, it does show that there were at least some corners cut, and just because the host library is similar, you shouldn't expect the hand tuned code to be at all similar, especially going from a Cell architecture PS/3 (essentially, a data flow processor) to Von Neumann architecture on an AMD processor on the PS/4. It's obvious that all the hand tuned pieces would need to be rewritten, just as if you were porting to Windows or XBox or some other platform that wasn't also Cell-based. You'd think if they had planned ahead for ports to other platforms other than the PS/3, that that planning would be directly applicable to geting the code running on the PS/4 as well.
Seem to me like there's some pretty good advantage in doing games for x86 and Windows .. (but maybe not as strong if you optimise at this level.)
Sorry, but *yawn*.
Had they followed the practice, they would have a version of the source code that runs correctly (but slowly) that they could optimize for different target platforms.
Anyone remember how many cruise missiles could that thing power?
The main problem with this argument is that The Last of Us was PS3 exclusive, and it was PS3 exclusive from the start, so there's no need to write the code for portability(which inherently means the game will run worse, because you can't use platform specific optimisations). It was only when the PS4 came out the development team considered possibly porting the game, and even then it was never a guaranteed thing. The discussion of whether the game game SHOULD have been ported to other platforms is a different argument altogether. It was only because the game was tuned directly for the PS3 platform that allowed the game to look and play as well as it did.
Lots of graphics eye candy, little of play (and replaying) value.
Too much focus on online play, and DLCs
The main problem with this argument is that The Last of Us was PS3 exclusive, and it was PS3 exclusive from the start, so there's no need to write the code for portability.
"PS3 exclusive" is a marketing term. YOU ALWAYS WRITE PORTABLE CODE and then you optimize specific path IF AND WHERE NEEDED.
The down-moded AC is right. It's was their own fault and they are awful programmers.
Don't expect a discount just because it's an old title.
That the PS4 has the same or greater number of cpus as the cell had cpu+spu, plus the ability to use compute units on the GPU as 'simplified' SPUs, it becomes much more difficult to understand how these guys had significant trouble re-optimizing their code for the PS4's architecture. Now mind you there ARE places they could've been having stalls (since the AMD jaguar cores share resources per pair(like bulldozer, correct?)), but most of the places where such issues would come into play should be optimizable into OpenCL datapaths and thus offload enough threads from the cpu for it to be acting like a 'native' quad core, with some number of Cell-like processing streams to hand the less general purpose computations.
While programming and game programming are difficult, and can in some cases compare to rocket science, this really isn't one of them. This is more about identifying the right resource or tool for the job and utilizing it in the most efficient manner possible.
Having gotten looks at plenty of 'production' game source code, mostly open sourced, I am sure plenty of you know how much more akin to the OpenSSL library's code than say 'an idealized, portable, and properly documented codebase'.
It's your job, just get on with it, maybe write the code with portability in mind next time?
Alternatively they're really good programmers who got explicitly told "make this run like shit off a shovel and don't worry about portability - this will only ever be on PS3". You can say "but we should really write portable code", but if SMT still tell you to ignore portability then you're left with either doing what you're told or quitting.
Yeah, I had a sig once; I got bored of it.
Well, I'm not so sure about that. They designed their game for the horribly quirky PS3, which means that they'd either end up wasting much of the console's power or they'd twist the code until their video game works like a streaming application - which is the only thing the Cell can do efficiently. Since portability was not an issue (they knew the game was a PS3 exclusive) they decided to go with a PS3-specific design in order to get the most out of the hardware, thus making their game more appealing and thus more profitable.
They could decide between "write this platform-specific program in a suboptimal way so that it's easier to port to another platform" or "heavily optimize for the sole target platform in order to increase market success". I don't think the latter was an invalid choice. If anything, this story illustrates just how bad an idea it was to put a Cell in a game console.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
Coding for the Cell is a pain. It has six coprocessors with limitations you can't ignore. People who never worked with heterogeneous architectures may think you can implement a non-optimized design and achieve good performance, but you can't for anything big like a game. If it was launched only on PS3 at first, it wouldn't even make much sense to worry about porting unless they knew it'd sell.
Besides, they already have a non-Cell version on PC, assuming this is the same game.
I expect the main difficulty in porting from PS3 to PS4 is the effort of converting all those programs between two broadly similar but different in the detail systems. The GPU shaders too were written for NVidia processors and now have to be converted / rewritten. And working through all the hacks, shortcuts and bad assumptions that come from dealing with code which has been crunched out to work on one specific platform and not another.
So it's mostly drudgery. I expect virtually all of the assets and much of the higher level code is reusable.
There are excellent books writen by Engineers at Naughty Dog (such as Game Engine Architecture) which describe the kind of abstractions most engines perform. The multithreaded job handlers are possibly what would have to be x64 optimized, while most of the general code would remain intact.
Anyone familiar with Naughty Dog's GDC presentations would agree.
The code optimization done by development studio Naughty Dog was a real technical achievement — making graphics look modern and impressive
Uh, are we looking at the same game, because from what I can see, it looks like complete ass. It does not look modern and it does not look remotely impressive. Looking at the shit lighting, the low poly counts and the blurry textures, this looks like a game from 2006.
No... You're not talking about some code that's designed to be portable, you're talking about code that was targeting exactly one piece of hardware, and trying to make the output look better on that exactly one piece of hardware than anyone else developing for that same exact one piece of hardware. Because of this, games for consoles have an insane level of optimisation for that one piece of hardware. More so in this case, you're talking about a piece of hardware that had one of the most exotic CPUs in decades. Porting from that to x86 is a huge challenge.
This is why I don't fault developers for not coding "directly to the hardware" anymore. So much extra effort (which means release delays, higher costs, tougher bug fixing) for minimal gain.
This isn't 1980 anymore. You don't have to eek out every last CPU cycle to get a playable game. Focus on the game design, leave the optimizations to the compiler.
You don't know anything about programming, do you? Take 50MB of assembly code and try to port it to another CPU architecture. Let me know how it goes.
If you wrote 50MB of assembly code without writing any development/not optimized/debug versions, good luck trying to develop anything substantial with that. AFAIK, most other game studios (Guerrilla, Insomniac) have already been able to ship games on x64 hardware. If you do dig into the details, Insomniac is another large supplier and user of SPU tech.
Why didn't Sony make the PS4 hardware more like that of the PS3? Then less effort would be needed to ensure PS3 games are portable to the newer system.
Last consoles I owned was Atari 2600 & original Nintendo.
I've been a PC gamer since.
Plating Ghostbusters & Chuck Yeager's Flight Simulator with joystick on a Tandy 1000 EX was fun, and all the free games in basic that came in the old magazine "Home and Office Computing" which became Family Computing (http://en.wikipedia.org/wiki/Family_Computing)
Anyhow I've never been a fan of consoles and while that might make me in the minority I still wished they'd ported to PC.
Someone posted the entire last of us game with no commentary and all the cutscenes a perfect play through I enjoyed like a movie.
I did same for Beyond Two Souls, entire game posted as a movie in HD with zero commentary. 8 hours 41 minutes straight through.
http://youtu.be/9qolJTsmmWA
Sigh, you really are an idiot. ND blows away those other developers in technical competency. Where exactly did you think Sony's ICE team was located, Waldo?
Why waste the time on a crummy game? The story and cinematics were nice but the gameplay and battle scheme was horrible. I was glad to get rid of this game
"making graphics look modern and impressive on a 7-year-old piece of hardware" - for me, graphics have looked as good as they've ever needed to be since, ooh, Metroid Prime? This is kind of detailing exactly why modern games suck, I don't care if Call of Duty 87 looks 63% more realistic than the previous one, they're not interesting to play
Sigh. The truth is that ND and Insomniac have worked on tech together, much before the PS3. I am just telling you that with those kind of partnerships and years of developing games for multiple consoles and hardware (MIPS, PowerPC and ARM), ND would know better than to write unportable code.
Clearly, you aren't from ND. And if you say you know so much about ND, tell us who you are and offer to AMA - so we know there's an element of possible truth to your arguments.
and brains and talent and resources... for a fucking video game. I wonder if people a hundred years from now will laugh at us or hate us for the squandered resources?
Mostly random stuff.
Keep in mind that Naughty Dog was and is a studio that does Sony exclusives. There was no reason for them to worry about portability, which is exactly why their games were always leading edge in performance. That studio, above all others, knew how to use every last resource that the PS3 offered.
It's not an identical core, it's only of the same generation. And there's only one to the PS3's three.
Obviously, I meant to the 360's three. But if I don't issue a correction, surely some wag will pounce. Here, I'll add in an actual link to a real comparison of the architectures. Or you know, This old thing. The 360's PPC cores have twice as many LSUs, integer and fp cores as the PPC core in the PS3 — two of each instead of one. That's right, each PPC core in the 360 can do twice as much math as the PPC core in Cell. That's because you were meant to do all your heavy lifting in the cell cores.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
It happened on the Wii and DS for exactly the same reason it happened on PC, namely that Nintendo Wi-Fi Connection was implemented on top of GameSpy. And it's not like Sony is immune: see DNAS error -103 on any PS2 game. The only long-term sustainable solution is to let players run their own private servers.
if it's that hard to make it for ps4, like making the game practically from scratch, then why don't they also make it for pc? ps4 and pc aren't that different... most companies say that they won't launch a "port" for pc because they have to make the game from scratch, well that's bullshit and they'll learn the hard way to leave the biggest gaming platform today outside
I just noticed something else goofy about your comment.
There's absolutely nothing weird on PowerPC being used on videogames. Sony made things complicated for developers by tacking 6 specialized coprocessors inside its chip - what, for programmers used to have just one (MMX, 3DNow!, etc), was clearly a new level of computing.
Actually, they were already used to having two asymmetric coprocessors, since floating point is handled by a coprocessor on traditional x86, while integer and fp math are both handled by separate units inside modern processor cores.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
They should get to work on the next game, specifically for the PS4
Hi! everybody, give you recommend a good shopping place. ( http://www.cheaponcn.com/ ) Good quality and good service but cheap price, Believe you will love it. You must not miss it!
The amount of ignorance in this post is incredible.
BLAZE ON ANONYMOUS COWARD.
If only they'd put that effort into getting the gameplay balanced... Which is a problem common to most of the Naughty Dog games from the PS3 period, in my opinion. The story and the music were exceptional, but the graphics clearly took front seat to the game design. I saved most of my points to get Shiv Master in order to counter the Clickers, only to have my character replaced with one that had no skills. And then had Clickers dropped on me at close range as I wandered around corners! Was no longer really interested in the fancy graphics at that point...
Isn't the PS3 running an IBM P6 ppc chip?
Subversion of spatial scale luxury decoration ideas.