What are you talking about? I hope you do not refer to the broken Silent Hill HD Collection.
-
Hey Guest. Check out your NeoGAF Wrapped 2025 results here!
Emotion Engine was really powerful ?
- Thread starter Toxa
- Start date
If you're talking about directly porting over the code, then it's not necessarily easy simulating it in the same framework, but I'm not familiar with any particular effects that the follow-up systems simply couldn't do. The PS2 had fewer practical graphic effects at its disposal even among its contemporaries.
I'm pretty sure he referred to the missing effects in some HD collections (*cough* Hijinx *cough*), but that has nothing to do with what PS3 & X360 can actually pull of.
This thread made me go back and watch this awesome VU demo.
http://www.youtube.com/watch?v=ZwD7-bs9hss
http://www.youtube.com/watch?v=ZwD7-bs9hss
That's super impressive. I hadn't known about this contest, let alone what came out of it. I've got some reading to do.
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
1080i mode in GT4 uses a 640x540 fb.
A CPU needs to be good at running game logic, not trying to run T&L plus game logic and be lacking at both.
A system designer didn't even have to spend 220+ square millimeters of silicon at 250 nm in early 2000 in order to have a class leading combination of performance. A superior architecture like SH-4 + ELAN proved that in actual games.
A system designer didn't even have to spend 220+ square millimeters of silicon at 250 nm in early 2000 in order to have a class leading combination of performance. A superior architecture like SH-4 + ELAN proved that in actual games.
KennyLinder
Member
When we were working on Colin McRae on PS2 and Xbox, it was really interesting to see the differences. Xbox could cope with higher res textures and some better effects (for mist on lakes, snow/rain and so on), but when we introduced procedural grass in CMR05, the PlayStation 2 ate it up like a mother fucker. It would keep drawing without a hitch at 60fps (50 for PAL) whereas Xbox really struggled.
Crazy fill-rate abilities.
Crazy fill-rate abilities.
That's amazing.
When you have Kazunori Yamauchi in front of the PD programming group say this in 2013:
.. you have the answer.
http://www.gtplanet.net/gran-turismo-6-pushes-ps3-as-far-as-it-can-go/
.. you have the answer.
http://www.gtplanet.net/gran-turismo-6-pushes-ps3-as-far-as-it-can-go/
Is there a video of that effect around?
KennyLinder
Member
It was incredible, and I think not as nice as when they showed it in GT 2000. Might be misremebering though.
The XBOX spanked the PS2 when it came to GPU and RAM but was the EE the most powerful CPU of the generation, if so by how much?
Anyone know?
Anyone know?
Great post, I guess it explains why mid-tier Japanese development never took off on the PS3 even when it became successful. I know its cool to bash SE around here but they have certainly learned and I hope they pump out current-gen titles (at least for the sake of saving Japanese gaming).
Really interesting old Ars Technica article on Emotion Engine.
from the article's third page
http://archive.arstechnica.com/reviews/1q00/playstation2/m-ee-3.html
from the article's third page
http://archive.arstechnica.com/reviews/1q00/playstation2/m-ee-3.html
The Emotion Engine: Basic Architecture
As was stated above, the Emotion Engine's primary piece of output is the display list. Generating those display lists involves a number of steps besides just the obvious geometry calculations. For instance, if the software you're running is a racing game, then you've got to first calculate the virtual friction between a car's tires and the road (among other things) when the car turns a corner before you can draw the next scene. Or if the game is an FPS, you have to run the enemy AI's path-finding code so you'll know where to place them on each frame. So there's a lot of stuff that goes on behind the scenes and affects the output on the screen. All of this labor--geometry calculations, physics calculations, AI, data transfers, etc.-- is divided up among the following units:
* MIPS III CPU core
* Vector Unit (which is actually two vector units, VU0 and VU1).
* floating-point coprocessor, or FPU
* Image Processing Unit (The IPU is basically an MPEG2 decoder with some other capabilities).
* 10-channel DMA controller
* Graphics Interface unit. (GIF)
* RDRAM interface and I/O interface (for connecting to the two RDRAM banks and the I/O Processor, respectively))
All of the above components are integrated onto one die and are connected (with the exception of the FPU) via a shared 128-bit internal bus.
As was noted in the bullet list, the VU can be further divided into two independent, 128-bit SIMD/VLIW vector processing units, VU0 and VU1. These units, though they're microarchitecturally identical, are each intended to fill a specific role. Toshiba, who designed the Emotion Engine and licensed it to Sony, didn't feel that it was optimal to have three pieces of general purpose hardware (a CPU and two vector processors) that could be assigned to any task that was needed. Instead, they fixed the roles of the devices in advance, customized the devices to fit those roles, and organized them into logical units. In that respect, they're sort of like employees who've been grouped together on the basis of talent and assigned to teams. Let's look at the division of labor amongst the components:
1. CPU + FPU: basic program control, housekeeping, etc.
2. CPU + FPU + VU0: behavior and emotion synthesis, physics calculations, etc.
3. VU1: simple geometry calculations that produce display lists which are sent directly to the Graphics Synth (via the GIF).
4. IPU: image decompression.
Of the above "teams," 2 and 3 are the ones I want to talk about here.
The CPU/FPU/VU0 team
The FPU and VU0 are coprocessors for the MIPS III CPU core. This means that the CPU, the FPU, and VU0 all form a logical and functional unit (or a team, if you will) where the CPU is the primary, controlling device and the other two components extend its functionality. This CPU/FPU/VU0 team has a common set of goals: emotion synthesis, physics, behavior simulation, etc. I'll be going into much more detail on this collaboration in the second half of the article.
There are two main things that bind this team together and allow them to work very closely with each other. The first is the way they communicate with each other: VU0 and the FPU each have a dedicated, 128-bit coprocessor bus that connects them directly to the CPU. That way, they don't have to talk over the main, shared bus. The dedicated 128b bus also gives the CPU direct access to VU0's registers, and allows VU0 to fill its role as a standard, MIPS III coprocessor.
The other important component that ties the CPU core and VU0 closely together is the Scratch Pad RAM. The SPRAM is 16K of very fast RAM that lives on the CPU, but that both the CPU and VU0 can use to store data structures. The SPRAM also acts as a staging area for data, before it's sent out over the 128b internal bus. So the SPRAM is kind of like a shared workspace, where the CPU and VU0 collaborate on a piece of data before sending it out to wherever it needs to go next.
The VU1/Graphics Synth team
The other main team is composed of VU1 and the Graphics Synthesizer (which communicate via the GIF). Just as VU0 has a dedicated bus to the CPU core, VU1 has its own 128-bit dedicated path to the GIF. However, VU1 and the Graphics Synth aren't as closely tied together as are the CPU/FPU/VU0 group. VU1 and the GS are more like equal partners, and one doesn't control the other. You're probably wondering at this point just who does control VU1. This is an interesting question, and we'll discuss the answer when we talk about VU1's architecture in detail.
Putting the teams together
Though the roles of the components were fixed by the PS2's designers, the overall design is still quite flexible. You divvy up an application's work amongst the teams however you like. For instance, the CPU/FPU/VU0 group can generate display lists and do geometry processing in parallel with VU1, so both groups can send display lists to the GIF at the same time.
Or, the CPU/FPU/VU0 group can act as a sort of preprocessor for VU1. The CPU and co. process conditional branches in the rendering code and load data from main memory. They then generate world information that VU1 takes as input and and turns into a display list.
This flexibility allows a developer to customize the process of generating and rendering the 3D environment to suit the needs of the specific application you're working with.
Now that we've gone over the basics of the Emotion Engine's operation, it's time to get hardcore. For the remainder of this article, I'll go in-depth on the MIPS III CPU core, VU0, and VU1. I'll give you the straight scoop on how these components are designed, and how they're integrated with each other. If terms like instruction latency, pipelining, and SIMD make your eyes glaze over, then you might want to check out here. If, however, you're an architecture enthusiast who eats CPU internals for breakfast, then hang on, because what follows is quite fascinating.
Emperor Bohe
Member
No, proof of a shitty ass port. I had to play the game on Xbox too because my PS2 wouldn't read the game for some reason.
The MGS2 developers went to town on the PS2's massive bandwidth. Right in the intro, with the car headlights in the bridge, which are nothing but lots and lots of translucent quads layered on top of each other, plus the rain, plus the depth of field.
The The MGS2: Substance disc was full of technical details about the game. In one of the documents it states that MGS2 uses up to 12MBs worth of textures on screen at once by loading new textures into the 4MB VRAM several times during the same frame. You can also pause the cutscenes and freely move the camera around and appreciate the effects in more detail.
The depth of field, for example, used a brute force approach that made it easily the highest quality DoF until DX11 came: there was no "haloing" because the scene was rendered into three layers (in focus, "far focus" and "near focus") which were blurred independently.
The The MGS2: Substance disc was full of technical details about the game. In one of the documents it states that MGS2 uses up to 12MBs worth of textures on screen at once by loading new textures into the 4MB VRAM several times during the same frame. You can also pause the cutscenes and freely move the camera around and appreciate the effects in more detail.
The depth of field, for example, used a brute force approach that made it easily the highest quality DoF until DX11 came: there was no "haloing" because the scene was rendered into three layers (in focus, "far focus" and "near focus") which were blurred independently.
Most visual effects wouldn't be implemented via brute force multi-pass on Xbox or PS3 due to the inefficiency of such an approach. Their GPUs dedicated logic to proper blending, multi-texturing, intermediate buffering, etc to perform higher quality and higher performance implementations.
Among the greatest benefits of a high fill rate is the capacity for high quality image resolution/definition and texture filtering, but an architecture lacking in bandwidth efficiency that has to store its display buffer in expensive RAM won't actually realize those benefits.
Krazy Ken wasn't ahead of anything as nobody followed his lead on the either the bizarre and needlessly exotic 'emotion engine' or the Cell. Dead end designs both of them.
Yeah, the market had already left those approaches behind. Though, burning the silicon budget on programmability in areas of graphics and processing where higher performance within a more focused feature set would've made for a better return on the silicon invested wasn't so much exotic or bizarre as it was misguided.
All specialized, non general purpose, areas of processing like graphics, video, display, audio, ray tracing, etc emerge originally as algorithms implemented on a CPU. As those types of processing jobs become a significant part of the overall workload, dedicating silicon leads to better efficiency, and that silicon itself only needs to become more generalized once being able to do a wider array of effects/approaches leads to better results than being able to do more of the established set of effects/approaches.
All specialized, non general purpose, areas of processing like graphics, video, display, audio, ray tracing, etc emerge originally as algorithms implemented on a CPU. As those types of processing jobs become a significant part of the overall workload, dedicating silicon leads to better efficiency, and that silicon itself only needs to become more generalized once being able to do a wider array of effects/approaches leads to better results than being able to do more of the established set of effects/approaches.