Xenon don't take this the wrong way, but I find this post annoying as hell.
Have you even been reading the thread?
Don't worry, I won't
I do, however, find it odd that you would even think PSSG was using EDGE, though.
Xenon don't take this the wrong way, but I find this post annoying as hell.
Have you even been reading the thread?
Don't worry, I won't
I do, however, find it odd that you would even think PSSG was using EDGE, though.
Where from this statement: Well, I can confirm right now that PSSG doesn't use EDGE at all.
...did you get that I was thinking PSSG might be using Edge?
Tell you what, why don't you find me an article or interview or something that discusses this mythical 'PSSG,' and we'll take it from there.
(no help from the outside folks)
Rick Roll
Also, why would you bother confirming that PSSG doesn't use EDGE at all? I mean, it's just personally amusing to me that you would even announce this "discovery" of yours. But, then perhaps you really need to understand the creation and evolution of PSSG to understand why I find it so irrelevant.
That's a good article you linked to; I consider it the best there is on the subject. In fact, I had a feeling it would be the one you returned with. Do you know who wrote it?
Here's what I see in you Xenon: arrogance. If you had read back even a two pages in this thread (#169), you wouldn't be in the embarrassing position here of posting an article at me that I myself wrote. But, then again you feel yourself too good for reading more than the page in front of you I guess... Hell, if you'd even read and comprehended the post you yourself initially responded to you wouldn't be here entwined in this discussion, premised on your thinking I said PSSG was based on EDGE when I clearly said the opposite.
And, now you see why my comment to that effect isn't one of 'discovery' either - simply of clarification, with me myself as a source that can be trusted on the issue, through my own discussions with the director of the project.
I've read through you post history Xenon, and you come off like an a**hole; move the attitude up towards 'amicable' a couple of notches going forward from here. And read before you post.
Excuse me? Just because their name is in the credits does not automatically mean they contributed to the creation of the engine in Resistance or the application of any EDGE technologies to the game. Mark Cerny, for example, is a consultant with Insomniac which is probably why he was thanked in the credits.
As you know graphic engines are always evolving and the graphic engine used for Resistance pales in comparison to the current iteration of the engine being used in R&C and Resistance 2. As an example of this evolution, the physics processing power of the engine has improved 400%.
As for writing the article - is that what they call "writing" nowadays? Because it seems it was more of a transcription service than an actual article. I don't mean to be rude, but there's an obvious reason why you went unnoticed in that piece.
Thanks for calling me names, but trust me, the feeling is mutual. As for writing the article - is that what they call "writing" nowadays? Because it seems it was more of a transcription service than an actual article. I don't mean to be rude, but there's an obvious reason why you went unnoticed in that piece.
Dredging up an earlier topic here but more info has come to light. HS sound effects will apparently amount to 10GB of storage.I missed it too.
I do want to point out that real-time surround mixing up to now has always been considered a rather hefty task, and I think Lair (and a few other games) supports 7.1 surround. Now for doing real-time surround stuff, you need to track the location of the sound origin in 3D space and mix all sorts of samples (from say all the different dragons, fireballs, and anything else that makes sounds) into a 7.1 surround sound uncompressed audiostream. While I'm sure that one day this may be reduced to a fraction of an SPU, I imagine it would be easy for the amount of data involved as well as the number crunching involved to take up enough for a development team to dedicate an SPU to it.
Of course, I really don't know anything about this, so I'm also hoping someone with actual experience on this subject chimes in.
The Numbers:
10GB of sound FX, approximately three and a half hours of music, 4,500 lines of dialogue
Hopefully we'll get more info closer to the release date.The Audio Director speaks: "If I could have a metric for how well the game is doing sound-wise, it would be how far I can get through this game with my eyes closed."
SD: Procedural techniques are demanding in terms of power, so the more power you can get, the better it is in that respect. Going multi-threaded is quite easy generally speaking for image-based work (you can divide the image in several pieces and work in parallel), and so the more cores you can get, again, the better it will be.
That said, programming the PS3's eight Synergistic Processing Units (SPUs) can be quite challenging from time to time, but there is definitely a lot to gain from the architecture, and ProFX on PS3 should run impressively fast. (We should get confirmation on that by the end of the year or so
A very cool side effect of the PS3's architecture is that ProFX should be able to continuously stream textures -- using one or two SPUs to compute the textures to be given to the GPU to be displayed, that's a huge bonus for adding rich content to games without having to stream that content from the BluRay or overloading the sole GPU of the machine.
In some approaches that may not be an issue. Procedural dirt seems an ideal solution. GTHD Prologue looks fantastic....but still has repeating ground textures! Creating, or adjusting, grass and dirt textures on the fly ought to be a good use of SPEs without being a hassle to integrate with the rest of the assets. With procedural dirt you can mix up vehicles say, so the one same model doesn't have 8 identical clones, but sufficient variations to look like 8 different units. These procedural techniques are, at east in theory, straightforward to implement, unlike procedurally generating 'ordinary' diffuse colour textures where design is an issue.Procedural textures are an ideal fit for something like SPUs; unfortunately, they present enormous art production difficulties.
Procedural textures are an ideal fit for something like SPUs; unfortunately, they present enormous art production difficulties.
Worked well enough in Roboblitz (50mb XBLA game on UE3)
There's different types of procedural synthesis. One is to record the artist's actions in a graphics application as a super-macro, and then repeat the same graphics functions at runtime to generate the texture. eg. Record the points of a beizer curve and fill gradient settings set by the artist, and recompose into a texture.The art production difficulties I'm talking about aren't something you can see from the finished product; it's the problem of replacing texture artists, who are used to painting freehand in Photoshop, with something like "texture programmers" who can decompose a target (painted) texture to a series of mathematical operations.
The art production difficulties I'm talking about aren't something you can see from the finished product; it's the problem of replacing texture artists, who are used to painting freehand in Photoshop, with something like "texture programmers" who can decompose a target (painted) texture to a series of mathematical operations.