SEGA Dreamcast reality based capabilities.

Akumajou

Regular
I tried using the search but could not find the information I was looking for however I know or at least believe I knew everything about Dreamcast/Naomi1 technical specs and capabilities.

What I am trying to get to the bottom of is:

Was FSAA a real, executed capability on Dreamcast?

Sega says 3 million poly, other sources say 6.5 million who is right?

Specially with reguards to Sega claiming Naomi 2 did 10 million polys easy as standard with dual SH4s, dual PVR2s and a t&a chip.

Also as far as FSAA, afaik only 3dFX was making claims of FSAA for PC back in 1999, 2000.

Also can you please provide sources, specially official if available and I know they exist because I collected them and read them years ago but do not have access to them anymore.

This is not a Dreamcast forever thread, just technical questions only, in my personal opinion I favored the Saturn as my favorite Sega console even over the DC as I just felt that it never reached (even with Shenmue) the effort that went into Saturn as far as game development.

How much did the internet modem add to the price of the console? and who paid for that? I remember that the Saturn Netlink was retailing around $199 when released.

How much did the console cost to make? in light of what we know about PS3's cost greatly exceding the price it was sold at.

Thats it for now, if I have other questions I will try to bring them up, thanks.
 
Was FSAA a real, executed capability on Dreamcast

Sega says 3 million poly, other sources say 6.5 million who is right?
The Dreamcast port of Omikron ran with 2X super sampling (1280*480). If you use a VGA cable, it's pretty easy to see it.

I know of a homebrew demo that does 3.12 million polygons per second on the DC. It's an animated, lit torus. It rotates while extending and retracting curved spikes and comes with a simple profiler, which indicates that it's pretty close to maxxing out the hardware. It doesn't run on any emulators I've tried, but you can download the source and precompiled SREC files and run it on a real DC without any problems.

Here's an interesting quote from the source (one of the few comments in what mostly assembler):
! Test example for the Render module
!
! Draws a morphing donut with 2*DONUTSTEPS1*DONUTSTEPS2 stripped triangles
!
! Border colours:
! VSync interrupt sets red border (at top of screen)
! RenderDone interrupt sets yellow border (position varies)
! Vertex registration done sets green border (steadily somewhere on screen)
!
! Currently, the code manages to push out approx. 55k striptris at 60fps.
! It is possible to do the CPU/TA work at least twice as fast.
! The rendering hardware will not be able to draw more than 60k-80k
! striptris per frame though (exact figure depends on size and orientation
! of the tris)
!

DONUTSTEPS1 = 130
DONUTSTEPS2 = 200
 
I tried using the search but could not find the information I was looking for however I know or at least believe I knew everything about Dreamcast/Naomi1 technical specs and capabilities.

What I am trying to get to the bottom of is:

Was FSAA a real, executed capability on Dreamcast?
Yes. Did any games use it? No idea.
Sega says 3 million poly, other sources say 6.5 million who is right?
It rather depends on the sizes of the polygons. The triangle setup engine, IIRC, had a peak rate of around 7M setup calcs/s but a triangle setup calculation had to be done for every triangle that was in a tile. If every triangle was thus in two tiles, the rate would be ~3.5M. Since a tile was 32x32, triangles could be "reasonably" large and still only fall into only 1 or 2 tiles. Of course, if you have anything other than tiny polygons then the fill rate is more likely to be a bottleneck anyway.

Specially with reguards to Sega claiming Naomi 2 did 10 million polys easy as standard with dual SH4s, dual PVR2s and a t&a chip.
Naomi 2 only had a single SH4 + Elan (T&L) and a pair of CLX2s. The figure of 10 million polys (which is conservative) also assumes using 5 or 6 lights per triangle. More lights would cause it to slow down.
Also as far as FSAA, afaik only 3dFX was making claims of FSAA for PC back in 1999, 2000.
The equivalent of CLX2 in the PC also did FSAA.
Also can you please provide sources, specially official if available and I know they exist because I collected them and read them years ago but do not have access to them anymore.
Is "the horses mouth" reliable enough? :)
 
Naomi 2 only had a single SH4 + Elan (T&L) and a pair of CLX2s. The figure of 10 million polys (which is conservative) also assumes using 5 or 6 lights per triangle. More lights would cause it to slow down.



I assume that the standard Dreamcast and NAOMI could *not* handle 5 or 6 lights per triangle at 3.5 million polys/sec, and that the 10 million poly/sec NAOMI 2 could do 5-6 lights per triangle because of the ELAN T&L chip. Would that be true ?
 
Megadrive1988 said:
I assume that the standard Dreamcast and NAOMI could *not* handle 5 or 6 lights per triangle at 3.5 million polys/sec
Not in the context they were defined for Naomi2 (IIRC local lights with specular component, which would put DC well below 3milion with about two of them).

That said, we've come some ways since those days as well - among other things we now have lighting solutions that are invariable with number of lights per vertex (ie. it doesn't matter if you use 1 or a 100) - granted there are restrictions (as always) but the term "light" really doesn't mean much without clarifying a context (from light model to particular properties).
 
I assume that the standard Dreamcast and NAOMI could *not* handle 5 or 6 lights per triangle at 3.5 million polys/sec, and that the 10 million poly/sec NAOMI 2 could do 5-6 lights per triangle because of the ELAN T&L chip. Would that be true ?
Yes. That was what the Elan chip provided (along with some clipping functionality that offloaded work from the SH4 and assistance for the bump mapping set up IIRC).

Not in the context they were defined for Naomi2 (IIRC local lights with specular component, which would put DC well below 3milion with about two of them).

That said, we've come some ways since those days as well - among other things we now have lighting solutions that are invariable with number of lights per vertex (ie. it doesn't matter if you use 1 or a 100) - granted there are restrictions (as always) but the term "light" really doesn't mean much without clarifying a context (from light model to particular properties).
I guess you are referring to "pre-computed" SH basis functions? Presumably that limits you to static lights, albeit a large number.
 
Nice comparison. U know if there's the same with PS2 in the table?
Spotted one mistake...
S3TC advantage over the DC's VQ compression, is that it allows transparencies to be compressed also.
DC's VQ can have transparency as well, in fact, it would probably do a far better job since at 4bpp S3TC can only have 1 bit of alpha and needs to expand to 8bpp have more transparency levels.
 
Thank you for your replies to Heinrich and Simon F and others, I will be replying soon but I am going over the information before I make a comment.

To Heinrich4, I new about segatech for a long time, always visited it but had not gone there for years, thanks for posting that link.
 
Back
Top