引用:

原帖由 hourousha 于 2010-8-20 17:36 发表

PS也有GTE做T&L的工作。那不是更超前了。
RSP是8way-fixed_point的格式，而T&L是需要浮点运算的，只能用定点数模拟，因此才有‘一开始SGI提供的数学库由于追求准确而速度过慢’的现象发生。GTE好歹还是原生浮点运算支持的。
要说N64比PS先进的，还真就是RDP，毕竟PS连Z缓存都没有，所有的三角形在‘显卡处理’的阶段都只是一个平面的三角形而已。遮挡关系全由绘制顺序而定（没Z-Buffer自然深度检测无法实现），至于像素属性的透视矫正则更加没有希望了。

GTEはCPUのコプロセッサとして、座標変換や光源計算、例えば固定小数点形式の行列やベクトル演算を並列処理機構により高速に演算します。
GTE哪里来的原生浮点运算啊，连PS的开发文档上都说不支持浮点格式。

引用:

原帖由 md2 于 2010-8-19 16:16 发表
这样也就能知道为什么32位机时代主机的3D能力相差这么大了。实际上差异不是因为主机的运算能力，而是主机选择的即时演算方式。当时的主机采用光栅化渲染效率最高。PS的路线不全对但最适合发挥主机潜力。N64路线正确但 ...所谓“SS没有3D机能”是错误的说法，SS的3D游戏当然是计算多边形，它所没有的是“光栅化渲染方式”
3D游戏的运算肯定是多边形，它的差异在于最后的渲染（包括贴图光照等特效）是用其他方式实现的

要是没有光栅化的话你让SS怎么让显示画面

引用:

原帖由 hourousha 于 2014-6-27 22:34 发表

4年前的老坟您也挖……
不过这点确实是我搞错，GTE有若干种定点格式，比如1.27.16或1.31.12等。不过基本不影响我说的结论，准确说T&L需要的是相当的动态范围，浮点数的动态范围自然是非常理想，不过GTE的定点格式动态范围也算尚可，最关键是不用开发者去太操心这个，尤其是中间运算的容错和精度等等（其实是想去操心也没得操心），而RSP的8way_FX16就不是这么回事了。
也就是说RSP直接把uCode的Ref扔给开发商，则对大部分厂商来说虽然是可编程了但基本没法用，于是乎只好去用现成的SGI库，然后结果就是N64很快被HLE……而且就如图所示，fast3D这个库，过于注重运算的精度和健壮性，速度其实是相当慢的，明显低于PS的GTE提供的性能。

哈，我看到了就顺便回复了。
16位定点不管套用那种格式还是16位定点，动态范围是不会有变化的，如果能扩大动态范围那就变成浮点了。不过毕竟对于PS那个年代来说，这样精度还是完全够用的，至少你在画面上是完全看不出来的，就算真的遇到精度问题还有许多手段可以修正。PS的真正优势还是像你所说的在于开发工具成熟，开发者不用过多的考虑这些硬件上的问题。而N64的RSP有8个16位的乘加器作为矢量单元，在进行坐标转换时默认是32位的定点格式，所以在精度上肯定要高于PS的GTE，但是在速度上并没有和PS的GTE以及SS的SCU DSP拉开太大的差距，所以给感觉性能不高的样子。另外N64的CPU是带FPU的，到是能够进行原生的浮点运算，但是速度依然是不理想。总的来说N64的硬件设计上还是太过于保守了，有好的东西，但是都不太好用。加上老任有急于推向市场没有提供成熟的开发工具，所以还是一个比较失败的硬件。

引用:

原帖由 SONIC3D 于 2014-6-30 20:03 发表
打开N64的豪华变速箱，发现里面只有2套固定传动比的齿轮，并且另外一套需要停车花半小时拆卸组装才能切换使用。
:D

不单单是开发工具上的问题。N64那8个用来处理顶点的16位乘法累加器除了进行顶点计算外还负责处理音效，再加上要求在计算精度上要比PS SS高，速度能快的起来才怪。而如果CPU用来进行坐标转换效率又明显不如DSP来的高。老任的硬件真的是让人无语。。。。

[ 本帖最后由 lemonninja 于 2014-7-2 00:30 编辑 ]