Was the dreamcast pushed to its limits

[chao2]

Im not a programmer but I thought this would be the best place to ask the my question because a lot of people on these forums have programmed for the dreamcast. Was the dreamcast pushed to its limits while it was on the market? I knew ram was a issue but could it have pushed more than 4 million polygons(test drive le mans).

[RyoDC]

I don't think 4 million polygons is a real number at all.
I think this 4 millions was just a some market figure to Stir up the brains of potential customers.
If you look at some tests, done by Ph3nom and other guys, the real number of polygons drawed by Dreamcast is around 133k per sec. (depend on the parameters and fps, of course).
133k pers sec with 60 fps -> around 2.5k polys per frame.
So it's not even nearly those number.
Nevertheless, about your question, it's hard to say, was it pushed or not, because who really knows?
Only particular, concrete tests and benchmarks can say that.
Nor we had the source codes of the games from those times nor the tests, so not that much can be said.
Anyway, you can look at the framerates and memory fill from the games on emulator, like nullDc, which tells us some statistics about total number of vertices and polygon count. Looking at them, and comparing them to results produced by graphic benchmarks from KOS package (but also, recall, that you can't consider those bechmarks as absolute, because benchmarks of those times could use some undocumented features that we don't know which could improve processing somehow, well i'm not really sure about this, those are just my considerations), you can tell, how close it was to the Dreamcast limit.

Well, also it's generally agreed to consider, that games, who pushed a Dreamcast to it's bleedin' edge, was games like Shenmue, ... and, yeah, Shenmue. I don't have any evidence on that, but it's just considered to be so.
That's all I konw on this topic,maybe guys should tell you somethin' more.

[park]

I remember deunan (dreamcast emu author) addressed this.It seems the dreamcast is quite capable under the right considtions.

Someone asked if it's possible to push 3M triangles through Dreamcast-based system in real-time. See the pictures below? The first two values shown in the second line are vertex (w) and triangle (tr) counters. That's per-frame so multiply by 60 to get per-second figures. So what do you think, possible?
Trigger Heart Exelica can do over 30000 vertexes and 44000 triangles per frame as well

[cube_b3]

Shenmue may also need to be properly optimized cause the game hangs like hell.

The disk has to be in perfect condition or the game will freeze.

I remember the discussion we had all these years back, can Resident Evil 4 run on Dreamcast?

Dreamcast died to soon, developers could've been pushed more with years however others would argue that Dreamcast was very easy to program for and very easy to optimize in contrast to the PS2.

[RyoDC]

Shenmue may also need be properly optimized cause the game hangs like hell

It's not an optimisation feature, it's about resources limit, I think. CPU processing power was just not enough to do everything without fps drowning. Also Takai Hirai said in an interview, that they used did done a lot of assembly pastings, fixing compiler poor generated code.
Well, it can be caused by a poor algorithms or not well structures used, but i don't think they are so un-smart do use appropriate algorithms and data structures

[Ayla]

In my opinion the Dreamcast still offers areas to explore. I'm not talking about commercial games but homebrew. Things like the recent OpenGL talk reveals it.

[TapamN]

There's no way Le Mans runs at 4 million polygons per second. Checking the textures for TDLM, the Le Mans track has about 1.9 MB of textures, estimating about 1 MB of textures for the cars and UI, and 1.17 MB for the framebuffer, there's about 4 MB left of video RAM for vertex data. That gives an estimated limit to Le Mans maximum output to around 1.6-2 million polygons per second at 30 FPS.

The slowdown in the Shenmue games is caused by their lack of mipmapping, which hurts fillrate. Probably 80% of slowdown on the Dreamcast is caused by lack of raw fillrate, either by too many transparencies or the penalty from lack of mipmaps on high resolution textures. The next biggest cause of slow is probably "game overhead" (like the physics/vehicle AI in Crazy Taxi and Super Runabout).

Also, I find Shenmue freezes less if you let the Dreamcast warm up a bit before playing. Playing something else for a bit first, or letting it sit on the BIOS for 5 minutes or so, seemed to greatly reduce the likelihood it would freeze while loading.

If you look at some tests, done by Ph3nom and other guys, the real number of polygons drawed by Dreamcast is around 133k per sec. (depend on the parameters and fps, of course).
133k pers sec with 60 fps -> around 2.5k polys per frame.

That's the speed of KGL, not the Dreamcast. The "pvr_mark" program that gets (IIRC) ~1.2 million is a unrealistic benchmark, since it draws individual triangles at random. Real games (that aren't terribly written) use triangle strips and have triangles clustered together into objects. I can get a bit over 4 million polygons per second, but that's not a really an accurate benchmark either, since I was drawing a lot of tiny polygons for tiny objects, when a real game would have a mix of large and small polygons. Sega's 3 million estimate for in-game results is probably pretty accurate.

Trigger Heart Exelica can do over 30000 vertexes and 44000 triangles per frame as well

What? Those numbers don't seem right. It's not the game's triangle counts I have a problem with (although they do seem a bit high, especially for the DOA2 screenshots with no characters on screen) but how does a Dreamcast game have fewer vertices than triangles? While a entire normal polygon model can technically have a ratio of around 2 triangles per vertex, the PVR uses strips, which can have at best 1 triangle per vertex (on an infinitely long triangle strip). Does he go out of his way to not count duplicated vertices for his numbers?

[PH3NOM]

If you look at some tests, done by Ph3nom and other guys, the real number of polygons drawed by Dreamcast is around 133k per sec. (depend on the parameters and fps, of course).
133k pers sec with 60 fps -> around 2.5k polys per frame.

That's the speed of KGL, not the Dreamcast. The "pvr_mark" program that gets (IIRC) ~1.2 million is a unrealistic benchmark, since it draws individual triangles at random. Real games (that aren't terribly written) use triangle strips and have triangles clustered together into objects. I can get a bit over 4 million polygons per second, but that's not a really an accurate benchmark either, since I was drawing a lot of tiny polygons for tiny objects, when a real game would have a mix of large and small polygons. Sega's 3 million estimate for in-game results is probably pretty accurate.

Trigger Heart Exelica can do over 30000 vertexes and 44000 triangles per frame as well

What? Those numbers don't seem right. It's not the game's triangle counts I have a problem with (although they do seem a bit high, especially for the DOA2 screenshots with no characters on screen) but how does a Dreamcast game have fewer vertices than triangles? While a entire normal polygon model can technically have a ratio of around 2 triangles per vertex, the PVR uses strips, which can have at best 1 triangle per vertex (on an infinitely long triangle strip). Does he go out of his way to not count duplicated vertices for his numbers?

Right, my initial tests using KGLX were maxing aroung 150k triangles / sec @ 60fps.

But I believe pvr_mark gets ~1.2 mil verts/sec, not triangles/sec. Triangles would be 400000/sec, or 6666 triangles/frame @ 60fps.

Using an early build of my GL library on DC, I made a benchmark of ~1.18 mil verts/sec @ 60fps.
In this benchmark, a bunch of "particles" are created dynamically, with a random lifespan, color, direction and velocity, translucent, untextured.
Each particle is 4 vertex quad, that is actually a triangle strip of 2 triangles for the PVR.
So, at 1.18 mil verts/sec @ 60fps is actually 590000 triangles / sec, or 9833 triangles/frame.
But as TapamN mentioned, this is certainly not an optimzed benchmark, instead, a brute-force method.



And lol that also botherd me, how can so few vertices in DOA create so many triangles?
What if it is not a glitch, rather, extremely efficent rendering?

[cube_b3]

Also, I find Shenmue freezes less if you let the Dreamcast warm up a bit before playing. Playing something else for a bit first, or letting it sit on the BIOS for 5 minutes or so, seemed to greatly reduce the likelihood it would freeze while loading.

Damn, that is so true.

My current save file of Shenmue is acting up on Disk 2, and I wasn't sure if the lense was dying out or the game was scratched (very faint marks on the disk), so I decided to play some light homebrew first and then popped Shenmue. It worked a whole lot better, still froze after a while though.

Once Shenmue freezes, it will freeze a whole lot faster on your next playthrough.

What is the logic behind heating up the Dreamcast?

P.S. What are mipmaps?

[Ayla]

P.S. What are mipmaps?

Long story short, mipmaps are duplicatas of a texture at lower resolutions, that will be shown instead of the real texture when the distance of the object on which it is applied increases. The lower resolutions ensure a faster rendering.

[cube_b3]

Oh yes, you can see them quite prominently in Duke Nukem Forever.

[Neoblast]

Shenmue didn't froze for me even when the dc was cool.

Shenmue doesn't have mipmaps?

Being so adamant on performance as they were for the shenmue games I don't know how they didn't see a performance gain with that...

[GyroVorbis]

Shenmue didn't froze for me even when the dc was cool.

Shenmue doesn't have mipmaps?

Being so adamant on performance as they were for the shenmue games I don't know how they didn't see a performance gain with that...

They would have had to sacrifice other textures for the mipmaps.

edit:

I remember the discussion we had all these years back, can Resident Evil 4 run on Dreamcast?

RE4 could BARELY run on PS2. I recall reading an article from the developers, where they talked about the painstaking process of drastically reducing the polygon count and texture sizes to get it working on the PS2. They did a great job, and it might not look like it in some places, but the PS2 version took some serious graphical hits compared to the GC.

I think if you reduced the graphics enough, RE4 could be on the N64...

A mobile version of RE4 came out for iOS a few years back, when the specs of the PowerVR chip in the devices was much closer to the Dreamcast's. I would like to think that looked quite similar to what RE4 would have to look like on the DC... imo, it still looks pretty good (I want to say the textures look better than they did on the PS2).

[Neoblast]

Still if the dreamcast had been continued I think SEGA could have squeezed its potential a lot more in further sdk.

Just look at some of the latest ps2 games and compare them to the ps2 games on the dreamcast era.

Heck even some dc ports were better than the ps2 counterpart ( texture wise, controls, loading screens... ).

Quake 3 arena for the ps2 took forever to load... nearly one minute or more...

So I think RE4 on dc would look almost the same as the ps2 version, maybe a little more reduced... but close..

[chao2]

Im confused so would the dreamcast ever be able to reach a polygon count to 4 -6 million polygons with programming tricks or is that just impossible? If it couldn't does this mean the dreamcast wouldn't be able to compete graphically against the ps2,xbox gamecube in multiplats ? Im have no knowledge of programming whatsoever so sorry if I sound like an idiot.

[BugoTheCat]

There's no way Le Mans runs at 4 million polygons per second. Checking the textures for TDLM, the Le Mans track has about 1.9 MB of textures, estimating about 1 MB of textures for the cars and UI, and 1.17 MB for the framebuffer, there's about 4 MB left of video RAM for vertex data. That gives an estimated limit to Le Mans maximum output to around 1.6-2 million polygons per second at 30 FPS.

I would guess that there is a lot of instancing (the same car object mesh send many times, trees and all that) and some procedural geometry sent from the CPU (maybe the creation of the road). 4 millions per second doesn't mean that there are data for 4 millions stored in the videoram every time. If there was a single 4 million polygon object that had to be loaded once then it would be like you say. Even though I don't know if there is something different with the Dreamcast architecture I am missing, I speak as an OpenGL PC programmer.

What? Those numbers don't seem right. It's not the game's triangle counts I have a problem with (although they do seem a bit high, especially for the DOA2 screenshots with no characters on screen) but how does a Dreamcast game have fewer vertices than triangles? While a entire normal polygon model can technically have a ratio of around 2 triangles per vertex, the PVR uses strips, which can have at best 1 triangle per vertex (on an infinitely long triangle strip). Does he go out of his way to not count duplicated vertices for his numbers?

It seems counterintuitive at first, when you think about geometry and a triangle usually having 3 vertices and maybe no less than 1 when sharing, but it's not the case. Many factors might play a role, like the topology of the mesh. I was wondering about that too, yet I used some models and many of them had less vertices than triangles (for example the stanford bunny, oh and a lot of other models there, usually less vertices than polygons, isn't that strange? (one would argue that somehow it happens because they are scanned, but they look fine to me without holes or more triangles than needed when I render them)). But also think of the cube, 8 vertices and 12 triangles (or 6 quads). So yeah, it's entirely possible and maybe it's even the norm, not sure why though.

p.s. I was speaking with some guys at Assembly party about how they find Dreamcast too slow, too much polygons and you are busted, that's one story. From the other side, I was speaking a long time ago with a distant friend working on a 3d engine, extremely optimized in pure assembly and he claimed reaching 50000 per frame at 60fps, and not just random polygons just to hit a benchmark, but loading various arbitrary 3d scenes with simple lighting and textures. This sounds like urban legend, yeah, I haven't seen it either, he doesn't want to release it yet. So I don't know if it's true, since I haven't seen it. But 50000 * 60 = 3 million per sec, that sounds closer to the theoritical limit.

[PH3NOM]

It seems counterintuitive at first, when you think about geometry and a triangle usually having 3 vertices and maybe no less than 1 when sharing, but it's not the case. Many factors might play a role, like the topology of the mesh. I was wondering about that too, yet I used some models and many of them had less vertices than triangles (for example the stanford bunny, oh and a lot of other models there, usually less vertices than polygons, isn't that strange? (one would argue that somehow it happens because they are scanned, but they look fine to me without holes or more triangles than needed when I render them)). But also think of the cube, 8 vertices and 12 triangles (or 6 quads). So yeah, it's entirely possible and maybe it's even the norm, not sure why though.

When it comes to indexed geometry, yes it is easy to exceed the number of vertices in polygons.
That is how a cube of 8 vertices can become 12 triangles.

Problem is, the PVR does not support indexed geometry.
As I have recently implemented glDrawElements() into my build of Open GL for DC, indexed geometry is certainly more efficient.
For example, in the case of an 8 vertex cube indexed mesh, I am only transforming ( and lighting, if enabled ) the 8 vertices of the mesh.
After lighting and transform, I go through the indices and unpack the elements into the Vertex Buffer for submission to the PVR as either triangles, quads, or triangle strips.
So in the end the SH4 still needs to send ((3*2*6) = 36) vertices to the PVR using triangle primitives, or ((4*6) = 24) vertices as quad primitives.

[chao2]

If the dreamcast lasted longer do you think the graphics would be comparable to a psp?