Why does Sony create such wacky architectures?

I was talking about DoA2 on Dreamcast versus Japanese Tekken Tag Tournament built specifically for PS2, both which came out around March of 2000.

I found this kind've funny since TTT was a PSX (or more specifically a Model 12) port... While there were some definate improvements it *was* a rather quick and dirtry port (especially the Japanese release)... (Kind've funny if you think about it, Soul Calibur was also originally a Model 12 game)

The one that's difficult to program

Crazy already addressed most of this, but just to go on a bit more. As far as abstraction goes it's actually even easier to do high-level abstraction on a console since it's not an evolving platform (especially if you're focussing on a single platform). Once you come with your high-level environment, it's pretty easy to start cranking out games on it. As far as performance goes, with each successive release (and or simply just more time spent tweaking the environment) you can optimize the snot out of the backend without changing too much of the front-end that designers and artists (and to some degree some programmers) will work with). EAGL, GOAL, Sqeak/Squak would be some examples (PS2)... Of course you've got massive abstraction environments like Renderware and Alchemy...

So how was Madden released shortly after launch?

Some studios (due to size and relationship) will get more attention focussed towards them. That, and they could have programmers fluent in Japanese, or just hire translators...

I thought that Triangle Set-up would have limited polygons/s figures before we became T&L limited... even assuming 75 MVertices/s, VU0 and VU's max is well above 80 MVertices/s ( of course they would not fit in the GIF-to-GS bus, still I thought that Triangle Set-up came to be a bottleneck before T&L... )

Very few do much with VU0 in micro-mode (especially running transforms in parallel with VU1). Also, I'm not sure what you mean by "not fitting in the GIF/GS bus"... The GIF does have a 256-bit FIFO and allows you to pack all coordinate data down quite nicely. Besides VU0 has more limited options regarding data paths and the GIF automatically prioritizes data based on path source...
 
I think VU0 should be used more in micro-mode... I think a good chunk of power lies in maximizing VU0 performance...


What I meant is this...

1.2 GB/s, 80 MVertices/s * 20 bytes ( X, Y, Z, W + color ) = 1.56 GB/s

VU0 + VU1 in theory should be able to crank up to 102+ MVertices/s ( ~42 from VU0 and ~60 from VU1 )... the GIF-to-GS bus is 64 bits wide and running at 150 MHz ( as you very well know ), thus yelding 1.2 GB/s...

Even admitting to only send 12 bytes/vertex ( X, Y, Z cordinates ) the GIF-to-GS bus gets maxed before reaching 100 MVertices/s...
 
also, doesnt the VU0 have access to VU1's registers and micro-memory through a directly connected bus ( not the EE's FSB ) ? ( regarding the GIF path comment you made )...
 
I used to believe in the CLUT talk but as time passes, i have yet to see a PS2 game with Sonic Adventure level of vibrant textures. :cry:

T4 and MK has nice clean textures, but never the vibrancy of a DC game. It is like you can easily tell a PS2 textured games from a DC textured one. THough, i prefer PS2's dullish textures on more realistic games, but i do wish for the lively richness of DC vibrancy textures, on more cartoony games.

Oh well, at least the PS2 has MOTION BLUR! The last greatest thing before bumpmapping! :LOL:
 
I generally prefer polygons over DC style textures ( good detail texturing helps the texturing arguments though )... with only high resolution textures, the instant you get close to an object... puff there it goes all the faked 3D detail of the surface...
 
R&C and Sly Cooper look dull with PS2 texturing. :( You can push up the polygons but they still look unfitting on them.
Games like those NEED SA textures! :oops: And dont start posting SA screenshots meesasays, you NEED to see it in motion to appreciate the texturing.
 
Yesh yesh, but lets take R&C for another example.
The texturing is both dull-washed-out-dead, too close and too far to the surfaces. :p
 
Lazy8 said:
I was basically referring to the apparent number of sources and how smooth its variance was over the characters. Neither game really flaunts anything out of the ordinary resulting from lighting calcs like self-shadowing or anything (that I remember).
Even with other things even, TTT chars add gloss/specular maps, which is rather obvious even in those crappy screenshots posted a bit back.
Environments are pretty much prelighted in DOA2. TTT at least does floors dynamically.
Considering you're one of the people that always points out perceived VF4->VF4 light source count reduction, I would expect you to notice something that is visually even more obvious immediately... ;)

PCengine said:
Of course all architectures would benefit from low level coding and micromanagement
Blah... he wasn't talking about little "benefits". The difference in performance between XBox properly utilized and the way some launch titles did it can be in order of magnitudes.
DC's SH4 is just as problematic with caching and memory access issues as PS2 R5900, with one difference - PS2 cpu doesn't do geometry transforms, while DC one DOES, so your chances of subpar performance relative to what platform is capable are even better in some ways.
And GC isn't devoid of situations like that either, in any applications that don't rely strictly on static geometry and need CPU intervention (mostly stuff with characters really). I wouldn't be surprised if most 30fps GC titles early on were CPU limited.

Panajev said:
20 bytes ( X, Y, Z, W + color )
Color+Position is not 20bytes Pana.
And the bus must be wide enough to sustain the GS primitive setup, more then that would be redundant with untextured primitives.
If you browse through your EE docs, you can find the byte counts for GIF packed vertices, and you can also quickly see that they are within Bus limits.
 
My EE docs ??? /me whistles...


aaah those.... ;)

Fafalada, the 20 bytes number was just a speculation of mine... 32 bits for each cordinate ( X, Y, Z, W ) + 32 bits for color... even admitting 12 bytes vertices you cannot send them at 100 MVertices/s rate as that would assume that the GIF-to-GS bus' efficiency is 100 %, please correct me if I am wrong...


Still GS's triangle set-up engine should become a bottleneck before bandwidth is an issue... IMHO
 
Seriously, IMHO, if you also want to send a decent amount of textures ( nice quality even one single layer ) you will end up with not enough GIF-to-GS bandwidth to max out VU1+VU0's transform rate... am I wrong ?
 
R&C and Sly Cooper look dull with PS2 texturing.
R&C are a bit on the color muted side, but Jak & Daxter look almost too vibrant IMO. All that contrast is unhealthy if looked at for too long. Same goes for many Sega games. They burn your retinas :)
 
VU/GS limits...

Hi Pana,

Go to the PS2 linux site, you can download code and look at the operations even if you lack the documentation...

Sonic is a good game - but I think Klonoa had a nicer look on PS2... and it ran at 60fps rather than 30fps.

It would be nice to see a conversion to PS2 a la Gamecube version, though.. ( Although at that point everyone will pore over it to find any differences, and proclaim them undisputable evidence of hardware inadequacies..... ) Developers are trying to cram more and more into games nowadays - I think if I limited my polybudget ( in terms of draw distance, model complexity, animation, and memory ) to the SA1 level I could easily cram in the same detailed textures found on the DC. However it may be more difficult to match textures with GC or Xbox because there is less memory....
( I remember all of the original posts about the Chaos monster in SA - with the wonderfull transparencies and water particle effects, and how they turned out to be CG, and the realtime stuff was a great letdown even though it was technically OK. With the PS2 early titles like The Bouncer and Driving Emotion Type S I didn't have the same letdown factor as the realtime graphics were impressive, even though the Bouncer contains many CG scenes, and DETypeS caused several temper sessions before I completed it... )
 
Seriously, IMHO, if you also want to send a decent amount of textures ( nice quality even one single layer ) you will end up with not enough GIF-to-GS bandwidth to max out VU1+VU0's transform rate... am I wrong ?
Pana, if you're doing just the simplest of transforms, perhaps. Otherwise it's very unlikely.

chap said:
i have yet to see a PS2 game with Sonic Adventure level of vibrant textures
Go play CrashPS2 Chap, particularly some of the latter levels. The game not only mirrors SA in color department, it adds extra burns to your eyes with a bunch of dynamic light effects (disco colored of course), which SA is pretty much devoid of.
 
With the PS2 early titles like The Bouncer and Driving Emotion Type S I didn't have the same letdown factor as the realtime graphics were impressive
Yup yup yup! I knew that since day 1! :p Bouncer graphiX > 99% of other PS2 games graphiX! :oops:

Faf,
No Crash and not intending to get one. But anyone would have expected games like Sly Raccon to spot nice vibrant textures. Oh well....




A little OT, but just how cool is the much fabled Performance Analyser supposed to be?

I been playing Getaway and Primal(the 2 SCEE games to "benefit" from the PA) Demo and well....i hate to say this....but they hardly look any better than current PS2 games. :? Very very ordinary looking PS2 games, very much like a PS2 game you expected. :oops:

So how now Archie, Faf and fellow friends at Sony :?:
 
Since someone brought up SA, SA2 ups the framerate to 60. SA was a first gen game too ;)

And I totally agree about the Getaway comment. I was expecting awesome cityscapes etc., but when I saw it in motion on TechTV's Extended Play, I was like ewwwww. Just goes to show how much of an impact hype can have on people. :LOL:

I was pretty amazed at that Harry Potter game for GCN even though I'm not a HP fan. It has some very nice graphics.
 
Back
Top