引用:

原帖由 SONIC3D 于 2009-6-22 17:14 发表


也不能光看主频，光看主频数值的话SS的两块SH2每块可都比Model2的那块80960高，关键是双CPU协作开发困难而且更重要的是缺少类似PS中向量处理器的矩阵乘法硬件，对3D作品的效率产生极大影响，所以移植个model2的东 ...

一方面SS没有GTE这种专用矢量运算处理器，因此即使slave SH2发挥到头，处理3D变换的速度也还是不如PS(SISD和SIMD怎么比速度)，此外，SS的Texture Unit（或者叫做sprite mapping unit或类似的东西更合适）其实和通常的TMU实现不同，因此在绘制自由变形的带贴图sprite时，半透明不可用233……
简而言之，PS和SS都不属于完善的3D硬件——比如PS也不带Z-Buffer，但无论如何，PS比SS更接近‘适合3D’的硬件。

引用:

原帖由 aquasnake 于 2009-6-23 10:50 发表
当时的软件技术没有达到这个层次，在今天，同样是2D ENGINE，却可以使用矢量技术，也就是类似FLASH的2D矢量变形实现模拟3D的效果而没有POLYGON运算的积木颗粒感。

SS的半透明，用的是2D的alpha blending,也就是 buffer里面的实现或运算（实际上这个用硬件完成的或运算）。是前景与背景的叠加。

PS的半透明，实际上是光源特效。

光源特效？半透明？你搞混了两个概念。也就是fragment operation和framebuffer operation的区别。
你见过不是framebuffer操作的半透明效果吗？它都是在primitive（SS上称为part）写入frame buffer时的操作，无非就是Current FB Color*A+primitive fragment Color*B的模式。
此外无论SS和PS，都称不上alpha blending，因为它们的颜色模式里都不支持alpha。也就是说它们是预定了几组上面公式的A、B值而已比如SS和PS都支持的半透明就是A=B=0.5，PS还支持A=B=1.0、A=1.0 B=-1.0、A=1.0 B=0.25这几种混合模式，而SS则除半透明之外只支持几种非混合模式，比如A=0.5 B=0、A=0 B=0.5，这些非混合模式对于PS来说没有支持的必要，因为PS支持shading function（估计这是你所说的光源特效，一般称为shading function或者texture function），换句话说它可以直接改变公式中的primitive fragment Color而SS不行。
也就是说，你的表述改成下面这样才是正确的。
SS和PS的半透明都是framebuffer特效，而SS实现一部分PS的‘光源特效’用的也是framebuffer特效。
此外由于SS本身的贴图是以sprite为根本目的，所以和一般的TMU不同，在自由形变sprite下，同一个像素可能要写入多次，因此带混合的framebuffer操作不能运作。

引用:

原帖由 aquasnake 于 2009-6-23 15:01 发表
2D engine中，静态半透明叠加，是用frame buffer,动态半透明，是sprite buffer中定义某色为透明色（当然透明的深度还可以分阶）。这个目前在2D游戏或者MMI制作的时候都可以看到。实际上，除非大面积用硬件处理处理 frame叠加，小的活动块都是用软件来实现。

你说的这个是类似colorkey之类的东西，这在PS、SS中当然是硬件支持（类似检测color的MSB）的——这是sprite渲染的必要能力，不过这东西只能是透明或不透明，不能半透明。它决定的是该pixel是否执行写入framebuffer的操作。如果说与当前硬件功能类比，这个更像alpha-test功能。这个同样是framebuffer操作。

引用:

原帖由 aquasnake 于 2009-6-23 15:01 发表
PS则完全是用3D的处理，光源运算(shading model)就可以了，已经没有sprite buffer了。
形象地描述，2D效果就是一个一个点（BMP）描出来，3D是统一后期渲染，3D要简单地多

shading function改变的是fragment color，比如把texel颜色用插值的顶点颜色（高洛德模式）进行改变。
半透明还是得靠后面的frame buffer操作实现，因为只有在那时才能提取framebuffer当前的颜色。
SS和PS的区别，还真不是一个点一个点描出来这么简单。一方面是SS缺乏PS的shading function，另一点在于SS的贴图操作是基于四边形形变，而PS是基于uv-TMU操作，因此PS画polygon才是一个点一个点描，而SS画sprite更像是一条边一条边描——因此在自由变形sprite中才会有重复写点操作。

[ 本帖最后由 hourousha 于 2009-6-23 15:45 编辑 ]

引用:

原帖由 GAYBL 于 2009-6-24 02:28 发表
N64相比PS的3D又有什么区别呢？

有些相似的地方，比如PS有GTE，而N64有RSP,这两个都是矢量处理器（区别是后者是16位定点数）
N64的3D功能比PS更先进，比如N64是支持Z-buffer的而PS不是，相应的诸如透视矫正等功能自然PS也没有，在纹理过滤上N64自然也明显比PS要强，以通常的观点看，N64算是一款‘完整’的3D硬件，而缺少Z-buffer的PS则有些牵强。
当然N64也有弱点，使用Z-Buffer，显然对带宽与填充率需求更大，因此据开发者反映N64发生bandwidth-limit或fillrate-limit的情况很多。此外就是RSP由于是定点数运算而非浮点数运算，并不非常适合3D的T&L尤其是诸如需要除法的情形，编程上比较困难经常要和精度等做斗争，而任天堂直到N64后期才把RSP的文档和工具发放到少部分开发者手中并且还存在缺陷（比如无法debug）。因此RSP很长时间内对于大部分开发者来说就是一个黑盒，只能调用Nintendo提供的库函数来使用它而无法直接写µcode，这也是为何N64成为了很快被HLE（高阶模拟，指模拟针对的是函数功能而不是硬件指令）的主机的原因之一。而偏偏Nin提供的库（fast3D）精度很好但效率比较低……因此就速度上，N64相当时间内并不十分理想。此外N64对纹理大小限制比较紧，因此普遍来看纹理相对细节比较少并不只是由于采用卡带载体造成的。不过由于有纹理过滤等功能，即使纹理分辨率较低的情况下N64游戏画面的观感也是不错的。

[ 本帖最后由 hourousha 于 2009-6-24 09:53 编辑 ]

引用:

原帖由 Nigel 于 2009-6-25 12:16 发表
RSP16位定点？做什么用？
做几何变换的话实在233
N64有没有大场景游戏，怎么处理的

RSP主要工作的就是T&L，8-way-FixedPoint16 SIMD
用定点模拟浮点，甚至高精度计算并不是新鲜事，早期没有X87处理器，或者编译器不支持x87指令的时代不也都过来了么呵呵，当然速度自然不很理想，精度和速度是一对矛盾嘛。

引用:

原帖由 Nigel 于 2009-6-25 13:00 发表
定点模拟浮点是用软件方法模拟本来该硬件做的浮点数运算，精度本身没有损失
RSP这是定点硬替代浮点，而且只有16位。16位精度给Z Buffer用都嫌少，这里直接用来T&L
这种东西都省，游戏开发不困难才怪

RSP是可编程的啊（只不过资料工具到了后期才提供），而nin提供的那个现成库之所以慢就因为讲究精度的原因。当然如果换成浮点SIMD自然这种问题就少很多了，不过一方面自然成本高，另一方面或许SGI当初就没提供给nin这种方案也未可知。RDP也有诸如fillrate的问题，所以有些N64游戏，实际上把Z-buffer这功能给闲置了。