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

Comments

Re:Shitty code

[DreadPiratePizz]

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.

Re:Shitty code

[Zembar]

The PS4 is x86, the PS3... not so much.

Anything assembler-level optimized for the cell architecture would be absolute hell to port.

Re:Porting is news for who?

[Stickiler]

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.

Re:Shitty code

[Tablizer]

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

Re:Own medicine

[xyzzyman]

How are the games obsolete? I bought a PS3 in September and have over 20 games on disk along with a bunch of digital ones and I love it.

PS3 Optimization: Parallelizing code 7 ways

[perpenso]

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.

Re:PS3 Optimization: Parallelizing code 7 ways

[Animats]

The PS3's Cell processor is, in simplified terms, a general purpose CPU and six special purpose coprocessors.

The "coprocessors" are decent general-purpose computers. The problem is that they only have 128K of RAM each. They can access main memory, with high latency but good bandwidth, through a DMA mechanism. (There's also a relatively conventional NVidia GPU on the back end, so the GPU part of the job isn't the big difference. This isn't about shaders.)

That 128K of RAM is too small for a frame. Too small for a level. Too small for any big part of game state. PS3 programming thus consists in turning a problem into some form of streaming process, where data is pumped into Cell processors, processed a bit, and pumped back out. This is a signal processing architecture. It's great for audio. Sucks for everything else.

The PS3 was a "build it and they will come" architecture. It was cheap to make, but large numbers of smart people spent years trying to figure out how to use the thing properly. (Sony basically gutted their US R&D group to beat on that problem.) In practice, a lot of games did most of their work in the main CPU (a MIPS machine) and the GPU, using the Cell processors only for audio, fire and explosions, particle systems, and other tasks that didn't have a lot of interconnected state.

Re:PS3 Optimization: Parallelizing code 7 ways

[fuzzyfuzzyfungus]

It doesn't help that The Last of Us (for reasons that probably have to do with being published by Sony Computer Entertainment; but may go further, I don't know) was 100% PS3 exclusive, and apparently not built with the expectation that portability would be a consideration.

There are plenty of ways (either through better software design that game development and release timelines probably don't allow) or through heavier use of licensed engines and middleware that do abstraction for you, at a cost in money and potentially quality, to improve portability; but you are less likely to use them if time is short and 'portable' isn't on the list of objectives.

Had this been a cross platform title, they presumably would have just thrown the PS3 version away and worked from pretty much anything else.

Re:PS3 Optimization: Parallelizing code 7 ways

[Anonymous Coward]

Naughty Dog are a first party developer of Sony. So exclusive here, probably really means platform-exclusive.

So I'd assume at the time of development portability never even came up.

Re:PS3 Optimization: Parallelizing code 7 ways

[JavaBear]

"This isn't about shaders."

I'm recalling a story about the production of Uncharted 2, also by Naughty Dog, mentioning that this is definitely about the shaders and other graphical effects.

The game engine is not just general gaming code, pulled apart and optimized, it was written for the specifics of the Cell CPU, and the PS3 architecture, then optimized at a byte level. One of the tricks Naughty Dog learned, was to leverage the 7 active SPE's in the Cell CPU to assist the GPU in rendering the scenes.
They have the SPE's do some of the tasks the ageing GPU can't, as well as physics.
Besides, the GP CPU in the Cell is not an x86 CPU core, it's another relic, a PowerPC core, and not a particularly fast one at that, IIRC its primary job is to manage the 7 SPE's

Re:PS3 Optimization: Parallelizing code 7 ways

[Anonymous Coward]

Yeah, sure. But no.
Optimizing code for cell means re-writing the code so it operates on small data, and data is transferred explicitly between the cores.
The SPUs have fast communication between some of them, which means that if you run the wrong kernel on the wrong SPU the whole thing slows down dramatically.
This combined with all the explicit DMA transfers you have to do makes the code extremely architecture specific.
Essentially the only code that can stay "the same" is the code running on the MIPS core, which if they really optimized it is only control which kernel is executed on which SPU.

Re:PS3 Optimization: Parallelizing code 7 ways

[rsmith-mac]

In practice, a lot of games did most of their work in the main CPU (a MIPS machine) and the GPU

Minor correction: Cell's main CPU - called the Power Processing Element - was a PowerPC processor, not MIPS.

Re: PS3 Optimization: Parallelizing code 7 ways

[loufoque]

It's not fundamentally different than programming DSPs but for floating point. The Cell isn't that exotic.

Re:PS3 Optimization: Parallelizing code 7 ways

[Anonymous Coward]

What a horribly STUPID idea.
You suggest that they should have written all their code in some generic x86 format.
Well guess what, that kind of code runs like SHIT on a ps3. You'd be able to make games that look like pc games from 15 years ago. If you want better stuff you'll need to actually write code for the architecture at hand.
If you write the code for the actual machine then you invarably end up with fundamental adaptations to the engine, in how it handles data, how interupts are handled, how bandwidth is used, how the coprocessors are used, etc.
Making a game like this is like defining a factory process. Only the ps3 is not a x86 factory. It has some of the same modules but everything is specced differently.
With games its not only important IF things get done. You also need to keep a tight schedule on WHEN things get done. And this happens to be something heavily influenced by the architecture and how you use it. Controling this makes that the code will have to be pretty specific to the hardware.
The generic bullshit you talk about can only exist on a higher abstraction level. It is still there and portable, but it plays a much less important role in consoles.

In short, consoles have a different set of requirements to get anything decent out of them. They are desiged to be optimized in the way naughty dog has done and the inportability this leads to is something the industry takes as a fact of life.

Re:PS3 Optimization: Parallelizing code 7 ways

[Narishma]

Another correction: the SPEs have 256KiB of local storage, not 128KiB.

Re:PS3 Optimization: Parallelizing code 7 ways

[beelsebob]

The problem with such an approach is that while you can indeed simulate it, simulating it will be inherrently slower than running it on the cell in the first place. While you do on the PS4 have one x86 core per SPU on the PS3, they're running at half the clock speed, and for very specific tasks, the PS3's SPUs had great IPC, so simply getting a core on the PS4 to do the same thing as an SPU on the PS3 will simply be slower.

Re:PS3 Optimization: Parallelizing code 7 ways

[Anonymous Coward]

Their code is pretty much a job queue where some of the code is a SPU job manager, and the dispatchers are SPU jobs. They have two kinds of code, for the PPU and the SPU. Now they pretty much need to write for one processor, the x86. I imagine they are bullshitting us if they find it harder to optimize for a homogenous kind of hardware, and we know very well that most of their code is portable C++ and their scripting is some variant of LISP.

Please, I've thought about this and Naughty Dog are just bullshitting us on the effort.

Re:PS3 Optimization: Parallelizing code 7 ways

[Anonymous Coward]

Still too little. 640k would have been enough for everyone.

Re:PS3 Optimization: Parallelizing code 7 ways

[MightyMartian]

I'll come in again.

Re:PS3 Optimization: Parallelizing code 7 ways

[CronoCloud]

In practice, a lot of games did most of their work in the main CPU (a MIPS machine)

The PS3's Cell isn't MIPS, it's PPC.

Re:PS3 Optimization: Parallelizing code 7 ways

[CronoCloud]

a PowerPC core, and not a particularly fast one at that

It's 3.2 GHz, hyperthreaded, with an Altivec unit. Probably more capable than the CPU's on all those WinXP machines still running. Heck it might even beat the Athlon X2 240 (2.8GHz) I have in this machine.

Re:PS3 Optimization: Parallelizing code 7 ways

[drinkypoo]

It's 3.2 GHz, hyperthreaded, with an Altivec unit. Probably more capable than the CPU's on all those WinXP machines still running. Heck it might even beat the Athlon X2 240 (2.8GHz) I have in this machine.

But the Altivec unit is not as capable as the three units in the 360's core. And that processor most certainly will not beat your Athlon 64 X2.

Re:PS3 Optimization: Parallelizing code 7 ways

[Anonymous Coward]

Considering it's an in-order variant of the PowerPC unlike what you might find in the workstations, servers, and mainframes (or the Gamecube / Wii / Wii U just for note), there's not a hope in hell it would compare well to the Athlon X2 240 in your machine. And that's ignoring the obvious disadvantage of comparing a single core, hyperthreaded part to a dual core non-hyperthreaded part and the greater availability of execution units, buffers, registers, and caches the latter implies.

Let me put it this way, would you expect an Atom 230 (http://ark.intel.com/products/35635/Intel-Atom-Processor-230-512K-Cache-1_60-GHz-533-MHz-FSB) clocked at 3.2 GHz to compare to your setup? Because that's pretty close to what you're expecting. Assume that such a processor would scale perfectly, if you doubled its frequency and thus its performance you can get a sense of the gap there would be to make up: http://anandtech.com/bench/product/79?vs=114

Obviously you could expect differences due to the different architectures, but rational thinking would say those differences aren't going to surmount that disparity; not even close.

Re:PS3 Optimization: Parallelizing code 7 ways

[Atomic Fro]

It's 3.2 GHz, hyperthreaded, with an Altivec unit.Probably more capable than the CPU's on all those WinXP machines still running.

Though its not necessarily the PowerPC's fault, try running flash on the thing and see which feels more capable.

Re:PS3 Optimization: Parallelizing code 7 ways

[Blaskowicz]

Simulating SPU code is nearly impossible, if you want to get it running at a reasonable speed at least. What makes it special I think is the use of its "local storage", which is impossibly fast and low latency, as if your PC used the L2 cache as RAM. Up to six SPE can be used in a game, so multiply the bandwith by six!

If you have enough low level control on a PS4 or XBO's CPU, you have 4MB L2 for the eight cores, actually two 2MB L2 each shared by four cores (the CPU is two quad-core CPUs copy-pasted next to each other). But that CPU was made for PC so I suspect the use of cache is all automatic.

Running functionnally equivalent code on the modern GPU is a better bet?, you have a 64 KiB Local Data Store per "Compute Unit" on the GCN GPU (each CU has four 16-way SIMD, vulgarized as 64 ALUs)

Re:PS3 Optimization: Parallelizing code 7 ways

[CronoCloud]

It would depend on what it was running. I've ran Linux on the PS3 so I was able to make "some" comparisons. In my experience, yes, the PS3 was faster for some tasks. It was noticeable in the GIMP in particular. For some other tasks, it was slower, but not "that much" slower. Part of the problem was the RAM limit.

But there is a reason I rip CD's in the PS3 and not on this machine, the PS3 is faster.

Its not about assembly code ...

[perpenso]

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.

There's actually some validity to the GP's post.

[tlambert]

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.

Re:Porting is news for who?

[aliquis]

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

Re:Own medicine

[aliquis]

He exageratted.

But over in Nintendo camp supposedly it's bye bye for all online multiplayer gaming for the Wii and DS now.

(Well, that have happened on PC too, but it's still due to vendor lock-in at least :))

So someone didn't follow the practice ...

[Ihlosi]

... of making the software run correctly first, and only then doing optimizations (down to the assembly 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.

Re:So someone didn't follow the practice ...

[Anonymous Coward]

Is it a good practice for cases like these? I argue not.

Let's say that we do create a reference version, then optimize. Since we are intending to push the hardware to its maximum, we have to assume that we will hit the occasional performance wall. How do we deal with that? We change the behavior of the program to fit within the limitations. This means that our definition of correct behavior has changed and the reference version is no longer correct. So, we update our reference version to match the version we plan to publish. This involves backporting the changes, then carefully testing to verify that the behavior is exactly the same as in the optimized version.

We're left with the question: Why do we call it a reference version if it is derived from the version that is supposedly derived from it?

The optimized version is the real reference version. The "reference" version is really just a port to a hypothetical platform. And, rather than just porting the final version, we are porting every bit of wasted effort along the way.

We get all the cost of the PS3 to PS4 port, dragged out over the whole path of development, with no target platform to sell it on. Sure, porting "reference" to PS4 will be cheaper than PS3 to PS4; however, PS3 to reference to PS4 will be much more expensive than directly porting PS3 to PS4.

So, best case, we spend more money to save time porting to a platform we never intended to support. Worst case, we spend a lot of money on a port that doesn't go anywhere. It's a lose-lose.

Re:So someone didn't follow the practice ...

[KliX]

The optimisations are the program, there is no unoptimised state to work from. Have you ever worked with soft real-time code?

Re:So someone didn't follow the practice ...

[_xeno_]

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.

I expect that when they started, they had no intention of porting to other platforms.

Naughty Dog is Sony these days. They only make games for Sony platforms. So they targeted only the PS3. I'll bet when development started, Sony hadn't finalized PS4 plans.

Now the PS4 is out and desperate for games (go ahead, name a PS4 exclusive), so Sony is having them port it to PS4. And since the game was never intended for anything other than the PS3, they're running into difficulties.

I wouldn't blame the programmers for optimizing for the only platform they were told to target, I'd blame the managers for suddenly springing a new platform on them after the game was done.

Re:So someone didn't follow the practice ...

[VortexCortex]

Correct First, Clever Later is my core philosophy. There is nothing I don't abstract via portability layer.

I wrote a "hobby" OS kernel from scratch, starting only with a bootable hex editor on x86. The FIRST thing I did was create a simple bytecode VM to call into a function table to give me ASM level abstraction, before I even switched out of realmode to protected mode. THEN I created the bootloader, a simple text editor, assembler, disassembler, a crappy starter file system, and that was enough to bootstrap into a a full OS completely free from the Ken Thompson's Unix Compiler Hack. A bytecode to machine code compiler was one of the very last things that got written (it was boring). All programs on my OS (yes even Java or C code) compiles into bytecode and the kernel can link programs into machine code at "install time" or include the (shared mem page) VM stub and run them as emulated -- Which is nice to provide application plugins, scripting, or untrusted code. Since the kernel is compiling things it can do far more checks on the validity of binary code, as well as optimizations. Since multiple languages can compile to the same bytecode I can transparently integrate libraries written in different languages instead of each language needing it's own implementation of basic things like big-integer math. I can even change calling conventions on the fly for transparent RPC.

For Gravmass last year I got some nifty embedded ARM systems to upgrade a few of my my x86 robotics projects with (for better battery life). Instead of building a cross compiler (which takes a while) and compiling the OS components into ARM from x86, I just implemented the bytecode VM on ARM in one weekend, and I had my full OS software stack up and running (albeit slowly since I lacked native compilation).

I took the time to do things right so porting painless and it was actually fun to migrate to a whole new architecture. Then I was free to debug, build, and test stuff right on the hardware over serial console. Now I've got a project to build a usable computer from scratch (a transistor version of a CPU I built from about 400 contactors) and the new system will use my VM bytecode as its native machine language, so I won't have to write a compiler. I'm just taking things nice and easy, even teaching kids and neighborhood enthusiasts CS101 as I go. Man it sure is nice to have as much time as I want on these hobby projects -- Time to actually do things absolutely correct first, then as clever as I dream of later...

However, imagine a Publisher is breathing down your neck to get things up and working and done before a deadline. They don't care about you making it harder to porting your code to a new system, right now what matters is getting your basic engine up and running pronto so other folks can start working with their content on the dev kits / consoles. Now imagine even if you started out with a cross platform system, you've got to squeeze a new feature in and it needs to work fast, and yesterday -- No, you don't have time to write a slow version and a fast non-portable version and you've made this sort of addition so many times that it's hasn't been possible to run the slow portable code with the latest assets in over a year.

Yeah, the GPU and shaders aren't all that different but this new platform is the difference between porting a program design from Erlang to a multi-threaded C program. Getting an image up isn't just getting a spinning flat-shaded teapot displayed -- You've got a bunch of code in your asset loading system to handle your data storage format before you can even get started, and both of these were optimized for the CELL processor's big endian while the new platform is little endian. The asset streaming was probably done in several stages distributed among the CPUs, and operating on batches of data a few KB at a time. I've got no doubt that before you could see a properly textured and lit wall there'd be some serious liftin

Re:So someone didn't follow the practice ...

[Ihlosi]

I expect that when they started, they had no intention of porting to other platforms.

Oh, yeah ... that is the other mistake. "No one's ever gonna look at this code again, so it's okay if it's an incomprehensible, unmaintainable mess. Ship it!".

Re:So someone didn't follow the practice ...

[west]

I'd suggest that the PS3 is radically different enough that if your *reference design* wasn't PS3 specific, you've probably already failed.

You can't "optimize" a bubble sort into a quick sort.

(One interesting effect of both the PS2 and PS3 was that their design was so bizarre that it took years for programmers to be able to optimize effectively. This meant that games were consistently better every year even without any changes in the hardware. With a more conventional architecture, what you buy in the first year will essentially be state of the art for the life of the console. Makes it much harder to get people excited about "this year's version of xxx".)

Re:So someone didn't follow the practice ...

[donaldm]

The Playstation-has-no-games meme was true back when the PS3 first came out, but it ended up with significantly more (and often better) exclusives than the 360 - hell, their camera & motion-tracking add-on had more and better exclusives than the 360's kinect. Of course, since memes never die, the next-gen console with more exclusives is being mocked for having no games. What's next, people claiming the xbox controller is huge for people with huge hands?

Now that leeds to the following cartoon :).

Re:So someone didn't follow the practice ...

[Ihlosi]

I'd blame the managers for suddenly springing a new platform on them after the game was done.

This is normal manager behavior. An experienced programmer plans for it, or makes sure he's not the one who has to adapt the old code to the new platform.

Re:So someone didn't follow the practice ...

[CronoCloud]

Now the PS4 is out and desperate for games (go ahead, name a PS4 exclusive)

Umm wait, I think I can name one..ummm. Resogun? Ummmm Infamous Second Sun? And there's a Brown Shooter or two I can't remember the name of. [looks over at the PS4 sittingmostly idle because of the lack of games in genres I want to play....maybe I should have got a Vita instead. I do play DCUO on it now and again....but that is not exclusive the PS4]

Re:So someone didn't follow the practice ...

[Ihlosi]

You can't "optimize" a bubble sort into a quick sort.

When you're deciding on a sorting algorithm, you're already optimizing. The unoptimized version just needs to run correctly, i.e. deliver the expected result. You pick a search algorithm that's easy to understand for that (so, bubble sort rather than quick sort). Chosing one that is best suited to the target hardware and implementing it optimally on the target hardware is part of the optimization process.

Re:So someone didn't follow the practice ...

[ultranova]

Oh, yeah ... that is the other mistake. "No one's ever gonna look at this code again, so it's okay if it's an incomprehensible, unmaintainable mess. Ship it!".

But that's not what the summary said. It said the code is specific to a particular architecture, and there's considerable effort required to port it to a completely different architecture.

It doesn't matter how neat your C program might be, moving the computations to OpenCL is still going to be a pain.

Re:So someone didn't follow the practice ...

[Threni]

No, that's what you do when you're writing something easy any entry level developer can do, like most of the shit enterprise software companies insist on writing. It doesn't work when you've got a cutting edge console with alien technology and a limited number of developers capable of writing for it. This isn't exactly Stack Overflow "pls help i am writing anroid app but i am getting teh crash plz to give me tutorial" territory.

Re:So someone didn't follow the practice ...

[_xeno_]

Except I've heard of Titanfall, and I though "Infamous: Second Son" was the PS3 sequel to Infamous. Apparently it's in fact the third game in the series, proving just how good Sony is at both marketing and naming things.

Hilariously, when I Googled it to find that out, the top hit was "How Second Son Really Hurt The inFamous Franchise" so I'm not sure that's really a good exclusive to have...

Plus your own link points out Titanfall sold better than Infamous Second Son, it just did it across more platforms because it isn't a Xbox One exclusive, leaving the Xbox One version sales alone to do worse than Infamous Second Son.

Re:So someone didn't follow the practice ...

[marsu_k]

I don't know what kind of personalized settings you have on your Google account, but I'm unable to find your link from the first four pages of my results (I never venture any further, usually never past page two even).

Re:So someone didn't follow the practice ...

[UnknownSoldier]

> You can't "optimize" a bubble sort into a quick sort.

At the risk of being rude, you are not really understanding what optimization actually means.

You need to take a step back from the trees and look at the forest.

Sorting is defined as:
  * Input: Given a set of unordered data
  * Output: Return a set of ordered data

Optimization entails both macro and micro efficiency.

The algorithm determines the high level efficiency.
The programming language may offer low level efficiency.

For example you could write CRC32 without any table usage:

uint32_t crc32_bitwise(const void* data, size_t length, uint32_t previousCrc32 = 0)
{
  uint32_t crc = ~previousCrc32; // same as previousCrc32 ^ 0xFFFFFFFF
  unsigned char* current = (unsigned char*) data;
  while (length--)
  {
    crc ^= *current++;
    for (unsigned int j = 0; j < 8; j++)
      if (crc & 1)
        crc = (crc >> 1) ^ Polynomial;
      else
        crc = crc >> 1;
  }
  return ~crc; // same as crc ^ 0xFFFFFFFF
}

But with a table approach it becomes the much simper:

uint32_t crc32_1byte(const void* data, size_t length, uint32_t previousCrc32 = 0)
{
  uint32_t crc = ~previousCrc32;
  unsigned char* current = (unsigned char*) data;
  while (length--)
    crc = (crc >> 8) ^ crc32Lookup[(crc & 0xFF) ^ *current++];
  return ~crc;
}

Code copy pasted from Stephan Brumme

 

Re:So someone didn't follow the practice ...

[drinkypoo]

But that's not what the summary said. It said the code is specific to a particular architecture, and there's considerable effort required to port it to a completely different architecture.

And that's why many developers (who have often sounded off here on slashdot) hated the PS2 and the PS3. Because it was so different, they made life harder and for what? In the end, most titles developed for both platforms (whether Xbox vs PS2 or Xbox 360 vs PS3) were smoother or had more detail on the Microsoft platform because it was easier to get more out of the machine. Developers don't want platforms that take so much effort to learn. They won't be able to take the skills to the next wacky architecture.

Re:So someone didn't follow the practice ...

[mattack2]

One interesting effect of both the PS2 and PS3 was that their design was so bizarre that it took years for programmers to be able to optimize effectively.

Can you give a couple of very very high level examples of what is bizarre about them? (..if you know why they were designed that way, even better)

Re:So someone didn't follow the practice ...

[tepples]

Your hobby OS sounds interesting, and your arguments that it's often more complicated than it may appear at first are compelling.

THEN I created the bootloader, a simple text editor, assembler, disassembler, a crappy starter file system, and that was enough to bootstrap into a a full OS completely free from the Ken Thompson's Unix Compiler Hack.

That's one way to defeat Trusting Trust. The other relies on having multiple implementations of a particular programming language, such as Visual C++ vs. GCC vs. Intel vs. Clang. David A. Wheeler pointed out in 2009 that if you bootstrap a compiler with a bunch of independently developed compilers, the binaries will converge unless a Ken Thompson attack is in progress.

All programs on my OS (yes even Java or C code) compiles into bytecode

Interesting. It appears even web browsers are doing the same thing, using LLVM's Emscripten backend to compile to asm.js and then compiling that into bytecode.

I can even change calling conventions on the fly for transparent RPC.

I'm not so sure how transparent RPC is so desirable, as a program can never be sure whether a call will block for 200 microseconds within a machine or 200 milliseconds when called across the Internet.

I've taken to debugging shaders separately from the main program

"Regular software devs" would call this "unit testing". I've written a floating-point library in 6502 assembly language, and a 6502 simulator in Python that I had written earlier helped me to build a unit testing framework.

Re:So someone didn't follow the practice ...

[west]

By bizarre, I mean that it has taken years for PS3 designers to be able to re-architect their games to keep all six SPE's busy because of limitations on the SPEs (as detailed multiple times in postings above by others). In other words, bizarre means "different", not necessarily bad. Essentially, there was not a lot of skills transfer between being able to program most machines out there and effectively programming the PS3.

Very briefly, the PS3 has one main core and six accessible Synergistic Processing Elements (SPEs). The SPE's are wicked fast, but memory access restrictions and limited access to main memory means that it's really tough to get them all doing useful work. For example, when the PS3 first came out, the net was full of people criticizing games where 3 of the processors were essentially unused.

As programmer gradually learned to re-architect their applications (and from what I understand through reading interviews, it was re-architecting - if you weren't designing to address the limitations of the SPEs from ground up, you probably weren't going to make very good use of them), the programs seem to get faster and to get better graphics each year.

It's an interesting (if dangerous) strategy

Re:So someone didn't follow the practice ...

[UnknownSoldier]

> I'll bet when development started, Sony hadn't finalized PS4 plans.

That's correct. The PS4 was in development for about 4+ years. Naughty Dog's focus wasn't on writing a game for unannounced hardware whose specs were volatile but to finish and ship a game on a known platform. (Disclaimer: I used to work for SCEA.)

> I'd blame the managers for suddenly springing a new platform on them after the game was done.

That's exactly right. Short-term Profits vs Long-Term thinking.

Someone needs to mod your post up as +Informative.

Re:So someone didn't follow the practice ...

[west]

*sigh*.

I see my analogy failed.

If my job is to write a program that does a sort, and I write a bubble sort, then if I really need it to work better, I don't tweak it, I redesign from scratch. Most people won't call that an optimization - they'll call it a redesign. Hence my original comment. (And yes, if we're being pedantic, *if* the sort is part of a larger program, then I would call rewriting the sort an optimization.)

My point was that if you don't *start* by taking all the strengths and weaknesses of the PS3 into account in the initial design phase, influencing or even dictating many of the the large scale design decisions (including the actual game play), you are unlikely to make maximum use of the machine.

You could call rewriting the design an optimization, but I don't think that's how most people think about it.

Re:So someone didn't follow the practice ...

[Ihlosi]

You've quite obviously never worked in embedded systems

Your crystal ball is quite obviously broken, as half of my work involves embedded system (the other half, the one that comes before the whole embedded thing, involves Matlab).

Re:So someone didn't follow the practice ...

[Blaskowicz]

Also the GPU was relatively weak, with the limitations of the geforce 6/7 architecture while the Xbox had an almost modern one in comparison.
Devs found ways to "help" the GPU such as doing preliminary geometry work and culling, and doing post-processing on SPE rather than on GPU.

That allowed to do something with the SPE resources that were still unused, even if they managed to fit other kinds of work on them.

Re:Own medicine

[Travis Mansbridge]

Well, if they were EA games meant to be played online, many of the servers are already offline.

Failed to keep up with the latest yearly sports release? TS.

Re:There's actually some validity to the GP's post

[Stickiler]

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.

When you consider the fact....

[Anonymous Coward]

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

Re:When you consider the fact....

[Blaskowicz]

I think Jaguar's L2 run at half clock? sounds terrible, but the architecture is optimized for low power. Also, not all caches/memory are equal. They're optimized for certain access patterns (there's cache associativity, which I don't understand much. Or imagine that some memory only realistically allows to write 4KiB pages while another is okay with writing bytes..)

Re:There's actually some validity to the GP's post

[_Shad0w_]

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.

Re:There's actually some validity to the GP's post

[Jesus_666]

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.

Re:Shitty code

[DrXym]

It was exotic for the time, but most of the principles are little different from GPGPU programming. You write programs called kernels that are loaded onto the SPU, you feed them data, the kernel processes the data and the result is used for something else. Nowadays people write similar programs using OpenCL or CUDA.

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.

Re:The problem with today's games

[aliquis]

What about all the indie bundles / small games?

Surely you can find a shitload of platformers, shoot 'em ups, puzzle games, physics games, space development games and so on to fill your time with?

Re:Shitty code

[beelsebob]

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.

Re:Shitty code

[Anonymous Coward]

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.

PS4 hardware

[PFritz21]

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.

Re:PS4 hardware

[drinkypoo]

Because the PS3's hardware was stupid. It never paid out the kind of performance dividends they claimed it would, and to even approach them took insane amounts of effort.

Re:PS4 hardware

[Lisias]

Because IBM didn't improve the PowerPC processor line since them, while Intel, AMD et all spent a lot of money on the x86_64 architecture.

In the end, it's not what the architecture did in the past - what matters is what the architecture will do in the future. Now, x86_64 is far more capable than the CELL architecture. So, if you want to build a top performance machine today, you will go with x86_64.

Re:PS4 hardware

[drinkypoo]

Because the PS3's hardware was stupid.

No, it was not.

Yes, yes it was. I didn't argue that cell had no purpose, but it was stupid to use it for gaming. And sadly, cell was only ever widely used in scientific computing in PS3s, because the only other way to get it was madly overpriced. Then Sony removed OtherOS and the supply of PS3s usable for scientific computing was constrained, although by that time the cell had been far surpassed.

Sony gained dominance in part because development for the Playstation was simpler than development for the Saturn or the Jaguar. Microsoft gained a foothold in part because development for the PS2 was a super bitch. Then Sony went on to make another console for which development was difficult, and the 360 became the dominant console of its generation. Microsoft probably wouldn't even be in gaming today if Sony had adopted a more conservative architecture for the PS3. It took them until the PS4 to figure that out, and they did indeed finally manage it — by making the same console Microsoft was making, or vice versa.

Re:PS4 hardware

[Lisias]

No, it was not. =D

You make a very poor judgment of the last decade developers. And somewhat lack of history knowledge.

What did PS3 a good start was the huge Microsoft failure on delivering a faithfully working hardware (that Red Ring of Death issue, remember?). Any other company would had fold, but Microsoft had (and still has) a huge cash cow to milk (Microsoft Office), and that was the sorely reason XBox didn't fold at that time.

But Microsoft people aren't stupid (for the most part, at least), and XBox was fixed. And they did a really big thing: the Microsoft Live. This really changed the game, and Sony got a really nasty bite in the ass. Sony took too much time to get the PSN up to the Live level (still doing it by the way).

By the way, The XBox 360 is also a PowerPC machine - the same core used on sony's PS3. And the NIntendo Wii (and also the WIi-U). And also on GameCube, Apple's failed Pippin and a lot of others dead on arrived videgames. 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. However, parallel computing appears to be here to stay (look at the ARM chips) - and having EIGHT general purposes CPUs competing for the same resources is not for the faint of the heart (Microsoft took years to learn, look at that crappy piece os software called Microsoft Windows). The complexity is still there - we just shifted it to another side.

Videogame Makers choose their hardware based on price, power and next years availability. Power PC had won the maker's heart in the past, but by some reasons IBM choose to abandon this race, giving the PowerPc a low priority on to research and development. AMD, on the other hand, spend a lot of efforts and money by upscaling their CPU to the current levels. The decision on using AMD's x64 over the previous PowerPC one was taken based on CURRENT chip power, CURRENT chip pricing and guarantees for chip supply for the product's lifetime.

The current new chip is easier to program? Beneficial side effect, nothing more. Not a single videogame maker will sacrifice any of the previous requirements to make the developer's life easier. We are not in the 90's anymore, there's a lot more people with programming skills nowadays, and a lot of them will be willing to deal with any extra complexity to take your job from you. (sad but true)

Re:PS4 hardware

[Baloroth]

There's absolutely nothing weird on PowerPC being used on videogames.

No one is saying using a PowerPC-based chip was stupid. Virtually everyone is saying using a Cell-based chip was stupid. You automatically lose performance relative to your competitors on games that don't take full advantage of the Cell architecture, which is precisely those multi-platform games where people can directly compare performance on the PS3 with performance on the Xbox. This article is a testament to the code specialization required to take full advantage of the architecture, and game developers simply weren't willing to put in that kind of effort (especially for a console that sold more for it's ability to play Blu-ray discs than it did for it's gaming capabilities). Often, even PS3 exclusives didn't utilize the Cell properly: it simply took too much work on an architecture few developers were familiar with (while PowerPC based, the SPE co-processor design means you have to use radically different techniques than you would for a normal PowerPC system).

Car analogy time: it's like giving a bunch of drivers who don't know how to use manual transmissions a manual car. Yes, manual transmission is faster than automatic, but if your drivers don't know how to use it properly, it's always going to end up being slower in practice.

Re:PS4 hardware

[drinkypoo]

By the way, The XBox 360 is also a PowerPC machine - the same core used on sony's PS3.

It's not an identical core, it's only of the same generation. And there's only one to the PS3's three.

And the NIntendo Wii (and also the WIi-U). And also on GameCube, Apple's failed Pippin and a lot of others dead on arrived videgames.

No, all those have different PPC cores.

The complexity is still there - we just shifted it to another side.

A lot more is done for you in a typical SMP system than in the Cell. The complexity is shifted away from the programmer, which is what we were talking about.

Not a single videogame maker will sacrifice any of the previous requirements to make the developer's life easier.

Videogame maker? You mean console vendor? Or what?

Re:PS4 hardware

[UnknownSoldier]

> Why didn't Sony make the PS4 hardware more like that of the PS3?

There are 2 parts to the answer: hardware + software.

SCEA, the games division of Sony, is NOT in the hardware business -- they are in the entertainment business. SAY WHAT?! But you ask "They designed all the hardware for the PS1, PS2, and PS3. What changed??"

Designing and Developing custom hardware is incredibly expensive. Sony was in the RED for about 4 years due to paying an expensive development cost on the PS3. The PS2 GPU - the GS - had a hardware bug where one of the Z-Test modes was completely broken! Sony was not going to repeat that same costly mistakes.

There is a reason commodity off-the-shelf hardware is cheap. Mass produced, and "good enough", which means "fast enough." Why pay engineers to "re-invent" the wheel for an CPU + GPU when there are already OTHER companies out there who have sunk a ton of man-hours and money into producing them??

Second, by using standard hardware, instead of fast "esoteric" hardware, you make it easier for developers.

Developers were constantly complaining to SCEA saying that while the PS3 had more power then the Xbox360 the XBox360 was vastly easier to develop for. Microsoft had a better compiler + IDE compared to the SN toolchain (which Sony eventually bought.)

> Then less effort would be needed to ensure PS3 games are portable to the newer system.

This doesn't make any financial sense.

The PS3 has 1 CPU (PowerPC Cell / PPE) plus 6 co-processors (SPE). The SPEs have 256KB of RAM but are EXTREMELY fast. The SPEs have their own assembly language.

The multi-core x86 means SCEA didn't have to focus on A) a compiler for the PowerPC Cell, and B) another compiler for the SPE. They can leverage GCC x86 across the board especially with x86 having 4 - 8 cores now.

For the full story will want to see these:

* https://www.youtube.com/watch?...
* http://www.wired.com/2013/11/p...
* http://www.forbes.com/sites/er...

Re:PS4 hardware

[drinkypoo]

http://www.geekwire.com/2013/xbox-360-wii-ps3-won-console-generation/

Dominant? I do not think that word means what you think it means. And 360s are still selling. Who's buying a PS3 now? Granted, that says nothing good about Xbone sales, but this isn't about Microsoft being great, but about Sony being lame. Given that Sony was giving away online gaming while Microsoft was charging, they should have ground Microsoft into a paste.

Re:PS4 hardware

[Sockatume]

One factor is that Ken Kuturagi had big technical aspirations; he's an engineer at heart, and the PS2 and PS3 were his attempts to make a mark on the way consumer computing is done. Unfortunately they were wholly inappropriate for the time they appeared. Ironically GPU compute, which actually is important these days, looks a lot like what he was trying to do. Just not terribly premature and inflexible.

Re:PS4 hardware

[Narishma]

More people are still buying PS3s than 360s worldwide. The 360 has only dominated (and is still selling relatively well) in the US and UK.

Re:PS4 hardware

[drinkypoo]

More people are still buying PS3s than 360s worldwide. The 360 has only dominated (and is still selling relatively well) in the US and UK.

Oh, you mean the countries where people buy the most [legitimately licensed] game consoles? Please, do go on.

Re:PS4 hardware

[Lisias]

Car analogy time: it's like giving a bunch of drivers who don't know how to use manual transmissions a manual car. Yes, manual transmission is faster than automatic, but if your drivers don't know how to use it properly, it's always going to end up being slower in practice.

No if *you* hire the good drivers, and use them to take a edge on your competitors - what's pretty feasible when you get the market leadership (of near it).

Anyway,I never stated that CELL or Emotion Engine were *easier*, I stated that they were *faster* at their time.

Yes, PlayStation One got the developer's heart because Sony did a pretty good job on make the developer's life easier. But then Sony throwed this through the window on PS/2, an excellent but totally awkward machine at that time: fast as hell, but not compatible with nothing in this God's land.

Things didn't get prettier on PS3.

Why? Because this simply wasn't a concern anymore. Exactly like nowadays.

(I like it? I don't like it? It doesn't matter, what I like it's irrelevant!)

Re:PS4 hardware

[Lisias]

Videogame maker? You mean console vendor? Or what?

Console maker, I'm sorry. I misused the words.

Re:PS4 hardware

[Lisias]

More people are still buying PS3s than 360s worldwide. The 360 has only dominated (and is still selling relatively well) in the US and UK.

Oh, you mean the countries where people buy the most [legitimately licensed] game consoles? Please, do go on.

Yes, exactly that countries. Now, keep in your mind that only a tiny fraction of PS3 are currently "jailfree", as only the first models (the "Fat PS/3") run the firmware version that allowed the hack, and only a even smaller fraction of that fraction was never updated (downgrading the firmware is risky - usually bricks the console).

On the other hand, the hacked XBox "installed based" is huge. Every single friend of mine that are XBox users has a hacked console to play pirated games. About half has also an original XBox to play Network.

The other half that are PS3 owners, I'm not aware of a single one that has a pirate capable PS3. We all buy our games (most of the time, second hand) or download them (legally) from PSN.

And Yes, we're doing this on a country where pirating goes unchecked for decades (no, I'm not chinese! =D).

That's something to think on.

Re:PS4 hardware

[Lisias]

I stand corrected.

Please read "Because IBM didn't improve the PowerPC processor line enough to meet Sony's new requirements since them" instead.

Re:Own medicine

[donaldm]

How are the games obsolete? I bought a PS3 in September and have over 20 games on disk along with a bunch of digital ones and I love it.

Not only that but if you have PS1 games you can still play them on your PS3, but with the exception of a few PS1 games you probably won't. Unfortunately only the first FAT PS3's played PS1, PS2 and of course PS3 games, however if you compare graphics on a decent large HDTV most PS1 games are fairly grainy even with smoothing on, the PS2 (FAT only) is quite reasonable and many games are very playable.

It is unfortunate but as time goes by the only way to play older PS1, PS2 and eventually PS3 games is to run them in an emulator. This does not only apply to PlayStation games but all games that ran on a different architecture.

At the moment I have no intention of purchasing a PS4 since there are not many games I see for it that makes it a compelling purchase for me. Backwards compatibility would have made for a compelling reason since I have many PS3 games I am still interested in purchasing as well as ones I am currently playing and since I like RPG's and Action Adventure I have enough for 100's of hours of game-play before I even consider getting a PS4.

Wish they'd have thrown PCs a bone

[Cito]

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

Re:Wish they'd have thrown PCs a bone

[CronoCloud]

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)

You got that backwards, it was Family Computing first with the basic listings and game reviews and "full home computer coverage, not just covering x86 only"...and then later became Family and Home office computing, adding more articles for the "wannabe home-office entrepreneur" and then becoming "Home office computing" and dumping anything not home-office and IBM PC related.

Re:Wish they'd have thrown PCs a bone

[Cito]

Yes I just remember it was that magazine that taught me basic programming.

After typing in hundreds of game code line by line they had as their "centerfold" it seemed, hundreds of games, modding them and I got pretty perfect at it. Even won first place in 8th grade FBLA state programming competition with a program you did your taxes on, then roll the 1040/ez form into an okidata printer and it would print the form, do the math and only thing to do was sign it is what won first in 8th grade, I was only one in my region to do programming in 80s so I went straight to state and beat out other programs, I remember one was program that turned keyboard into musical keyboard, another mimicked an animated ball bouncing around the screen.

Loved that magazine, still got about 20 editions I saved, I'm 38 now, love reading ads for $2000 5 or 10 meg mfm hard drives and wanting one so bad...

My first modem was an acoustic coupler ;-) I think it was 300 baud

In ham radio I had a 1200 baud tnc for packet radio and at the moment was faster than my dialup modem was hehe

graphics, who cares

[jonthomson]

"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

Re:graphics, who cares

[GuB-42]

Can you please stop with this meme :
We don't need better graphics, [game I played as a teen] was good enough. We need better gameplay. Modern games (Call of Duty) suck.

Ok, time to remove the nostalgia goggles.
First of all, not all modern games are Call of Duty. There are plenty of very good games with interesting gameplay *and* good HD graphics, both in the big budget and indie scene. Of course, you won't like all of them, not everybody have the same tastes after all.
And Call of Duty 28 is not a bad game. It only annoys older gamers (me included) because it's just another military style FPS like we've seen for more than a decade. But for younger people who are just getting into video games (the target demographic), if they have to choose between modern graphics and the low-resolution, blurry/aliased, shadowless mess we had before and came to accept, what do you think they'll choose ?
Good graphics are important. Proof is : when you ask someone about what he think were good games, he will usually mention games that had state-of-the-art graphics for the time.

So much effort

[50000BTU_barbecue]

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?

Re:There's actually some validity to the GP's post

[asmkm22]

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.

correction

[drinkypoo]

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.

Nintendo WFC was GameSpy

[tepples]

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.

Re:The problem with today's games

[tepples]

What about all the indie bundles / small games?

Years ago it was like pulling teeth for an indie developer to get a devkit out of a console maker. Only very recently did PlayStation open up to smaller developers with things like Pub Fund.

double (triple?) replying

[drinkypoo]

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.

Re:double (triple?) replying

[Lisias]

As a mater of fact, your (almost desperate) counter-arguments to every single and minimal "goofy" of mine just demonstrates how difficult are being to you to simply present some facts that proves me wrong.

Let me tell you something: inside your Intel chip, there're not only three "integer coprocessor", but a entire array of ALUs.

From Pentium and ahead (if I remember correctly), Intel decided to o "RISC" style and invested a lot of efforts on pipelining the thing, in order to achieve a better instruction per cycle ratio. By the nature of pipelining make it hard to fully use all internal "coprocessors", they discovered that unless the programmer do very specialized techniques while programming, 20% (at the very best) of the chip stays unused all the time. A pretty waste.

They managed to overcome the industry incapacity to get rid of ancient programming habits (please read it right: I said ancient, not wrong) with hiperthreading. They just sacked another pipelined Control Unit inside the core, carefully crafter to use the chips parts that the first pipeline leaves unused. Each Control Unit appears to the Operating System as a CPU core (but make no mistake: it's just ONE core, faking it is two).

There's no problem with this solution, but one (sane - or at least non stupid) person can not just tag "stupid" anything that decides to be a better idea avoiding all that "faking two CPUs" thing, saving the money or the chip space, leaving space to yet more features.

The ordinary Intel chip nowadays has a lot more cores than the CELL. But you don't see it, because you choose to learn programming on a eco-system that uses customer money to make things easier to you. There's no problem with it, it's a valid way of doing things.

But what's wrong is just calling everybody that thinks that it's better to make developer's life a bit more complicated in order to save money on the long run. Doing this is not just wrong, its plain stupid (or bad faith).

Games have a different development cycle : the game maker (software) spends a lot, but a really lot of money building the game to one platform, but when the thing is done, the thing is done. For the rest of the product's lifecycle, development is at minimum. It's not a continuous development cycle that we're used on PCs - the hardware does not change! Again, when the thing is done, it's done.

It totally makes sense on saving money on hardware, what is hard and costly to "duplicate" (and the manufacture sinks money during all the product's lifecycle), even if by doing it, you make the developer's life harder as their product has a shorter development lifecycle, but it's easier to "duplicate" and have the same lifespan as the hardware.

Developers are not the core business in this industry. We're a important part of the business, but that's it.

(grow up!)

Re:port it for pc

[petermgreen]

Afaict console game series can be divided into two main categories.

1: Those funded/published by a big publisher who is independent of the console vendors. EA, Take 2, Activision etc. These games may have a timed exclusive but if they sell well they will most likely end up on multiple platforms.
2: Those funded/published by a console vendor, these are highly unlikely to end up on any platform not controlled by that console vendor.

Afaict this one falls into the latter category.

Re:Own medicine

[SuperDre]

Uhm, you mean, finally a game that actually makes use of the hardware you bought.. It's the biggest problem with PC's, because there is a new GPU every quarter (even though consumers don't buy them only once a few years), and the incredible ammount of different configurations, there is no incentive to even to TRY to optimize and actually use the hardware.. That's the beauty of buying a console, you know the games will still look ok/good/great by the end of the lifetime and you won't have to upgrade it, but with a PC you're glad if you're 2 year old PC can actually run the latest games on a level that looks like the console-version, or finally be able to run that 4 year old PC-game at a level that was shown in gameplay-previews due to the developers using triple SLI GPU's that weren't even on the market at the time..

Re:Super stoked

[Blaskowicz]

That runs on an IBM PS/3 :). I have one of those, it costs $10K, the case is made of depleted uranium, hard disk drives are gigantic and the bus is MCA Express (but you won't find cards except for 1TB RAM expansions and gigabit Token Ring)
Sadly a $500 PC is faster.

Re:Own medicine

[Blaskowicz]

Another solution would be to use a PS2 with the hack to run games of a HDD (you can rip legit games I think), that would help with the concern of optical drive dying and discs getting damaged at least.
PS2 is hard to emulate, might be doable at last with an extremely powerful GPU with hundreds GB/s of memory bandwith like Radeon R9 290 or future mid-range ones when they get memory on silicon interposer.. PS2 has that eDRAM with crazy bandwith, and crazy fillrate to use it.
Emulating PS3 might be doable in a future where we have "many-core" CPUs made of "tiles" each with their own extremely fast local storage like the SPEs. Even then there's difficulty in the PS3 running at 3.2GHz which is almost the max clock for a chip (well we can do 4GHz to 5GHz at best) so I wonder about managing to respect some timings in some cases.

Re:Own medicine

[Blaskowicz]

Wow.. Crysis came out in 2007 and I gave up on being able to run it! I did get a nice 65 watt graphics card at some point, but had to run at 800x600 or 1024x768 to get high detail and anti-aliasing, game looking bad IMO without those.. and whatever I did the framerate tanked in fire fights. So I figured I was CPU limited even though I had a recent one I thought it was nice enough. Mobo/CPU still haven't died on me and I see no reason to upgrade

Re:Shitty code

[DrGamez]

The amount of ignorance in this post is incredible.
BLAZE ON ANONYMOUS COWARD.

Re:Shitty code

[nobodie]

Isn't the PS3 running an IBM P6 ppc chip?