Comparison of 6th generation game console hardware

Some interesting forum posts I found just now.

http://dcemulation.org/phpBB/viewtop...?f=29&t=102506

Since KGL is completely absent from any lighting code, I decided to take a swing at it.

I have made an implementation of Dynamic Vertex Lighting based on some resources provided by nVidia, although it applies to GL.
http://http.developer.nvidia.com/CgT...chapter05.html
To accelerate things, I have used the SH4s fast math functions when possible.

Here is a basic scene I wrote for testing; some cylindrical and rectangular columns.

In this image, the scene is lit with one diffuse light, and a low level of ambient light:
http://oi42.tinypic.com/35cmvd4.jpg

This image is the same scene with the same diffuse light, except now the specular term is also being calculated:
http://oi43.tinypic.com/30clj5z.jpg

Same scene, now with a high level of ambient light:
http://oi40.tinypic.com/2r56l9t.jpg

So, I have the basic lighting model up and running, but now it leaves the desire for shadows to interact with the lighting.

My question is, how do we use the PVR to achieve shadows?
I know there is a modifier volume that can be set to "PVR_MODIFIER_CHEAP_SHADOW" but I really dont know how to use modifier volumes.
Any info appreciated!

BTW this guy seems to have achieved some very nice effects with PVR shadows:
http://yam.20to4.net/dreamcast/index_old.html

Small update, added attenuation calculations, and posted a short clip on youtube:
http://www.youtube.com/watch?feature...;v=pNPW6gJkVbE
http://yam.20to4.net/dreamcast/index_old.html

Quite a lot of time did I spend on that one and I guess this is gonna be
my favorite platform for trying things out or just for senseless coding hours.

I tried several times writing a 3D Graphics Engine for Dreamcast.
The very first version was written in C but I rapidely switched to C++ (and a lot of assembly..).
It now consists of asynchronous file loaders, simple thread support, a scene graph renderer
and a strange multi texturing material system that needs a redesign.
The graphics data is created with Cinema 4D and exported with a custom plugin.
I am currently thinking about a realtime plugin for Cinema that sends modification
parameters for the running scene over to the Dreamcast target, so you can change things in Cinema
and see the changes on the Dreamcast in realtime.
Below are some screenshots and some descriptions of my work so far.

---

http://yam.20to4.net/dreamcast/zclipping_00.jpg http://yam.20to4.net/dreamcast/zclipping_01.jpg
On Sega Dreamcast you must clip all polygons at least against the z near plane witch can break up all the nice flowing TnL code. Also, since you're working with triangle strips most of the time, you somehow have to take care of breaking up a strip into single polygons and stuff. The right picture shows some strange mipmapping behaviour on clipped polygons I've not figured out yet.

---

http://yam.20to4.net/dreamcast/outlines.jpg http://yam.20to4.net/dreamcast/shadow_00.jpg
Before we can do some stencil based volume shadows we first must find the object outlines and then extrude a shadow volume with some special polygons. Stencil shadows on Dreamcast are quite easy to do but they have their drawbacks. The biggest disadvantage is that you have only one type of volume witch tells the other polygons whether they are inside a volume or not. However, the results tend to look quite impressive...

http://yam.20to4.net/dreamcast/shadow_01.jpg http://yam.20to4.net/dreamcast/shadow_02.jpg




http://yam.20to4.net/dreamcast/shadow_03.jpg http://yam.20to4.net/dreamcast/shadow_04.jpg
...until you quickly run into some problems. First, you can have as many volumes inside the scene as you want. But the polygons of one volume must not cross, i.e. it must be convex. As far as I could figure out there are only two solutions to the torus problem you can see above. Either you break up the torus into multiple segments and let each segment cast a different volume, or you create a different volume for each backfacing polygon, which tends to slow down the rendering on the graphics chip a lot.


http://yam.20to4.net/dreamcast/shadow_05.jpg
And there is one more major problem. Notice the wrong shadowing in the middle of the picture. This happens when the camera enters a shadow volume. The polygons of the originally closed volume are clipped against the z near plane and the volume is opened. There is a nice solution to that famious capping problem by John Carmack but it works only with 8 Bit stencil buffer depth. On Dreamcast we have some kind of what I call 1.5 Bit stencil buffer. For one volume object there is only 1 Bit stencil, so either in or out. But you can have multiple overlapping separated volumes without any problems. So what we have to do is to generate capping polygons at the znear plane in order to close the clipped volume.


http://yam.20to4.net/dreamcast/shadow_06.jpg http://yam.20to4.net/dreamcast/shadow_07.jpg
I wrote some cheap algorithm that generates capping polygons based on the clipping information. It does not work for all arbitrary meshes but it turned out to be fine in normal cases. You usually don't have such strange volume meshes like spheres or tori, but rather cylinders and stuff.

---

http://yam.20to4.net/dreamcast/envmapping_00.jpg http://yam.20to4.net/dreamcast/envmapping_01.jpg
Above you can see some multi texturing and environment mapping with specular highlights. On the left there is only one environment texture, on the right there is a base texture and an environment map that makes up the black blots. On Dreamcast there is no real multitexturing support in hardware. Each additional texture layer must be rendered with translucent polygons, i.e. you have to send almost the same geometry vertex data to the graphics chips multiple times. My intention was to reduce the burden on the CPU (all geometry processing is done by the CPU on Dreamcast) by organizing the data in such a way that it could easily be cloned in one go. And in some cases it is even almost for free!

---

http://yam.20to4.net/dreamcast/bumpmapping_00.jpg http://yam.20to4.net/dreamcast/bumpmapping_01.jpg
Now that we've got multitexturing up and running we can continue with some more interesting stuff: The bump mapping. I don't remember seeing any game out there that makes use of it. But I also must confess that you won't be able to recognice it when you don't know it's there in some cases. On Dreamcast bump mapping can be done quite easily, too. Basically all you have to do is just a lookup table for the atan2 computation. However, things get complicated again if you want more than one light source to affect the bump mapping surface.


http://yam.20to4.net/dreamcast/bumpmapping_02.jpg http://yam.20to4.net/dreamcast/bumpmapping_03.jpg
Left image: no bump map.
Right image: heavy bump map applied, looks damn cool when you move the light source. Bottom image: base texture + bump map + environment map (pink / black)
http://yam.20to4.net/dreamcast/bumpmapping_04.jpg

---

Last but not least some standard post processing effects.
Top left: normal image.
Top right: noisy pixel displacement.
Bottom left: box filter blur.
Bottom right: radial blur / crash zoom.

http://yam.20to4.net/dreamcast/postfx_normal.jpg http://yam.20to4.net/dreamcast/postfx_noisy.jpg
http://yam.20to4.net/dreamcast/postfx_boxfilter.jpg http://yam.20to4.net/dreamcast/postfx_radial.jpg

-edit-

I also found this discussion of Sony's "How far have we got" 2003 document which apparently includes comments by the document author (llmarie post 9):
http://forum.beyond3d.com/showthread.php?t=8053

As the author of the document, I would like to make a few comments:

Quote:

What a shame that there are still many developers that are not even using VU0.

Very true, but VU0 is not as easy and staightforward to use as VU1. There are many reasons why this is so. We can't condemn developers for that, I am just trying to encourage them to give it a second thought.

Quote:

It's quite a bit different from the 15 - 20 million figure that has been used by the console's advocates (infact this would seem to roughly indicate that the DC was to PS2 what the PS2 is to Xbox in terms of performance).

Let's not get confused between "top speed" and "average speed". A Porsche can go over 200km per hour, but drive it over hundreds of kilometers and look at the average speed you got.
There are regulations and constraints, there are pauses and traffic jam.
It's all the same on PS2. You can achieve up to 22MP/s, but the average will still be around 5MP/s.

Quote:

As has been mentioned sereral times on these boards, the PS2's CPU does appear to be the weak point of the system.

True, although not the CPU itself, but rather the CPU efficiency. It is slowed down by bus accesses and stalls, etc... That makes it the weak point.

Quote:

But I too, am quite surprised at the slide which says "Best performing games use up to 8% VU0". Not sure if they scanned the just released J&D2, R&C2, or SH3 and ZoE: Anubis from Japan. Because that statistic is really surprising.

I did indeed, and the stats do includes the results from those games.


It is not an easy platform to program for, but definitely a very interesting architecture and it does allow for interesting techniques. It is nice to see that it hasn't reached the end of its life yet.
If you have any more questions about the document, please let me know.

Lionel

------

Quote:

There is one thing I was wondering about - the app with 40x overdraw, is it a big secret which is it?

I'm not sure I'm supposed to say it, but I see no harm in it, especially that the game is doing pretty well technically. It was LOTR2, it is full of giant particles.

Quote:

do you mind if I ask where you pull your information from? Individual hand-testing of every game through the PA yourselves only, or is there a lot of developer info-swapping going on as well?

Over the last two year we have scanned a large number of games. There is a developer community too, but they have their secrets that I cannot discuss it here.

Quote:

Do you test only the maximum performance a title can bring into play, or average it with all the various levels a game can deliver? (Thinking specifically of racing titles here, as you can play with just yourself on a track, or potentially load it up with many more cars--meaning much more needed pushing power.)

I usually take a random point in the game. It might be unfair, but it is unfair in the same way for each game, so on average the results are still relevant.

Quote:

I must say your "maximum" count is going to get a lot of people jumping around, but it's supposed to read more like "maximum average polys at 60fps for the entire title," right?

Reading the document without attending the talk is not so good, because of course you don't get the explanation for each assertion.
For example, the maximum count is indeed an average and is nowhere near the maximum the PS2 can achieve at peak.
If people like big numbers, a developer has contributed some code running a 600K poly textured scene at 60fps. It is public too, and can be found on playstation2-linux.com

Quote:

I rather doubt the majority of ANY games for any of the consoles push over 5M at this point

I think so too. In most cases though, it is fair to say that the game has been designed not to need more that that, rather than it being limited by the hardware.

Quote:

BTW: I loved your comments on the Data Packing slide talking about palletized textures

Thanks. During the talk I asked if there were any artists, I didn't expect any, but there were several of them actually. Busted.

Quote:

the PA actually underestimates the polys drawn

Wrong, the PA shows you _exactly_ the number of polygons drawn, regardless of how many you actually intended to draw.

Quote:

How does this affect your averages?

If affects the stats indeed. But in the end if you send 100K polys but only 50K got drawn, then you did only draw 50K. I think it is fair to count only polygons that are drawn on screen.

Quote:

You are working for the developer support at SCEE (like listed in you presentation) this results in the following questions:

I am working for the developer support at SCEE, this results in the following answer:
No comments, sorry.

Hope this helps,
Lionel

----

Missed a few questions, sorry:

Quote:

Would this be 145,000 peak, average (over a section of the game) or sustained (over successive frames)?

145k sustained it was, but not at 60fps. That makes it 70K polys at 60 on average, so 125K at 60 is still the fastest (and those are actual displayed polygons). But those are just numbers, in most games the quality of the picture does not depend so much on the number of polygons.

Quote:

I'm just interested to know specifically what the figures are referring to

I read the figures by looking at the rendering part of the scans only. That is to say I didn't include the waiting time for the VSync for instance. I did include the time waiting for texture uploads on the other hand, that could make a renderer capable of 15MPs run at 10 or 8 or less.

Quote:

How successful do you feel you will be at utilizing VU0 in future and upcoming titles?

As we said, using VU0 is not easy. Results will certainly vary, we are still waiting to be surprised.

As a comment, it has been mentioned that when I said "VU0 usage" that wasn't taking VU0 as COP2 in account. That is true, and during the talk I did explain that the figures were for VU0 running independantly from the CPU, which was the relevant point I wanted to make.

*sigh*

- Thanks for pasting a DC demo showing very basic lighting techniques + a FULL website page + 2 pages of format-removed forum discussions in a single post.

- The website discussing DC demos had already been posted both in this thread and in the PS2 vs DC Graphics thread.

- Funny that you have now "found" a thread to tell us, again, the same things that Crazyace has been telling you several times in this very same thread. By the way, Crazyace was partaking that discussion you linked.
Despite your endless efforts to misread that document, three key points in the author's replies work against some of your assumptions (and Crazyace had already pointed them):

1. The VU0 usage percentage mentioned in the document do NOT consider the games which used it in macromode; only the ones which used it independently from the CPU were considered.
2. The polygon counts of the games do NOT represent the peak of those games, just some randomly chosen scene of the game which can be as monotonous as that Ratchet & Clank one.
3. The PA shows you exactly the number of polygons drawn; so the PA figures are directly comparable to the DC's.

Another developer in the discussion also reinforced what rusty had already said about the use of VU0 in micromode or macromode:

Quote:

---

One of the major reasons to use micromode VU0 is paralel operation to the core. Because we have to spoon feed the data to VU0 by R59k, much of this paralelism gets lost. Moreover, VU0 can't output results by itself either, requiring more R59k assistance for reading out the results.

This interaction between core and VU0 is also anything but simple to implement efficiently, isn't easy to debug, and doesn't lend itself well to a generic approach that would work for multiple problems.
Macro code takes MUCH less time to write, and if you fail to implement the above interaction efficiently, stands a good chance to run comparably fast.

What VU0 lacks to making it truly usefull is what APUs promise to give - ability to feed and output data by themselves.

I'm not just speaking theory on this one btw, I've wrote a buttload of macro code as well as several micro coded solutions (mostly related to physics optimisations).

---

- Let me know if you need help to reset the thread discussion once again.

The only thing you could be helped with is a massive attitude overhaul. Yep, i thought I had seen the Dreamcast demo pics before. I've seen you be a complete asshole before too. Silly me for not remembering a link from May of last year. The graphics thread is a waste and a joke, until I ignore it huh?

I definitely had not seen the author's comments on the "how far have we got" document, and it looks like Crazyace had. As for resetting the discussion, this discussion is far from over, the more developer anecdotes the better. The more barone-the-troll keeps responding the more error he creates in this thread. It's no wonder you caused the graphics thread to be moved to troll land.

sheath is dodging questions? sheath is overreacting? sheath is insulting people who don't support his fallacy and conspiracy theories?
sheath, the man who is driven by facts and only facts? The only person is this forum capable of providing valid sources in a discussion?
The one and only sheath???
That can't be! :shock:



sheath, when you have found your pills, answer the following questions:
- Which equation do you use to generate your predictions about the polygon counts of games for the entire 6th gen of gaming consoles?

- In which parts of DC's Daytona USA I can find graphical effects similar to ones used in GC's F-Zero GX?

- What is the supposedly innovative "level of detail engine" which you were purposing to make the Dreamcast games push more polygons per frame overall?

- Why do you think that polygons drawn by multipass renders to be used in graphical effects should not be counted as drawn polygons?



Talking about people in need of a massive attitude overhaul:
"The grand experiment is over! "What experiment?" you might say, should you care to read and ponder? Are popular online "communities" known as forums treasure troves of solid information? Does pouring historical and technical facts into one or all of these popular communities result in more technical or historical discussion of the Video Game Industry? That answer is a resounding ... sometimes but very rarely. Instead forums, as originally suspected, are argument factories first, outlets for unfounded opinion posting second, and places to vent all around."
By sheath.

I never made any of the above assertions. I can't be "dodging a question" when the question is flame bate in the first place. Your problem, and it is YOUR problem, is you are so arrogant that you think your reading of my inquiry is the only possible reading. I think it is somewhat one sided to say that Grand Prix Challenge runs at 18 million polygons per second because of the way textures and effects are rendered. I have not attempted to negate the fact that Melbourne house said "18 million with multipass effects." This is just one of the many errors you have created in your attempt to blast my posts.

As for your other questions, as of yet I have found no such "formula" for calculating polygons per second or comparing polygons per second across platforms. Which is one of THE MANY reasons why I doubt polygon counts in the first place. You already knew that though, as I have consistently pointed this out both in the group and to you over PM. I can only see one reason why you would ask such a leading question, and I'm sure you will meet and exceed my expectations.

The F-Zero GX and Daytona comparison was a simple straight forward one with no implications other than what I wrote. I can't see why the models of F-Zero GX would need to be downgraded for a Dreamcast version. You quoted this yourself and still fail to see the difference between what I said, a personal observation not an opinion stated as fact, and what you claim I said. The burden of proof is on you as my accuser to prove that I have asserted F-Zero GX and Daytona 2001 are technically identical. Good luck with that.

I speculated that advancements in an LOD engine might improve the average polygon counts of Dreamcast games, nothing more. You blew it into the stupid statement, that I thought Le Mans wasn't using LOD steps, not me.

Also, if you don't think you are being a complete asshole about this entire topic you really are not seeing the forest from the trees. I can tell you that your every post in this thread and since that asinine Graphics thread was created has sucked any potential fun out of the discussion for me. I suppose that has nothing to do with you and everything to do with me not wanting to listen to facts I have already accurately summarized in this thread. I even admitted that one of my earlier statements, which actually had reasonable context, was incorrect. None of that is going to be good enough for you obviously.

sheath, a few more questions for you:
- Can't you handle being asked to point the graphical effects equivalencies of game that you said to be "comparable" to another one in a discussion about graphics? By the way, you still didn't point them. Will you?

- You still didn't answer how a "level of detail engine" would help the Dreamcast to render more polygons per frame... Aren't LOD steps supposed to be used to decrease the number of polygons per frame instead of the opposite?

- I still don't understand how you have been able to predict, repeatedly, the polygon counts for the entire 6th gen of gaming consoles. Do you care to enlighten me?

- Why do you need a formula to compare in game polygons per second figures of different platforms? Polygons drawn by the Dreamcast are different from those drawn by the other consoles of that gen?

- Do I need to quote your own posts, again, in order to make you "admit" the existence of them and expose your bad attitude towards members who dare to disagree with your narrative and/or criticize it?

Quote:

---

Originally Posted by sheath

I never made any of the above assertions. I can't be "dodging a question" when the question is flame bate in the first place. Your problem, and it is YOUR problem, is you are so arrogant that you think your reading of my inquiry is the only possible reading. I think it is somewhat one sided to say that Grand Prix Challenge runs at 18 million polygons per second because of the way textures and effects are rendered. I have not attempted to negate the fact that Melbourne house said "18 million with multipass effects." This is just one of the many errors you have created in your attempt to blast my posts.

As for your other questions, as of yet I have found no such "formula" for calculating polygons per second or comparing polygons per second across platforms. Which is one of THE MANY reasons why I doubt polygon counts in the first place. You already knew that though, as I have consistently pointed this out both in the group and to you over PM. I can only see one reason why you would ask such a leading question, and I'm sure you will meet and exceed my expectations.

The F-Zero GX and Daytona comparison was a simple straight forward one with no implications other than what I wrote. I can't see why the models of F-Zero GX would need to be downgraded for a Dreamcast version. You quoted this yourself and still fail to see the difference between what I said, a personal observation not an opinion stated as fact, and what you claim I said. The burden of proof is on you as my accuser to prove that I have asserted F-Zero GX and Daytona 2001 are technically identical. Good luck with that.

I speculated that advancements in an LOD engine might improve the average polygon counts of Dreamcast games, nothing more. You blew it into the stupid statement, that I thought Le Mans wasn't using LOD steps, not me.

Also, if you don't think you are being a complete asshole about this entire topic you really are not seeing the forest from the trees. I can tell you that your every post in this thread and since that asinine Graphics thread was created has sucked any potential fun out of the discussion for me. I suppose that has nothing to do with you and everything to do with me not wanting to listen to facts I have already accurately summarized in this thread. I even admitted that one of my earlier statements, which actually had reasonable context, was incorrect. None of that is going to be good enough for you obviously.

---

It would seem to me that a couple of the questions you are trying to answer are "Is the PS2 really is every bit the "polygon monster" fans claim it is?" and also "Does the PS2 outperform the Dreamcast in most cases?" Am I right? If so there seems to be quite a lot of evidence to show that even if it isn't the "75 million polys/sec pushing super computer" that Sony's PR Hype blurb claimed, that it still has a powerful rendering system on board and that in terms of fill rate it still surpasses the DC.
I'm also curious to find out why you think that it is "one sided" to say that Grand Prix Challenge runs at 18 million polys/sec "because of the way textures and effects are rendered", I admit that I'm no expert on how these systems work but my elementary understanding is that the more graphical effects that are applied to the 3D model the more computationally intensive it is for the system to draw it. I am right in this thinking? If so I would then say that producing that level of detail at 60fps requires a very high fill rate and a lot of graphic memory bandwith and therefore is fully taking advantage of the PS2's fillrate. What is it about that statement that would make that "one sided"?

Quote:

---

Originally Posted by sheath

I never made any of the above assertions. I can't be "dodging a question" when the question is flame bate in the first place. Your problem, and it is YOUR problem, is you are so arrogant that you think your reading of my inquiry is the only possible reading. I think it is somewhat one sided to say that Grand Prix Challenge runs at 18 million polygons per second because of the way textures and effects are rendered. I have not attempted to negate the fact that Melbourne house said "18 million with multipass effects." This is just one of the many errors you have created in your attempt to blast my posts.

---

The multipass effects though are something the Dreamcast would probably struggle with. If I remember correctly they are what give games like Gran Turismo that photo realistic art style with the reflections and what not. The Dreamcast could probably handle the terrain and car models for those games, but the reflections and other multipass effects would probably have to be handled differently. Now how that would end up looking in the end is anyones guess. Test Drive LeMans looks great and on par with Gran Turismo 3 and possibly 4, but it's running at half the frame rate. Other racers like Daytona USA don't have effects that look on par with GT3 and GT4 and other racers that make heavy use of multipass rendering effects.

Quote:

---

Originally Posted by sheath

As for your other questions, as of yet I have found no such "formula" for calculating polygons per second or comparing polygons per second across platforms.

---

Most emulators for these systems will give you these numbers. However the last build of PCSX2 that gives those is rather buggy with some of the games in question.

Quote:

---

Originally Posted by sheath

The F-Zero GX and Daytona comparison was a simple straight forward one with no implications other than what I wrote. I can't see why the models of F-Zero GX would need to be downgraded for a Dreamcast version.

---

The car models would probably be fine. It's the track details, the buttloads of transparencies and lighting effects that would be the concern.

Quote:

---

Originally Posted by sheath

The burden of proof is on you as my accuser to prove that I have asserted F-Zero GX and Daytona 2001 are technically identical. Good luck with that.

---

You're saying you don't see why the game would need to be downgraded to run on the Dreamcast, and are using Daytona USA to back that claim up. It's not that hard to connect the dots here.

Quote:

---

Originally Posted by sheath

I suppose that has nothing to do with you and everything to do with me not wanting to listen to facts I have already accurately summarized in this thread. I even admitted that one of my earlier statements, which actually had reasonable context, was incorrect. None of that is going to be good enough for you obviously.

---

You may have admitted you were wrong earlier, but you keep backtracking and going back to your old arguments that which completely negates what you admitted earlier. If you didn't keep backtracking and going back to the same arguments over and over again we wouldn't be having this conversation.

Quote:

---

Originally Posted by stu

It would seem to me that a couple of the questions you are trying to answer are "Is the PS2 really is every bit the "polygon monster" fans claim it is?" and also "Does the PS2 outperform the Dreamcast in most cases?" Am I right? If so there seems to be quite a lot of evidence to show that even if it isn't the "75 million polys/sec pushing super computer" that Sony's PR Hype blurb claimed, that it still has a powerful rendering system on board and that in terms of fill rate it still surpasses the DC.

---

The PS2 being capable of 60-75 million polygons per second was considered a reality up to and including its March 2000 launch, and that spec absolutely perpetuated Sony's Playstation brand as technically ahead of the curve. Even back in the day nobody thought those numbers meant anything in regard to actual games, but it took y-e-a-r-s for sources to start to surface that even began to show what the real in game figures might be. The old gamepilgrimage "editorials" on the topic have been used against me, as though I ever intended those pages to be "codified fact".

I have not been credited for using this quote about the Dreamcast and PS2:
http://www.gamepilgrimage.com/DCPScompare.htm#tvf
"Of course, the polygon count, even in the potential worst case (all bezier surfaces, 50% CPU spent on AI and physics) is still faster than the PowerVR. In fact, about twice as fast. What does this mean. Well, look at the current DC game models. For every straight edge you can see, subdivide it once (so that each edge is broken into two), and that's the detail improvement you'll see. Pretty substantial? Of course, as game developers make better use of the CPU(s), I'd expect polygon performance to increase."

The above has been and will continue to be my backdrop to any comments regarding the PS2 and Dreamcast performance until I find a way to poll the actual performance of the games in a comparable way and create the necessary stats to claim anything otherwise or support the above. In that attempt I have decided occasionally to play on the assumptions of any given forum or thread in the hopes of gaining some actual discussion of actual facts. You might have noticed, the usual PS2 vs anything thread results most often in a whole bunch of people reciting the same old unfounded statements.

Quote:

---

Originally Posted by stu

I'm also curious to find out why you think that it is "one sided" to say that Grand Prix Challenge runs at 18 million polys/sec "because of the way textures and effects are rendered", I admit that I'm no expert on how these systems work but my elementary understanding is that the more graphical effects that are applied to the 3D model the more computationally intensive it is for the system to draw it. I am right in this thinking? If so I would then say that producing that level of detail at 60fps requires a very high fill rate and a lot of graphic memory bandwith and therefore is fully taking advantage of the PS2's fillrate. What is it about that statement that would make that "one sided"?

---

I find it one sided to claim the highest figure in this case because some 3D renderers, as far as I know, do not need to re-rasterize the front facing polygons to produce the same effects. As such it is a loop hole for the PS2 version of the same game to be listed as higher polygon counts just because it is using polygons for effects the other platform does natively. This is also a point that requires a more thorough consensus than I have seen discussed. If the PS2, as rusty and barone have stated, renders polygons for environment effects, lighting, bump mapping and other effects and also doesn't cull back facing of hidden polygons, then these polygon counts truly are apples to oranges in relation to the tile based rendered Dreamcast specs. This is just one reason why this "discussion" is far from over.

Quote:

---

Originally Posted by TrekkiesUnite118

The multipass effects though are something the Dreamcast would probably struggle with. If I remember correctly they are what give games like Gran Turismo that photo realistic art style with the reflections and what not. The Dreamcast could probably handle the terrain and car models for those games, but the reflections and other multipass effects would probably have to be handled differently. Now how that would end up looking in the end is anyones guess. Test Drive LeMans looks great and on par with Gran Turismo 3 and possibly 4, but it's running at half the frame rate. Other racers like Daytona USA don't have effects that look on par with GT3 and GT4 and other racers that make heavy use of multipass rendering effects.

---

I am 100% absolutely certain that hard coded PS2 effects could not be ported to the Dreamcast. I wouldn't even be surprised to find out that these effects would need to be rewritten for the Gamecube and Xbox or even the Wii. Is somebody claiming that the Dreamcast cannot do true environment mapping effects?

Quote:

---

Originally Posted by TrekkiesUnite118

The car models would probably be fine. It's the track details, the buttloads of transparencies and lighting effects that would be the concern.

---

Gasp! nuances!

Quote:

---

Originally Posted by TrekkiesUnite118

You're saying you don't see why the game would need to be downgraded to run on the Dreamcast, and are using Daytona USA to back that claim up. It's not that hard to connect the dots here.

---

The first problem here is that I was screwing around, not writing a dissertation or posting an article or comparison on GP. Secondly, yes, I find Daytona on Dreamcast fairly exemplary of a port done right to the Dreamcast. It is also an Arcade racer with relatively great texture mapping, track detail and numbers of cars on track. Beyond that, my original statement is all I intended. I don't see why F-Zero GX would need to be massively downgraded, even noticeably downgraded, to run on the Dreamcast. The poster I was responding to with that singular comment obviously had no idea what the comparison would be.

I wrote this because I know absolutely nothing about what the performance figures are for each game and would LOVE to know somebody has figured out more.

Quote:

---

Originally Posted by TrekkiesUnite118

You may have admitted you were wrong earlier, but you keep backtracking and going back to your old arguments that which completely negates what you admitted earlier. If you didn't keep backtracking and going back to the same arguments over and over again we wouldn't be having this conversation.

---

My old argument that you can't put into words? The one where you think I am trying to claim the Dreamcast can do X-many polygons per second more than the PS2 with similar effects? You mean the argument I have never made or even thought of.

Quote:

---

Originally Posted by sheath

The PS2 being capable of 60-75 million polygons per second was considered a reality up to and including its March 2000 launch, and that spec absolutely perpetuated Sony's Playstation brand as technically ahead of the curve. Even back in the day nobody thought those numbers meant anything in regard to actual games, but it took y-e-a-r-s for sources to start to surface that even began to show what the real in game figures might be. The old gamepilgrimage "editorials" on the topic have been used against me, as though I ever intended those pages to be "codified fact".

---

Well you tend to use the exact same arguments quite often. So they may not say "These are FACT!" on game-pilgrimage, but you sure do try to use them as facts.

Quote:

---

Originally Posted by sheath

I have not been credited for using this quote about the Dreamcast and PS2:
http://www.gamepilgrimage.com/DCPScompare.htm#tvf
"Of course, the polygon count, even in the potential worst case (all bezier surfaces, 50% CPU spent on AI and physics) is still faster than the PowerVR. In fact, about twice as fast. What does this mean. Well, look at the current DC game models. For every straight edge you can see, subdivide it once (so that each edge is broken into two), and that's the detail improvement you'll see. Pretty substantial? Of course, as game developers make better use of the CPU(s), I'd expect polygon performance to increase."

---

You left out the most important detail:

Quote:

---

Originally Posted by Sheath on Game-Pilgrimage

Highlights of the graphical comparison are quoted directly below from a Usenet discussion

---

That makes it lose most if not all credibility. It's not from any developer, it's just from another fan looking at specs and taking wild guesses.

Quote:

---

Originally Posted by sheath

The above has been and will continue to be my backdrop to any comments regarding the PS2 and Dreamcast performance until I find a way to poll the actual performance of the games in a comparable way and create the necessary stats to claim anything otherwise or support the above. In that attempt I have decided occasionally to play on the assumptions of any given forum or thread in the hopes of gaining some actual discussion of actual facts. You might have noticed, the usual PS2 vs anything thread results most often in a whole bunch of people reciting the same old unfounded statements.

---

So in sheathland Usenet posts trump developer interviews?

Quote:

---

Originally Posted by sheath

I find it one sided to claim the highest figure in this case because some 3D renderers, as far as I know, do not need to re-rasterize the front facing polygons to produce the same effects.

---

This isn't what multi-pass rendering effects are or what's going on here.

Quote:

---

Originally Posted by sheath

If the PS2, as rusty and barone have stated, renders polygons for environment effects, lighting, bump mapping and other effects and also doesn't cull back facing of hidden polygons, then these polygon counts truly are apples to oranges in relation to the tile based rendered Dreamcast specs. This is just one reason why this "discussion" is far from over.

---

The Dreamcast would need to use polygons to do those kind of effects too. They are not used to produce the same kind of lighting and shadows that the Dreamcast is doing. To use Gran Turimso as an example, if I'm remember correclty multipass rendering is used to render transparent models/polygons over the cars that use different textures to give the kind of reflection and shadowing effects that give the game it's photo-realistic art style. If the Dreamcast wanted to get the same look it would probably need to do the same thing.

Quote:

---

Originally Posted by sheath

I am 100% absolutely certain that hard coded PS2 effects could not be ported to the Dreamcast. I wouldn't even be surprised to find out that these effects would need to be rewritten for the Gamecube and Xbox or even the Wii. Is somebody claiming that the Dreamcast cannot do true environment mapping effects?

---

You've missed the point. The point isn't on the code that is written for the PS2 to do it, it's the theory and implementation. That's not hardware specific, that's general rendering techniques. If you want to get the exact same effect the PS2 is doing, you'd need to do multipass rendering. The Dreamcast would probably struggle due to it's lower peak polygon performance and the hit that transparencies take on performance. So you would need to do a different effect. It may look close, it may look radically different.

That was the point being made that you completely missed.

Quote:

---

Originally Posted by sheath

Gasp! nuances!

---

Do you even know what that word means? Trackside detail, lighting and transparency effects aren't a subtle difference. They're a big deal. To imply that the vehicle models are all that would matter for a DC port isn't just wrong, it's flat out ignorant.

Quote:

---

Originally Posted by sheath

The first problem here is that I was screwing around, not writing a dissertation or posting an article or comparison on GP. Secondly, yes, I find Daytona on Dreamcast fairly exemplary of a port done right to the Dreamcast. It is also an Arcade racer with relatively great texture mapping, track detail and numbers of cars on track. Beyond that, my original statement is all I intended. I don't see why F-Zero GX would need to be massively downgraded, even noticeably downgraded, to run on the Dreamcast.

---

The screwing around comment is completely negated by your last sentence there. You are again saying you don't see why the Dreamcast would struggle with F-Zero GX. It's not the textures, and it's not the number of cars on the track. It's the complexity of the track geometry, the lighting effects, and the transparency effects. Without that the game becomes rather bland.

Quote:

---

Originally Posted by sheath

I wrote this because I know absolutely nothing about what the performance figures are for each game and would LOVE to know somebody has figured out more.

---

Then wait a bit. I'm downloading it so I can load it up in Dolphin (Dolphin doesn't work well with real discs). I should be able to get the polygon counts then.

Quote:

---

Originally Posted by sheath

My old argument that you can't put into words?

---

I put it into words here and you agreed with it here.

Do you have memory problems?

Quote:

---

Originally Posted by sheath

The one where you think I am trying to claim the Dreamcast can do X-many polygons per second more than the PS2 with similar effects? You mean the argument I have never made or even thought of.

---

As you can see from the above links, I did not say you are trying to claim that the DC can do more polygons per second than the PS2.

Quote:

---

Originally Posted by sheath

The PS2 being capable of 60-75 million polygons per second was considered a reality up to and including its March 2000 launch, and that spec absolutely perpetuated Sony's Playstation brand as technically ahead of the curve. Even back in the day nobody thought those numbers meant anything in regard to actual games, but it took y-e-a-r-s for sources to start to surface that even began to show what the real in game figures might be.

---

This is not true.

I have yet to read an official document from Sony claiming that those numbers (60-75 million polygons per second) were supposed to be in game figures. It wasn't uncommon at the time and it isn't now to try to sell products based on theoretical peak numbers or numbers obtained under very special conditions.
Again, if that is what made the PS2 successful, the 32X should have set the world on fire when Sega sold as being 40 times faster than the 16-bit machines.

According to that SCEE document's author, "If people like big numbers, a developer has contributed some code running a 600K poly textured scene at 60fps. It is public too, and can be found on playstation2-linux.com". If that is true, we are talking about 36 million polygons per second which is "just" about seven times greater than what seems to be the DC's limit determined by its own architecture.

Even the evil mainstream media had already questioned those numbers before the PS2's release:
"In real-world numbers, how many polygons can the PlayStation 2 handle on screen?
Since a 3D object is constructed of pieces (known as polygons), the number of polygons per second a system can process indicates how detailed the 3D graphics can be, and how smoothly they can animate.

Officially, the maximum number the system can process is 75 million polygons per second. But this number doesn't take into account texture maps (images wrapped onto the polygon set), filtering (making the textures look clean, natural, and unpixelated), and lighting (giving the object a more 3D look with realistic shadows and light effects). With all this into place, the PlayStation 2 can process 20 million polygons per second. Again, in-game physics, character artificial intelligence, audio, and other processor-intensive effects will affect this number. We'll take a conservative estimate and saying initial games will push around eight to ten million polygons per second - and believe us when we say that this number is still no slouch.
http://www.ign.com/articles/1999/10/...ystation-2-faq

Looks like the biased media pulled off predictions which are much closer to the reality than yours, sheath.

Quote:

---

Originally Posted by sheath

The old gamepilgrimage "editorials" on the topic have been used against me, as though I ever intended those pages to be "codified fact".

---

They have being used against you 'cause they are heavily biased.
And the fact that you keep the archive online only contributes to make your theories look even more anecdotal and outdated.

Quote:

---

Originally Posted by sheath

The above has been and will continue to be my backdrop to any comments regarding the PS2 and Dreamcast performance until I find a way to poll the actual performance of the games in a comparable way and create the necessary stats to claim anything otherwise or support the above.

---

You have already shown many times that you will create drawbacks to a direct comparison at any costs.

It's pretty clear by now that all you DON'T want is to produce any direct comparison of factual numbers. What you really want is to carry on with your biased and outdated narrative.

Even sadder than that is that you don't have enough guts to actually assume it in front of the others and all that you do is to claim that you're always misinterpreted and, even worse, on purpose.
You seem to think that people are idiot enough to not be able to connect your years of self-entitled biased narrative and relativization of sources to your actual self-pity posts.

To apologize for all the overly drama, the false accusing, the uncalled insults and the misinformation that you have been spreading for years is what you should be doing now prior to blame anyone else for your struggle to face the reality.

Quote:

---

Originally Posted by sheath

The first problem here is that I was screwing around, not writing a dissertation or posting an article or comparison on GP.

---

So after accusing people from twisting your words and delivering insults you want to gain a free pass by saying that you're "screwing around"?
Man up, sheath.

Quote:

---

Originally Posted by TrekkiesUnite118

That makes it lose most if not all credibility. It's not from any developer, it's just from another fan looking at specs and taking wild guesses.

So in sheathland Usenet posts trump developer interviews?

---

You obviously didn't click on the link, the source was a developer with access to the hardware or at least dev kits.

Quote:

---

Originally Posted by sheath

You obviously didn't click on the link, the source was a developer with access to the hardware or at least dev kits.

---

I did, here's what the guy has to say:

Quote:

---

Much of the information was pulled from the appropriate links. Here's
the basic breakdown. For the Sony, I simply went to
http://www.playstation.com and got the spec for it. Some things regard the
summaries of the PS2 were pulled from extensive hardware study in 3D design.
Some facts were filled in from various magazines that have (accidentally)
published NDA information :) Sega isn't as forth comming as the PS2, inspite
of the fact that the machine is "out-there". But the guys at
http://www.ign.com give a good summary. Then spend a few minutes travelling
to http://www.hitachi.com to get info regarding the SH4;
http://www.powervr.com for infor regarding the Dreamcast graphics chip, and
finally http://www.yamaha.com for the audio chip. Other details were filled
in with the magazines I have (as for the PS2).

Yes, I'm a "computer technician", though more appropriately an
electronics hobbyist and professional electronics technologist, and have
worked for R&D companies who build computer systems from scratch (embedded
controller mind you). I have followed the 3D world since Lightwave (1) was
released on the Amiga, so many years ago. Nothing here was made up, though
my opinion is obvious in the "Note:" sections.

---

So basically he hasn't coded a single game or program for either machine. He's just a hobbyist looking at the specs that were published and taking guesses. He may have read up on 3D techniques, but that doesn't make his assumptions more accurate than what actual developers have to say about the hardware. He even admits in that post that the parts in the "Note" sections aren't fact, but just his opinion.

Here's a hint, the section you quoted is from one of the "Note" sections.

That is right, I obviously haven't clicked the link in years. I was wrong!!!!111 He was a "technician" at least at our level, with no access to dev kits. At any rate, his post is and has been a spring board for my own inquiries. This thread's more recent posts have shown that the PS2 may well have been averaging at 6 million polygons per second in most games by 2003, with a large group of polled games. If anything that makes me wonder even more what the point of polygon specs were in this generation, as I have played most of the games mentioned and found very few of them to be clearly and obviously superior in detail.

It would seem that most of the polygons were absorbed by water effects, lighting effects, particle effects, and things that never really drew my attention in the first place. If they had instead improved the poor texture quality earlier than 2003 I might not have moved on to the Xbox and Gamecube instead.

F-Zero GX Polygon counts courtesy of Dolphin:

Average Polygons per frame in less complex tracks: 45-60k
Average Polygons per frame in complex tracks: 75-85k
Highest count I saw (Mute City Demo): 110k
Lowest I saw (Turn in Desert Track with no cars or trackside objects): 16k

This is all while running at a never stuttering 60fps. So if we take the high end of the complex tracks which is 85k, that's 5.1 million polygons per second. If we take the max which was 110k that's 6.6 million polygons per second. In the average tracks we're at 3.9 Million.

As Chilly and others have said, anything beyond 3 million polygons per second isn't really worth doing on the Dreamcast because the bottlenecks of VRAM space and the SH-4 start to make it not worth while. So even in average tracks we're beyond the max realistic figures for the Dreamcast. And that's not even considering the lighting or transparency effects.

Here sheath, you an use this canned meme reaction for your reply:

http://i.imgur.com/cGMZKty.gif