|Red Dog: Superior Firepower|
|Genre||All-Terrain Mission Based Vehicular Combat, Intricate Level Design, 4-Player|
|Critique||Unique Reflective Shields, Tank and Car Controls|
Red Dog is clearly one of those poor casualties of too many quality DC software releases, as it just slipped through the cracks of public awareness. Argonaut, the company that made SNES classics Starfox and Stunt Race FX is the creator, and they went all out on this one.
3DMARK 2000 systematically tests the CPU and Graphics Card with a series of in game and theoretical tests. The results are charted below and each graph is organized chronologically by CPU and then GPU. All of the hardware listed was released from late 1998 to the end of 1999 with the exception of the Geforce 2 MX, Radeon 7500 and Kyro II. These graphics cards were included to show whether later GPU developments created a significant performance gap between top of the line PCs and, then, current generation game consoles.
Average statistics for the Helicopter test's low mode is 23 Objects, 4 Lights, 6,997 Polygons, 11,601 Vertices and 2.47MB of Textures, while high detail averages 39 Objects, 5 Lights, 53,026 Polygons, 71,292 Vertices and 2.81 MB of Textures.2. Early Dreamcast/Naomi games like Incoming, Crazy Taxi and Sword of the Berserk ran at a solid 30FPS with comparable geometry and at least as many objects and animated characters on screen.3 Yu Suzuki is on record repeatedly citing peak Dreamcast polygon performance in game at 3.5 million polygons per second. Some evidence exists that this figure was an estimate based on prototype Blackbelt or Dural hardware.
More importantly for the present comparison, 3.5 million polygons per second at 30 frames per second is only 116,000 polygons per frame. One Hundred and Sixteen Thousand polygons per frame at 40 bytes per polygon is 4.45 Megabytes of precious Video RAM, or a little over half of the 8MB attached to the PoverVR 2 - DC. Suzuki-San's estimation of the Dreamcast's peak in game performance may have been based more on VRAM limitations than anything else. Final Dreamcast hardware, and VRAM requirements for a 16-bit color 640x480 frame buffer being less than 0.7MB,4 leave ample room for the Dreamcast to maneuver.
|Low||22||4||9 392||16 356||3.14 MB|
|Medium||33||7||17 084||24 023||3.31 MB|
|High||44||8||29 941||36 983||3.41 MB5|
For the Adventure test we have a range of 23 to 39 objects and total polygon counts ranging from 16,356 to 36,983 polygons per frame. Video RAM usage for textures, excluding frame buffer, is fairly consistent at just below 3.5MB. Using these two tables it is possible to combine the framerates graphed above to find the "in game" polygons per second specs for each CPU and Graphics Card according to 3DMARK 2000. Since these game demos are more graphically advanced than anything that was released in 1999-2000 these averages are significant especially when compared to 3DMARK's own high polygon count test below. Numbers of light sources, and increased polygon detail in general, tends to have a dramatic affect on framerate, if not peak polygon throughput, even with graphics cards from 2000 and 2001 like the Geforce 2 MX, Radeon 7500 and Kyro II.
Maximum Dreamcast polygon counts, assuming one light with modifier volumes for shadows, is between 5-6 million polygons per second.6 Dreamcast's PowerVR 2-DC is the hard limit, based on 640x480 resolution frame buffer and 40bytes per polygon filling the 8MB of VRAM.7 The Hitachi SH-4 can set up over 10 million polygons per second.8 Melbourne House claimed 5 million polygons per second with all weather effects and cars on screen with Test Drive Le Mans.9 Current best guess average polygons per second for Le Mans is 300-500 thousand polygons per second.10
3D Mark's High Polygon Count tests are more realistic than theoretical peak performance figures, but still not as low as in game performance was. As can be seen here, the Pentium III 800e and Geforce 256 peak out at 8 million polygons per second with one light, 3.8 million with four lights or less than 2 million with rarely used in game eight lights. The PIII 800e and Kyro II Hercules 4500 (Power VR Third Generation) was tested since a Dreamcast quality PowerVR Neon 250 was unavailable. The Kyro II should outperform the Dreamcast's PowerVR2-DC in all respects and as can be seen further down has more robust multi-texturing effects than what 1998 video cards like the Riva TNT had available.
The PowerVR Second Generation was marketed directly against Nvidia's 1998 Riva TNT and was finalized and released around the same time. It is presently unknown if the above peak polygon numbers are only reflecting the Power VR's Tile Based Rendering of only front facing visible polygons. If the traditional renderers are counting back facing and hidden polygons while the Kyro II is only reporting visible polygons these numbers are not representing the same thing at all and the actual performance figures are closer than they appear. Nevertheless, the Kyro II maintains a consistent 3-4 million polygons per second scaling up much less dramatically from eight down to one light. Even the year 2000 released Geforce 2 MX drops to nearly one-fourth the polygon performance from one light to eight. So it is worth noting that the Kyro II maintains two-thirds of its peak performance even with eight lights.11 It will be very interesting to test the PowerVR Second Generation Neon 250 as soon as it can be purchased.12
2000-2002 Playstation 2 games averaged 1.5 million polygons per second, 300k minimum to 4.5m max, at 25-30 frames per second or less according to Sony's "How Far Have We Got" document.13 Melbourne House boasted 11,000 polygon car models in Grand Prix Challenge, released in 2003. Grand Prix Challenge peaked with 22 car models using 11,000 polygons each, or "20,000 (polygons) with multipass effects," and 500,000 polygons on the most detailed tracks at 60FPS.14 Level of Detail (LOD) changes as objects are displayed further from the camera, so there would never be a single scene with all 22 cars displaying their full detail models. These models are nonetheless impressive in their full detail. One car model out of twenty-two on screen has more polygons than an entire low detail frame in 3DMARK 2000's game tests as can be seen in the tables above.
Electronic Arts Canada was able to benchmark the PS2, Xbox, Gamecube and PC tech from 2002 using a Middleware engine. As can be seen, the PS2 peaks at 17 million polygons per second for a texture mapped gouraud shaded model, 10.9 million for the same with presumably one light, and 8.5 million for a skinned model. A non-textured, gouraud shaded but non-lit, high polygon model peaked the PS2's polygon performance at 25.2 million polgons per second.15 These are not in game figures and should not be considered the same as 3D Mark's High Polygon Count test as it still has Windows and Direct X overhead affecting performance. Additionally, Electronic Art's benchmark is not the same as 3D Mark 2000's because it is only measuring how fast the single figure can be rendered. If the figure was rendered ONCE in so many nanoseconds, then the maximum number of polygons per second must be the same multiplied by some guess at frames per second. This model fails to consider AI, Input Output, Physics calculations, or stalls and hardware glitches or poor coding as were mentioned of Sony''s "Graphics Synthesizer" and Vector Units earlier.
Unknown sources in the "mod community" compiled a list of character and car models for the PS2, Gamecube, Xbox, PS3 and Xbox 360. The so-called "6th generation" consoles tended to have 2,000-4000 polygon models including top tier racers like Gran Turismo 3 and GT4, while maximum detail characters were made of 7,000-10,000 polygon models.16 Disregarding this forum poster's lack of sources, Melbourne House's achievement with Grand Prix Challenge should not be taken lightly. The bottleneck prior to 2003 was stalls and lack of proper utilization of the PS2's Vector Units (VU1 and VU0). VU1 would stall on "large polygons and textures" and few games used VU0 at all.17 In addition, a glitch in the PS2's "Graphics Synthesizer" resulted in the system being incapable of proper Anti Aliasing and the limited 4MB cache only allowed the display of a line doubled 640x224 or 640x448.18