小黑屋
原帖由 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自然深度检测无法实现),至于像素属性的透视矫正则更加没有希望了。
查看详细资料
TOP
原帖由 md2 于 2010-8-19 16:16 发表 这样也就能知道为什么32位机时代主机的3D能力相差这么大了。实际上差异不是因为主机的运算能力,而是主机选择的即时演算方式。当时的主机采用光栅化渲染效率最高。PS的路线不全对但最适合发挥主机潜力。N64路线正确但 ...所谓“SS没有3D机能”是错误的说法,SS的3D游戏当然是计算多边形,它所没有的是“光栅化渲染方式” 3D游戏的运算肯定是多边形,它的差异在于最后的渲染(包括贴图光照等特效)是用其他方式实现的
原帖由 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提供的性能。
原帖由 SONIC3D 于 2014-6-30 20:03 发表 打开N64的豪华变速箱,发现里面只有2套固定传动比的齿轮,并且另外一套需要停车花半小时拆卸组装才能切换使用。 :D