Ikaruga

[Tagrineth]

Saturn can push 1,000,000 polys, however, by todays standards the sacrifices made to do that would not be acceptable. the only effects really used in Saturn Shenmue were textures, and the game ran at about 15 fps in low-rez.

Saturn Shenmue doesn't look that great imo, it's just the fact that the artwork looks so incredibly close to the DC version and the size of some areas shown (like the warehouse) look neat - but the video is really dark and you can't really see just how much is filling the warehouse. For all we can see it's just a giant roof.

As for Saturn VF3 AM2 using the latest and greatest Saturn development system (SGL 3.02 i believe it was called) was able to get a graphically near perfect port. few sacrifices were made, it ran at 30 fps in low-rez, and a few other small details were removed from clothing. The 64-bit upgrade card was originally required for this game but AM2 using SGL 3.02 found that the Saturn was far more powerful than originally thought running VF3 at 750,000 polys.

Judging by the screenshots at that site linked earlier, it is certainly not graphically near perfect.

And we've gone from 1M to a much more realistic 750K... what's your next downgrade?

One reason the Saturn can do this is that the Saturn doesn't use triangles for graphics like the PS1, but uses squares, this is also why the Saturn got crappy PS1 to Saturn ports.

Actually, you should say it uses Quads, not squares - squares would be INSANELY limited from a 3D graphics standpoint. 😉

And Quads take MORE calculation than triangles, sweetie. The point is, you can get away with fewer Quads than triangles in a given scene, and get the same look.

SGL 3.02 made it easy to develop Saturn games, in addtion unlocked an enourmous amount of possibilites with the capabilites of the Saturn. unfortunatly the it came out too late, and the Saturn was discontinued in Japan. Only a few games began development on SGL 3.02, and only VF3 was finished. The final gold copy was done and sent to the plant for mass production, but SEGA Japan at the last minute decided to cancel the game because they were afriad it might hurt the DC version VF3tb (this version wasn't even done by AM2, and why it's not arcade perfect).

I somehow doubt it was made "easy" but probably a LOT easier than it used to be. I mean, damn, if SGL 3.02 was such a 'Miracle Potion', why didn't they try and at least get that last round of games to appear? >_>

Well now you know the Saturn was far better than expected once all processors were put to their true potential. And maybe the N64 is also capable of more, but not the Playstation.

I already knew the Saturn was better than expected. In fact, I tend to expect a lot from heavily multiprocessor environments - the right coding practices can result in CRAZY benefits. Same with great art direction. Just look at Panzer Dragoon Zwei, PDS, and Duke Nukem 3D/Quake... (<3Lobotomy<3)

well first off you're right, the recent PS2 games do look better than most DC nearly all DC games, but also the PS2 developers have had time to learn it better. The DC's lifespan was far too short, and the games that are still coming out don't really test it's 3D capabilities.

Um... ok? I somehow doubt that. DC is a lot like PS1, and PS1, while it did improve quite a bit over its lifetime, didn't suddenly look worlds better than N64 (for example, Quake2 looks better on N64 than on PS1, and that's a pretty late game).

About 300Mhz, a max of about 10,000,000 polys (with all effects on), 32MB of RAM, 4MB of VRAM, no texture compression, anti-alising only at software level

10M polys with effects? That's a lovely load of crap. If you're going to immediately go on to list the maximum for PVR2DC's setup engine, which the SH-4 can't possibly keep maxed out, then at least be more "realistic" with your PS2 estimate. I'd put a number probably closer to 25,000,000 to maybe 30M as a theoretical 'in-game' max. Games are already pushing 15-20M today, and there's still plenty of room to improve (apparently only like 1% of PS2 games use VU0 in micro-mode AT ALL).

PS2 also has texture compression, though it's more limited - 4- and 8-bit CLUT. PS2 is much more complex than you make it sound, sweetie.

And finally, the anti-alisaing isn't "software", it's simply "Ordered-grid supersampling". INCIDENTALLY THE DREAMCAST USES THIS SAME METHOD. >_>

200Mhz, a max of 8,003,000 polys (with all effects on), 16MB of RAM, 8MB of VRAM, 5:1 texture compression ratio, anti-alising at hardware level (better)

200MHz processor with only ONE part, compared to PS2's 300MHz with three processors - AS YOU ALREADY POINTED OUT, MULTIPROCESSOR ROCKS.

8,000,000 is the maximum the PVR2DC's setup engine can process for rasterisation. There's simply no way the SH-4 can keep crunching THAT many polys. The most any game managed was Test Drive Le Mans, at ~4-5M peak... a far cry from your 8M number. Oh, and the 8M number is with no effects - it's the highest the GPU can accept already-transformed polys. You do a good job sounding like you know what you're talking about, but you don't. >_>

Hell, you don't even get the compression ratio right. VQTC can easily run 8:1 compression.

And anti-aliasing "at the hardware level" doesn't do shit if you have no extra fill rate to work with (PowerVR cores are NOTORIOUS for having puny fill-rate but awesome efficiency), and especially doesn't help if you're USING THE SAME METHOD.

I repeat. Dreamcast and PS2 use the same method to perform AA. DC has a better scan-out filter and a much better output format (VGA 640x480, woot), though.

The PS2 is faster (Mhz) and can build larger levels with more on screen (RAM and polys), but the DC is not far behind in those aspecs, and can produce 10 times as many textures (VRAM, and texture compression), in addtion the graphics get cleaned up better with anti-alising at the hardware level.

The PS2 isn't only faster in clock speed, it's also using a CPU that's a tad more efficient (MIPS > SuperH, thank you very much), and has TWO, count 'em, TWO vector units chugging along with it.

DC can't produce ten times as many textures, because PS2 can perform almost as efficient texture 'squashing' with CLUT (4-bit vs. 2-bit - at this point, it's up to the artists to use the available colours effectively), and keep in mind the GIF-to-GS bus that is insanely low-latency and runs 1.2GB/sec - enough to refill PS2's VRAM over, and over, and over, and over, and over, and over, and over, and over again... and still barely tap the bus. It's a shame it's so hard to get the transfer timing right (according to some guys at Naughty Dog - see also Jak II as proof it's possible).

And... once again, how the rasteriser achieves the AA process is irrelevant if both cores are using IDENTICAL methods. It's especially irrelevant when one of them has more than TEN TIMES the fill-rate of the other one.

I don't think it's too fair too call one better than the other in terms of power, they should be judged by the games that you like.

I have to agree here, it's best to judge a system based on games, but to say Dreamcast can compare to PS2 on a pure hardware level... is foolish, now that PS2's architecture has preeeeetty much proved itself, much like Saturn was -JUST- short of doing.

The only way Dreamcast can compare to PS2 from a hardware standpoint is when the artists pull off creative, spiffy stunts.

Oh, and don't you ever fucking dare baby me like that again.

 

[it290]

Wow.. this conversation has certainly sunk into the depths of console spec depravity.. Tagrineth, I'd like to see you argue SNES vs. Genesis sometime (although there's much less to discuss from a technical standpoint, that argument is always more fun).

Anyway, just thought I'd add:

And Quads take MORE calculation than triangles, sweetie. The point is, you can get away with fewer Quads than triangles in a given scene, and get the same look.

From a graphics/modelling standpoint, quite a lot fewer, actually. Usually it takes 2-3 times as many triangles vs. quads to produce the 'same' geometry. Also, quads are far better for creating most shapes, especially organic ones. It's _very_ difficult to model a realistic human head using only 3-point polys, for example, and your end result will likely look pinched or puckered in many places compared to the smooth effect created by quads. In fact, quads are so much easier to use in general that I've never really understood why most video chipsets and game engines rely exclusively on triangles. Is it really that much more efficient from a pure hardware/theoretical software standpoint, or is it just how the APIs have been written? If the difference in performance isn't that great, I can certainly imagine everything moving to quads (and other polys while we're at it, but still supporting tris when necessary), in the future when realtime 3d graphics have moved to the level where sacrificing a little performance will be considered acceptable in exchange for a gain in artistic freedom.

 

[ExCyber]

Tagrineth, I'd like to see you argue SNES vs. Genesis sometime (although there's much less to discuss from a technical standpoint, that argument is always more fun).

Agreed. 🙂

In fact, quads are so much easier to use in general that I've never really understood why most video chipsets and game engines rely exclusively on triangles. Is it really that much more efficient from a pure hardware/theoretical software standpoint, or is it just how the APIs have been written?

AFAIK, it's a difference in the fundamental rasterization theory, and boiling things down to the simplest unit that can be treated consistently for all possible variations. As I recall, a (non-clipped) triangle can always by drawn by essentially the same rendering algorithm no matter where you put the vertices, while a quad cannot. As you design a piece of hardware, every additional case you have to treat differently adds complexity, expense, delays, and quite possibly bugs.

 

[Tagrineth]

Tagrineth, I'd like to see you argue SNES vs. Genesis sometime (although there's much less to discuss from a technical standpoint, that argument is always more fun).

Agreed. 🙂

Gimme a couple weeks to learn more of Genesis's hardware and I could do it. :>

AFAIK, it's a difference in the fundamental rasterization theory, and boiling things down to the simplest unit that can be treated consistently for all possible variations. As I recall, a (non-clipped) triangle can always by drawn by essentially the same rendering algorithm no matter where you put the vertices, while a quad cannot. As you design a piece of hardware, every additional case you have to treat differently adds complexity, expense, delays, and quite possibly bugs.

Bingo.

There's also the artist's POV.

When you shift the vertices of a quad, you get a curved surface. Unfortunately, that curve isn't -technically- there, so you have to work your collision detection around it. Then you have the problem of not being entirely sure how different render engines will draw the curve - can you be certain that the curve will be convex? What if the renderer has a bug which causes the curve to be concave?

Then you have filtering... from what I understand, filtering textures across multiple quads is insanely painful, at least in all attempted implementations of the technology.

And finally, please notice that all quad implementations have had no Z buffer. Can anyone tell me how well you can render quads _with_ a Z buffer? How do curves react when you actually know where everything is in 3D space?

Basically one of the biggest reasons triangles are most commonly used is, 99% of the time you can load three vertices and be guaranteed exactly one triangle between them, with no possible variance between architectures and renderers.

Addendum: Easier way to understand this: Quads: Easier on hardware, hell for developers.

 

[it290]

Ahh. Well that certainly makes sense about the 'simplest implementation' thing.

Shifting the vertices of the quad: well, as I understand it, generally the curve degree is simply interpolated from the position of the four vertices - obviously, this requires additional calculation, but I don't forsee any reason why implementations would vary much at this point. Not to mention that collision detection doesn't seem to be a real big deal in most of today's games anyway.

Concave/convex: Again, this could be something that could be pretty standardized. In most cases the engine should be able to figure it out, and if not, you could have two additonal datasets - the first one defining which side is the face of the polygon, and if it should be doublesided, and the second holding something that Lightwave called 'vertex weight' - which defines the amount of influence each vertex should have in influencing the shape of the polygon. I could see these impacting realtime performance by some small degree, but mostly they would have a (still slight) effect on loading geometry.

Filtering/Zbuffer: No idea, although I don't understand why filtering would be that much harder to implement. I also have no idea what kind of algorithms

are involved in filtering, so color me silly.

It seems like the biggest problem involved with handling quads is the curve aspect, but again from the artist's POV that is the biggest advantage. Given that most games these days are ~70% media, 30% code, that still seems like a worthwhile tradeoff to me.

 

[ExCyber]

The thing is, you're now talking about implementing a rasterizer for higher-order 3D surfaces. Quads and triangles are pretty much two-dimensional (plus a perspective correction vector IIRC) in conventional rendering engines - geometry setup "flattens" the scene into renderable 2D primitives before anything even touches the framebuffer. This is the context I'm talking about. It turns out that even if you come up with a general algorithm to rasterize quads, it tends to be faster and simpler to simply split the quads into triangles and then render those...

edit: and if you're wondering why Hitachi/Sega decided to go with quads in this case, you're not alone. My best guess is that for rendering warped sprites/bitmaps, the algorithm becomes simpler to deal with for quads (for which it's essentially a rotated scanline copy) than for triangles (for which you have to deal with scaling/rotation ambiguities between the two halves of a sprite).

 

[AntiPasta]

Doesnt the Saturn draw textured quads using the sprite engine? So basically textured quads are actually distorted sprites, and as far as I can see there's no point in having sprites with 3 vertices 😛

I recall that this is exactly the opposite thing the PSX does, it draws (scaled) sprites using textured quads, which consist of 2 triangles (which seems to have some nasty side effects).

Note: this was all done from vague memory on a tired morning, sue me 🙂

 

[it290]

Hmm interesting. I guess I just don't really understand from a mathematical point of view why rending tris is that much more efficient. WRT to the curve thing, aren't there engines out there that support curves from triangles already (Quake 3 for example does this without much performance hit IIRC)? I suppose by having the engine handle it, it allows the precision of the curve rendering to be adjusted more easily, but it seems the same could be done for quads overall. Again, certainly not faster, but the results could probably be prettier, IMHO.

 

[ExCyber]

Doesnt the Saturn draw textured quads using the sprite engine? So basically textured quads are actually distorted sprites

Or distorted sprites are just texture-mapped quads.

Anyway, now that I think about it, rendering quads and triangles shouldn't be radically different aside from dealing with concave quads (which, strictly speaking, is optional; you can just let those fall where they may with an algo designed for convex...).

edit: this is not to say that the two are equivalent overall, just that the low-level rendering details are probably similar - it's probably still simpler to break down higher-order surfaces into triangles rather than quads (consider, for example, the complications inherent in making a "quad strip" or "quad fan").

 

[M3d10n]

Originally posted by it290@Dec 16, 2003 @ 04:58 PM

WRT to the curve thing, aren't there engines out there that support curves from triangles already (Quake 3 for example does this without much performance hit IIRC)? I suppose by having the engine handle it, it allows the precision of the curve rendering to be adjusted more easily, but it seems the same could be done for quads overall. Again, certainly not faster, but the results could probably be prettier, IMHO.

Now you're confusing things. Quake 3 does not render curves. It's an OpenGL game, your video card wouldn't know what a curve is even if you hit it with one.

The curves you're talkiing about here are stored as mathematical curved surfaces. A curve is described as a equation, and that equation can be used to find points across the curve's surface, and THEN you can dynamically add more or less polygons to that.

The "curves" in (some) quad rendering engines are not that kind of curves. They are often not really intentional and theres not much control on how they'll look like (from the artist's standpoint). There was a post a while ago about that, and there were a few images. Basically, in a scanline rasterizer, having a concave quad results in the scanlines being rendered past the concave edges by a few pixel (this can be seen in the Saturn), and it'll produce a "curve", that is rendered outside the quad area.

It's not like you have free NURBS just by using quads. The curves are only visible in VERY specific situations, and sometimes they are not perceived (recently I gave Sonic JAM a run to see if there were any non-coplanar vertices in the 3D world - and there were some - but I had to look carefully to find them).

And to however said that quads provide better (organic) models... fer god's sake! You'll need TONS of polygons if you want something to look organic by using only co-planar quads! It always looks boxy. It is more confortable to *begin* modelling with quads (very few have the guts to go straight into triangles - like ID is doing with Doom3), but trinagulizating the model and tweakening the vertices afterwards can do wonders to your 3D model, since after it's triangulized you can drag the vertices wherever you want without worrying about non coplanar faces.

 

[it290]

Now you're confusing things. Quake 3 does not render curves. It's an OpenGL game, your video card wouldn't know what a curve is even if you hit it with one.

Yeah, I understand the video card doesn't care, that's what I meant by the engine being able to control the precision. As in the case of quads, it doesn't make much difference from an artistic perspective whether they're supported by the engine or directly by the hardware.

The "curves" in (some) quad rendering engines are not that kind of curves. They are often not really intentional and theres not much control on how they'll look like (from the artist's standpoint). There was a post a while ago about that, and there were a few images. Basically, in a scanline rasterizer, having a concave quad results in the scanlines being rendered past the concave edges by a few pixel (this can be seen in the Saturn), and it'll produce a "curve", that is rendered outside the quad area.

Hmm, I think I saw that thread.. the images were from Nights, right? I can see how the results of that type of engine would not really be something that is defined beforehand, but I think they potentially could be in this day and age and with a few extra parameters added to the data. Not 'free NURBS' but maybe something more like 'controllable realtime subdivision surfacing'.. most engines already perform some type of surface smoothing by default, UT2003 being a good example.

And to however said that quads provide better (organic) models... fer god's sake! You'll need TONS of polygons if you want something to look organic by using only co-planar quads! It always looks boxy. It is more confortable to *begin* modelling with quads (very few have the guts to go straight into triangles - like ID is doing with Doom3), but trinagulizating the model and tweakening the vertices afterwards can do wonders to your 3D model, since after it's triangulized you can drag the vertices wherever you want without worrying about non coplanar faces.

Well, the distinction comes into play moreso on higher poly models not found in today's games, that's true. That's why I'm talking about future applications, and not using _only_ coplanar quads.

As for starting your (low poly) models in tris or quads, it seems like most are split on this issue - it's mainly a matter of preference. The people who seem to prefer using only triangles from the start are those who only do low-poly modelling, which is understandable. I tend to use mainly quads, but just use whatever works best in a given situation, eventually going in and converting (mostly) everything to tris by hand, as I feel the software doesn't always make the best choices in this regard. I always tweak during and after this process, of course, but a good part of that is oriented towards getting good UV seam placement, and not specifically tweaking the geometry.

 

[Tagrineth]

Shining Force III is a good example of severe abuse of curvy quads, though it is hard to see specifically. The terrain just looks good, despite being obviously poly starved.

Panzer Dragoon Saga seems to use them a bit for morphing your dragon, too.

Edit: Oh, and the reason Saturn uses quads for 3D - the system was never truly intended for 3D games. It was meant to be the evolution of 2D, IIRC... and the 3D engine literally just borrows the 2D engine. Quads are the most logical step up from the old 2D methods used in dedicated 2D systems like SNES and Genesis.

 

[ExCyber]

Oh, and the reason Saturn uses quads for 3D - the system was never truly intended for 3D games.

AFAIK, this is a myth - all signs I've seen point to the Saturn being built as a powerhouse 2D/3D hybrid machine, which is exactly what VDP1 is suited for. To believe that Saturn was not intended for 3D, you'd have to believe that Sega didn't want to capitalize on their own arcade games, as their primary successful franchises were 3D at the time. Furthermore, the SCU DSP is severe overkill for a 2D system, especially with the presence of a second SH-2. Some people like to tell the story about how late in the "Saturn" development process, Sony demoed the PSX and blew away Hideki Sato, who immediately bitched out the Saturn dev team. In the popular version of this story, they tacked on an elusive "3D chip", creating a halfassed solution. In my pieced-together "Dead Sea Scrolls" interpretation (which is almost certainly not entirely accurate, but fits the known facts a tiny bit better), they essentially scrapped the console they were working on (the so-called "Giga Drive", more or less a home hybrid of the Model 1/2 and System 32 hardware bearing little resemblance to the Saturn), pulled everything they could for a killer playfield generator from their arcade designs, cut a couple sweet deals with Hitachi for a large chunk of the VDP1 engine and fabrication of almost every non-memory chip in the console (the ones they didn't make could probably be counted on one hand, including stuff on the CD board), and worked a bunch of 16-hour days to put the pieces together before their scheduled launch. As a result, there was no time for cost-cutting and no time to refine the dev tools, resulting in a console that was too expensive (Sony slaughtered them on this by launching PSX at $299 - the story goes that "Two-hundred ninety-nine dollars" was the entirety of their announcement at the trade show where Sega announced the early Saturn launch) and had zero third-party games at launch.

the 3D engine literally just borrows the 2D engine.

All rasterization is effectively done by a "2D engine", same as PSX and N64. The only thing that could reasonably be called a 3D engine is the hardware available for geometry setup, a role represented in all three systems by a core that's ridiculously overkill for 2D (SCU DSP, GTE, and RSP respectively).

 

[SEGAFan 3000DC]

yeah, it was definitly quads, i wonder how i forgot that and where squares came from, oh well.

I stand firm on what i said the Saturn can do, this is backed up by AM2 themselves in interviews and are the ones who stated the numbers 1,000,000 and 750,000 for their own games, not i.

as for Tagrineth's arugument on the DC vs. PS2, GET REAL!!! you have to be a ps2 fanboy or just plain ignorent if you expect me to believe that! the ps2 can do 10,000,000 polys when maxed out in a game such as Gran Turismo 4, TechTV labs also confirmed this. also both ps2 and DC get their asses kicked in the graphics department by the GC and Xbox which can only push 12 million and 16 million. No game made the DC go to 8,003,000 this was done with a tech demo after the DC was dead in the US and Europe. however for this to work in a full game and not a 5 minute demo is very realistic because that is probably what AM2 felt they could do an accurate VF4 to DC translation. Yu Suzuki said he would do it if the DC could handle the game with little to no sacrifices needed for the translation. later this prooved possible and all that was left was the green light from the top SEGA executives, but they never gave it. the original VF 4 did not take full use of the Naomi 2's 10,000,000 but did run over 8,300,000 so thier would have been some graphical loss but not much. the tech demo is the only real proof out there that the DC can do the high polygon count so go look it up! oh and just to let you know even after the DC died SEGA did make a revision of the DC's poly stats, and changed it to 7 million (this of course was before the tech demo was shown, and it's not an official demo by SEGA either).

 

[M3d10n]

Never heard of that demo. Keywords too loose for google, I guess. Links, please? While I do believe the DC can do 7M polygons per second, I think most games were FAR from that... I'm not sure it can stream that many polygons into the videocard.

Do some math. 7 million polygons means 166,667 polygons running at 60fps, and the double of that at 30fps. Anyone who works getting their eyes sore by dealing with polygons everyday can tell that not even DOA2 nor Shenmue 2 get close to that. From the polycounts I'm getting at the game I'm working on, I'd say that Shenmue2 keeps something between 12K to 16K polygons on screen at once (total polycount for a walkable area might be WAY higher than that, tough).

The bandwidth is a strong bottleneck in the DC, and one needs all sorts of culling schemes to minimize the amount of data sent to the video card per frame. Culling can keep the CPU pretty busy, and it also needs to apply the transforms to all vertices before uploading it to the videocard, and do some extra work if vertex/bone animation is involved.

I'm am not a PS2 fanboy, and was a major DC advocate, and I must admit that I have a hard time wondering if some of the lastest PS2 stuff could be done in the DC. The amount of on-screen geometry in some games is blatantly superior to anything I ever saw the DC produce, along with good framerates. I also often see the PS2 do stuff at 60fps that I'd expect the DC do at 30fps.

Of course, most PS2 games have obviously inferior texture resolutions, or repeat textures far too much. And I find the view of a higly blurred texture destroys the coolness of a well-tesselated character model, but, who would guess that one of Sony's marketing blabbering was actually true: the memory bandwidth *is* fast enough to allow the game to upload textures into the VRAM *while* rendering, and still retain high framerates. A few games recently are making use of this trick, since it's obvious they display a sheer variety of textures that could never fit in tiny 4MBs.

Maybe screens or even a video of that dreamcast demo can sheer me up, but usually demos lack lots of the stress an actual game needs.

 

[ExCyber]

Quads are the most logical step up from the old 2D methods used in dedicated 2D systems like SNES and Genesis.

Didn't notice this part before, but the methods used in dedicated 2D systems look very little like any framebuffer-based rendering engine. They generally use shift register / FIFO type memories that are loaded once for each scanline and triggered by a counter to implement pixel-precision X axis positioning. The size of these memories determines the size of the palette and the number of sprites per scanline. This is why a lot of horizontal shooters get butchered and/or have awful sprite flicker on older consoles, which can typically only load 4 sprites per scanline.

Conceptually, quads may be the logical next step, but if the implementation were derived from old-school playfield/sprite chips even decent Model 1 ports would probably have been out of reach.

 

[SEGAFan 3000DC]

actually M3d10n, my last post was directed more toward Tagrineth

I can't seem to find the place where i found the link myself anymore, any help to help me as well as those here to find the link to the info on the demo would be much apprciated. I don't remember the video being avalible for download, only a description from the people who did it and some pics (i think) anyway i remember the description stating that it was a large city with cars racing around and all DC able effects on running at 60fps at 8.003 million polys per second.

Also i'm glad you can see that the DC can handle textures better than the PS2.

 

[Tagrineth]

I stand firm on what i said the Saturn can do, this is backed up by AM2 themselves in interviews and are the ones who stated the numbers 1,000,000 and 750,000 for their own games, not i.

Yeah, and Sony claims 20M Polys per second on Jak II. Do you believe that?

as for Tagrineth's arugument on the DC vs. PS2, GET REAL!!! you have to be a ps2 fanboy or just plain ignorent if you expect me to believe that! the ps2 can do 10,000,000 polys when maxed out in a game such as Gran Turismo 4, TechTV labs also confirmed this.

Ooh, I'm a PoS2 fangirl now, am I? Hahaha, how utterly laughable.

TechTV labs blah blah blah why should I care what TechTV came up with? TechTV is full of shit! How can they claim GT4 "Maxes out" the PS2? Even Polyphony Digital and Sony (the game's CREATORS) don't claim the game maxes the hardware out, by any means.

Oh, and YOU SAY YOURSELF a few lines later that VF4 uses ~10M in arcade, well GUESS WHAT, the PS2 version of VF4 is quite effectively ARCADE PERFECT. And it doesn't max the hardware out either. YOU CANCELLED OUT YOUR OWN ARGUMENT, THANK YOU VERY MUCH.

also both ps2 and DC get their asses kicked in the graphics department by the GC and Xbox which can only push 12 million and 16 million.

ERP at Beyond3D, a former employee from Boss Games, said his own Xbox engine was pushing 30 Million polys per second. Thanks, have a nice day.

And if you think PS2 gets its ass kicked completely by GC/Xbox, I get the distinct impression you haven't ever seen or played Silent Hill 3?

No game made the DC go to 8,003,000 this was done with a tech demo after the DC was dead in the US and Europe.

Tech demos != games. Tech demos overpower games ON A REGULAR BASIS, because guess what, they don't do half as much work as any game in existence. They're pretty much designed to get peak graphics performance, period.

There's at least one tech demo I know of for PS2 that pushes a good 25+ Million polys and totally destroys anything I've ever seen on Xbox/GC. I could send it to you if you give me an e-mail address.

however for this to work in a full game and not a 5 minute demo is very realistic because that is probably what AM2 felt they could do an accurate VF4 to DC translation. Yu Suzuki said he would do it if the DC could handle the game with little to no sacrifices needed for the translation. later this prooved possible and all that was left was the green light from the top SEGA executives, but they never gave it. the original VF 4 did not take full use of the Naomi 2's 10,000,000 but did run over 8,300,000 so thier would have been some graphical loss but not much. the tech demo is the only real proof out there that the DC can do the high polygon count so go look it up!

Sure. Now we go back to earlier, and talk about PS2 - you said PS2 "maxes" at 10 million polys per second, and yet PS2's pretty obviously not-maxing-out-the-hardware Virtua Fighter 4 port is arcade-perfect. Even Cloud121 would agree with that.

You're pretty badly underestimating the PS2.

And one tech demo doesn't prove shit.

oh and just to let you know even after the DC died SEGA did make a revision of the DC's poly stats, and changed it to 7 million (this of course was before the tech demo was shown, and it's not an official demo by SEGA either).

OK...? What's your point with this one? Sony has claimed PS2 can push ~66-75M polys per second, doesn't mean it's true! The GS's setup engine can process 75M per second max (kinda overkill but is true), and the best PS2 tech demo (internal) ran just over 60M per second. That proves.... what now?

anyway i remember the description stating that it was a large city with cars racing around and all DC able effects on running at 60fps at 8.003 million polys per second.

What's your point? Tech demos are rarely an indication of what a console can really do, least of all tech demos that came out late in a console's life (or even after it's already dead).

Also i'm glad you can see that the DC can handle textures better than the PS2.

DC can handle textures more easily than PS2. PS2 has plenty of creative ways by which its texturing could likely crush DC's texturing under its steel boot heel, unfortunately we'll likely only see it in a tech demo. >_> But if a tech demo could do it, it must be the console's true power right! RIGHT!?

OK basically to summarise my argument, you are dramatically over-estimating DC's real-life abilities, and dramatically under-estimating PS2's real-life abilities. The gap is larger than you think, sweetie.

Or do you really think games such as Metal Gear Solid 2, Silent Hill 3, and Gran Turismo 4 would be possible as-is on a Dreamcast? Hell, MGS2 even has severe slowdown on Xbox. >_>

 

[AntiPasta]

Hell, MGS2 even has severe slowdown on Xbox. >_>

I fail to believe that's entirely Xbox's fault though...

 

[ExCyber]

Especially considering that said slowdown is only really substantial on one effect that itself looks like it was lifted from a tech demo.