EGM Feb '97 Lockheed Real3D Saturn upgrade for VF3 and standalone console Pluto

x

 

If I am not wrong the geometry processing is done by the second processor when the other SH2 is idle, in the case of the Playstation this is made by the GTE when the R3000A is idle.

I don´t know how things run in Saturn but I doubt that it is highly different than the original Playstation, both of them lacked a triangle setup (which work was nothing more than the transformation of vertex 3D values to 2D values), GTE does this before sending the transformed polygons into fragments to the GPU.

-GTE has an internal table with 256 values.

-The information (X,Y,Z) from the polygon becomes (X,Y) and Z is stored into the internal table after a division (Z/4).

-The console draws things from backward to forward, for knowing the position of everyone of the fragments (and with this its real size in the screen) the algorithmn is: AddPoly(ot+256-z, poly0). Where z is the value of the table.

I don´t know how the second SH2 does this but knowing how it isn´t a specialized processor in this matter then it goes with an huge disadvantage. If I am not wrong the first specs for Saturn used a dual 68030 until Sega changed them for two SH2 that have twice the performance, the question is that why Sega never assumed the use of a coprocessor for geometry calculations, it could have been a better solution and less expansive, unless Sega was without time or they made the console for competing against 3DO and not Playstation.

 

x

 

The problem here is that you believe that the 3D math and the drawing of the polygons are done by the VDP1 but it only does the rasterizer part of the rendering, then some other processors have to do all the geometry processing.

This is why I am talking about the 2nd SH2 because we are not talking here about a paralel architecture, both SH2 don´t work at the same time then when one is iddle accessing to the memory then the other can do the geometry processing and send it to the VDP1. Knowing how Saturn was hard to develop because any programmer had to know how to synchronize both processors I can imagine the hell and why one of the audio DSP was used for the geometry processing in later games since it was more easy to develop.

In other words:

First Generation Saturn games ---> Geometry done by the 2nd SH2, rasterization made by VDP1, framebuffer control made by VDP2.

Second Generation Saturn games ---> Geometry done by one of the Audio DSP, rasterization made by VDP1, framebuffer control made by VDP2.

The difference between a 2D GDP (Graphics Display Processor) and the rasterizer part of a 3D card is 0, they are both the same thing, the difference is that the 3D engine has got a geometry processor that transforms the 3D data into 2D one and is sent in form of fragments to the rasterizer, this is why sometimes they are called fragment controlers or fragment processors.

 

x

 

That would be me.Still can't find the thread though.SEGA was ripping off their customers.And they paid the price with the Dreamcast I guess.

 

If you guys really want to know more about Saturn development, the Beyond3D forum is the place to go. There are developers there who have worked with just about every console. I'd start with a search of the forum there.

 

Thanks a lot for the info, i will look there.

 

Yeah there are a bunch of threads on there with in-depth detail if you search.

Ex:
http://forum.beyond3d.com/showthread.php?t=8976&highlight=saturn+geometry
a sample:

Some more...
http://forum.beyond3d.com/showthread.php?t=9587&highlight=saturn+geometry

 

woah,,,a lot to read..!