When have I said I don't count PSSG? All I said before was that Sony ditched their effort to do a decent OpenGL layer, replaced it with GCM, and now there is no transition between those, except for rewriting the whole engine. I might want to use OpenGL or higher level libraries, but what's my optimization path? See, that's the key to any agile development, don't do things up front that you don't need, BUT plan on how you CAN change and optimize if need arises.
*Game Development Issues*
- Thread starter valioso
- Start date
- Status
When have I said I don't count PSSG? All I said before was that Sony ditched their effort to do a decent OpenGL layer, replaced it with GCM, and now there is no transition between those, except for rewriting the whole engine. I might want to use OpenGL or higher level libraries, but what's my optimization path? See, that's the key to any agile development, don't do things up front that you don't need, BUT plan on how you CAN change and optimize if need arises.
That speaks to Sony ditching responsibility for manufacturing Cell, not for Sony ditching the use of Cell, nor for Sony abandoning the possibility of designing future Cell variants down the road.
You can get rid of VFTs with the CRTP.(and still leverage inhertance)
Copy ctors or cloning functions can handle your DMAs (which I'm not sure why DMAs would be required although I'm not sure you meant to imply this) or latch into an abstraction that deals with memory resources (freelists/mem-manager/whatnot).
You can eliminate unwanted template expansion by exporting the specific instantiations of a template you want to be available.
You can adapt pointers to freelists or use "handles" into a more intelligent abstraction layer which does whatever you want it to do with them to make OOP easier on everyone....err "else."
Iterators are an interface and given the implementation is up to you one can hide and hook into whatever you desire to be within them to handle dirty details you'd rather not deal with constantly.
You can forgoe C++ mechansims and accomplish OOP in C: (picked the first site that came up)
http://www.embedded.com/97/fe29712.htm
with patterns: (picked a random site)
http://www.adampetersen.se/articles.htm
With that said I realize the size of the 256K LS must be taken into consideration as well as the seperate address spaces. If nothing could be done to ameliorate the issues the LS size and hetero-memory spaces present I would agree with you whole heartedly that OOP is not possible to leverage with Cell.
I am not dismissing any problems you have had. I am only saying that it is possible to leverage OOP with Cell.
I have to sort of agree and disagree with you that Cell requires you to use the streaming model with it. It's a "by degrees" distinction between us I'm sure in any case.
---------
I seem to have misinterpreted what you meant by abstraction. My view is that abstraction has just about the same meaning as encapsulation.
If I read you right you're not saying this is impossible or difficult to obtain with Cell.
It very much sounds like a plea for legacy support to already be in place...almost sounds like a call to use x86 period given the tone of your last few posts.
Forgive me if I misread you. I am only making sure I understand what you're really saying.
Since Cell is different then all the legacy support for x86 cannot be leveraged and you would really prefer that you could put that to good use "directly".
The simple fact that things need to be refactored or re-engineered for Cell is what you think holds the PS3 back and is why you feel Cell will ultimately be a failure? Correct?
(Toshiba is only taking over production of the Cell processor as Sony would like to focus their resources elsewhere. Sony still holds ownership rights and IP for Cell.
I'm going to just leave your saying PPC is dead and what Apple is doing right now out of the discussion if you don't mind because I really think "more support" is really what's getting to you.)
Last edited by a moderator:
I'm going to try and paraphrase some of what I think Barbarian is trying to say, to try and clarify his point at least as I understand it, since a lot of people are tied up in the details of the argument and I think missing the point.
When PS2 was released code bases were in the 200K to 300K lines of code range, it was pretty much the only game in town and as a result even though people struggled with the esoteric architecture people perseveered. Even with that most PS2 game were limited by the the speed of the MIPS processor core, and VU0 wasn't heavilly used by most.
Today games are MUCH larger and more complex, I've worked on a couple now that are in excess of 1 Million lines, Cell is a radical departure from existing architectures, it requires rewriting a lot of code to extract performance from the architecture. I'm not going to throw away the million lines of code I have and just rewrite it all.
Barbarian is simply stating that it's difficult for radical departures in architecture to be successful, especially in an environment where there are competing evolutionary processors. Because as code size grows the cost of re-targetting it at a radically new design grows even faster.
Now yes given time and resources it can be done.
And it's somewhat more practical to move some of the bigger bang for buck core/graphics code over to SPU's, and there are even things in games that lend themselves to trivial SPU usage but that's a small percentage of the actual game code.
Sony also hasn't done themselves a lot of favors with their system level code and their tool support. Some of this again stems from "radically new architecture" and a lot of it just wouldn't matter if they were the only game in town and not a year late to the party.
My personal view is it's too early to declare winners and loosers, I think the PS3 architecture is intellectually interesting, but it probably wasn't Sony's best move. And I think they've continued to make mistakes across the board since the launch.
When PS2 was released code bases were in the 200K to 300K lines of code range, it was pretty much the only game in town and as a result even though people struggled with the esoteric architecture people perseveered. Even with that most PS2 game were limited by the the speed of the MIPS processor core, and VU0 wasn't heavilly used by most.
Today games are MUCH larger and more complex, I've worked on a couple now that are in excess of 1 Million lines, Cell is a radical departure from existing architectures, it requires rewriting a lot of code to extract performance from the architecture. I'm not going to throw away the million lines of code I have and just rewrite it all.
Barbarian is simply stating that it's difficult for radical departures in architecture to be successful, especially in an environment where there are competing evolutionary processors. Because as code size grows the cost of re-targetting it at a radically new design grows even faster.
Now yes given time and resources it can be done.
And it's somewhat more practical to move some of the bigger bang for buck core/graphics code over to SPU's, and there are even things in games that lend themselves to trivial SPU usage but that's a small percentage of the actual game code.
Sony also hasn't done themselves a lot of favors with their system level code and their tool support. Some of this again stems from "radically new architecture" and a lot of it just wouldn't matter if they were the only game in town and not a year late to the party.
My personal view is it's too early to declare winners and loosers, I think the PS3 architecture is intellectually interesting, but it probably wasn't Sony's best move. And I think they've continued to make mistakes across the board since the launch.
Thank you, I couldn't have said it better.
To scificube: I think you have very valid points, and definitely, it's gotta be possible to leverage OOP and other high level techniques and finding powerful abstractions that can hide the complexity of Cell yet realize it's true potential is sort of a question of time and money. I just wish I had it now, so I can focus more on making awesome games.
Just to clarify why I mentioned Itanium - Intel did try to have some legacy support there, but it was half ass effort. You can't just slap it as an after thought and it can't be a significant step backwards. I guess that goes to say that even Intel make mistakes
Thank you, I couldn't have said it better.
To scificube: I think you have very valid points, and definitely, it's gotta be possible to leverage OOP and other high level techniques and finding powerful abstractions that can hide the complexity of Cell yet realize it's true potential is sort of a question of time and money. I just wish I had it now, so I can focus more on making awesome games.
Just to clarify why I mentioned Itanium - Intel did try to have some legacy support there, but it was half ass effort. You can't just slap it as an after thought and it can't be a significant step backwards. I guess that goes to say that even Intel make mistakes
The feeling is mutual. You make very valid points as well Barbarian.
"so I can focus more on making awesome games" says it all to me.
It's been a pleasure speaking with you.
Thank you, I couldn't have said it better.
To scificube: I think you have very valid points, and definitely, it's gotta be possible to leverage OOP and other high level techniques and finding powerful abstractions that can hide the complexity of Cell yet realize it's true potential is sort of a question of time and money. I just wish I had it now, so I can focus more on making awesome games.
Just to clarify why I mentioned Itanium - Intel did try to have some legacy support there, but it was half ass effort. You can't just slap it as an after thought and it can't be a significant step backwards. I guess that goes to say that even Intel make mistakes
What games are you working on btw? Just out of curiosity
Or are you not allowed to say?
What games are you working on btw? Just out of curiosity
Or are you not allowed to say?
I've been working on some "kiddy" games, based on licensed properties etc. Those projects tend to have very hard deadlines (tied up to movie releases etc) and usually are not well financed, at least not beyond what the license was deemed to safely return. We still do put a lot of effort in pushing the hardware, and the current game I'm working on actually looks really nice (720p 60fps btw), but it's easy to see how the gameplay has often more important consequences, since our target audience rarely scrutinizes our screenshots
I'd like to reveal more details but that would make it quite easy to figure out who I work for, and I kind of enjoy the anonymous nature of B3D.
Last edited by a moderator:
Sorry to jump in 17 pages in, but Sony made a "radical shift" at what was probably a good time because their user base was at an industry all-time high. If they suffer an enormous 50% drop their user base for the PS3 will still be huge.
As for the architecture, they moved from a completely proprietary architecture in the PS1/PS2 to what will be fairly standard in 5+ years. I think everyone knows that multi-core chips are the way of the future and the Cell fits that description.
The point being, they were at a point where they had to make a shift. Either another radical shift to a completely different architecture with no future (like all consoles before) or a radical shift to a completely different architecture with a potentially huge future (the Cell chip).
I think it's a safe assumption that a PS4 will rely on chips that are hardware backwards compatible with current PS3 code, or at least that was the intention. The effort put into the PS3 will translate into the next generation. That's kind of a first in the console industry.
So they decided to get through the growing pains this generation when Nintendo was weak and Microsoft was still young. It was probably the right decision at the right time IF the PS4 is a large enough leap when it arrives while allowing coding techniques and their SDK from this generation to still be useful. For the first time in the history of the console industry it's conceivable that a game could be released on one disc that works in two generations of systems much like PC games. A PS3 game that's "better" on the PS4 because the development tools are the same.
Cell isn't really typical multi-core and I'm not sure it will be in 5 years.
No, but if the user base of the PS3 gets to 50 Million (I assume a minimum expectation based on previous PlayStation consoles) and it permeates into other devices, then in 5+ years it will be very common and a lot of people will have experience programming for it.
There is no such thing as "Playstation userbase" which carries over from console to console. Sony have to work hard earn their 50 million PS3s, it's not a "terrible drop from the PS2" because they would normally get the 100 mln PS2 users to migrate.
The "Cell in other devices" argument is a strawman - there's very little to none overlap in expertise, codebases and people between embedded device programming and game development.
The "Cell in other devices" argument is a strawman - there's very little to none overlap in expertise, codebases and people between embedded device programming and game development.
That's a very interesting question. IMHO, not including B/C into a product that consumers are taking for granted of being there can be a double edged sword.
On one side, as you say, if you have a complete B/C in your console and not the new games to grap consumers interest, you may have lack luster sales because consumers will rather be playing the old greatest or be still buying cheap platinum titles (Greatest hits titles in the US) while they wait for all the good new games.
On the other hand, not including B/C will surely have a negative impact on all those who were expecting it, which can result in lost consumer confidence. As Phil Harrison put it at E3 2005 I think, the PlayStation 3 isn't (shouldn't) just a PlayStation that playes PS3 games - it holds the name PlayStation and stands for a brand with more than 10 years of gaming content that is playable. Every consumer that gets a PlayStations knows that the titles they buy will be still playable 10 years down the road on the newer versions - as a result, games hold their value better and are not lost investments. It adds value to an already very high price of a console and makes the whole next generation transition for consumers easier.
The question then becomes: What's better? Loosing that positive mindshare, that confidence you've build up over 2 generations, and perhaps lose a few early PS3 sales, or do you ditch it, taking away the choice for consumers at the expense that they may not adopt the new console as quickly as possible and may even move on to another console instead?
The advantage of offering a new fully B/C console to an already PlayStation 2 owner is not to be unterestimated. After 5-6 years, the old PS2 tend to get old and are close to breaking - a new PS3 that's able to play those games is immensly more attractive than one that can't play them (and the consumer may have to buy another cheap PS2 to still be able to play his games).
A PS3 consumer that doesn't buy games *yet* is still a consumer and potentially will buy new software down the road and is better than one, that hasn't bought one yet (perhaps because of lack of B/C the incentive to buy one is a lot lower).
I'm, sadly, facing the same problem at the moment: I bought a PS3 with semi B/C (European 60GB version) and am quite disappointed with the B/C so far. I have over 20 PS2 games and a lot of them don't work properly.
Cutting R&D says a lot about long term usage IMHO. Especially for the control freaks that Sony are...
I wouldn´t read in to much in the fact that Sony is leaving some cutting edge process research after they sold out some of their chip manufacturing, it is pretty much inline with the intentions Stringer expressed some year ago. Sony is hardly the first company to bail out from low geometry manufacturing because of the huge research costs.
@phil concerning the BC. I am still baffled they removed BC in the 40 GB version, I wonder if it really will stay that way in the coming models or if it´s just a stop gap cost reduced solution until a new shrinked RSX with incorporated hardware BC is introduced. I really hope so because I think BC is a nice feature.
I totally agree.
At the same time, while I doubt the gaming industry will be able to leverage a lot of expertise from other fields working with Cell, I think most development studios will have a good amount of experience with the architecture from mult-iplatform games. So, if PS4 is similar to PS3, the growing pains will be worked out this generation, for the most part.
archangelmorph
Veteran
Why not?
Papers get published all the time on cell software developments & with both Sony, IBM & the open source communities contributing to development research and offering up a wealth of information on the net, I highly doubt absolutely none would be useful to games development nor absolutely no devs would consider inquiring to find out what's out there..
That's true. I just don't think you'd see a lot of people migrating between industries.
archangelmorph
Veteran
Sure of course thats not going to happen.. But individuals moving around isn't the only way information & expertise can be shared as I've already expressed..
- Status
Similar threads
