» 您尚未登录:请 登录 | 注册 | 标签 | 帮助 | 小黑屋 |


发新话题
打印

[业评] 日厂技术大幅度落后就是源于ps2时代吧

引用:
原帖由 SSforME 于 2023-8-4 22:09 发表
TNT2 M64频率跟gs一样
特效比gs多
显存比gs大
带宽比gs小

480p下不如gs
600p及以上比gs强
gs都到不了这分辨率
哥们你不会ptsd了吧,不就实话实说你m64低端入门了吗,别这样啊。。。。


TOP

引用:
原帖由 小悟空 于 2023-8-4 22:42 发表


哥们你不会ptsd了吧,不就实话实说你m64低端入门了吗,别这样啊。。。。
m64低端入门不假
gs更拉跨啊



TOP

引用:
原帖由 SSforME 于 2023-8-4 22:46 发表

m64低端入门不假
gs更拉跨啊
你说的对,给你个赞


TOP

引用:
原帖由 SSforME 于 2023-8-4 22:46 发表

m64低端入门不假
gs更拉跨啊
单管线二次贴图 64bit显存是怎么想到跟16管线 2560bit显存来对线的?

TOP

引用:
原帖由 卖哥 于 2023-8-4 22:51 发表

单管线二次贴图 64bit显存是怎么想到跟16管线 2560bit显存来对线的?
特效比gs多
显存比gs大
带宽比gs小

480p下不如gs
600p及以上比gs强
gs都到不了这分辨率

TOP

引用:
原帖由 SSforME 于 2023-8-4 22:52 发表

特效比gs多
显存比gs大
带宽比gs小

480p下不如gs
600p及以上比gs强
gs都到不了这分辨率
我不贴全
引用:
Parallel rendering processor with embedded DRAM "Graphics Synthesizer" (GS) clocked at 147.456 MHz
279 mm² die (combined EE+GS in SCPH-7500x: 86 mm², 53.5 million transistors)
Dedicated connection from and to EE and VU1 via GIF
Programmable CRT controller (PCRTC) for output
Video output resolution: Variable from 256×224 to 1920×1080

TOP

引用:
原帖由 卖哥 于 2023-8-4 23:03 发表

我不贴全
散了吧,这位明显已经被喷魔怔了

TOP

posted by wap, platform: Android
从头看到尾,就是自己一知半解半瓶子咣当被怼了还死鸭子嘴硬

TOP

PS2架构落后但是规模庞大,结合奇技淫巧应付了当时3D游戏的需求。
但这种奇技淫巧无法复制到之后游戏机上趋于主流的3D图形开发导致落差不是很符合主楼的观点么?
为啥楼主非要认为GS弱,恰恰是强才足够带歪人呀。

TOP

引用:
原帖由 Nemo_theCaptain 于 2023-8-4 17:36 发表

PS2当然有Shader,实际上PS1都有Shading的过程,只是PS1是不可编程的
PS2的Shader具备一定的编程性,但灵活度逊于DX8,不过依然可以实现很多人想不到的功能
比如法线贴图PS2是能做的,只不过他跟Xbox那种显卡负 ...
从任何意义上讲,PS2都不支持Shader。
VertexShader方面,PS2没必要支持,它使用VUs功能要更灵活,虽然优化难度比使用VS(无论硬件VS还是MS实现的软件处理版本)要高太多。
PS或Fragment Shader,GS显然是完全意义上的不支持。GS支持的Fragment操作就是最简单最基础的操作,基本所有复杂点的效果都要靠multi-pass blending。
至于所谓的GS法线贴图的‘奇技淫巧’,只能说探索精神可佳,一方面GS的分量相乘是无符号的,想解决有符号就得费一番功夫变成多pass;其次它没有做点乘需要的分量横向相加功能,这就不能以primitive为单位而需要做全屏后处理,将32bit的frame buffer(PSMT32)cast成8bit的PSMT8进行多pass累加,而由于PSMT32与PSMT8的内存布局差异,这个累加还不能以一般意义上post processing那样使用screen quad进行,而得使用一堆细长的小多边形进行操作。因此这基本只停留在‘探索可能性’的研究,类似在minecraft里搭门电路甚至CPU,没什么实用价值。想实现点简单凹凸效果,用早先的emboss凑合一下也就是了。
第一代的Shader,确实还有很多旧时代的影子,就比如尽管功能有进化,但NV1x和NV2x的register combiner都是4进3出的结构,也都以Final Combiner进行结尾,PS1.1-1.3反而是Register Combiner的功能子集,因此微软才在XDK版的Shader里加上了专门对应register combiner的PS1.x。从另一个角度说,如果开发个对应NV1x Register Combiner的pixel shader,叫他PS 0.7也未尝不可。NGC的TEV虽然缺少原生的Dot3功能,但它的dependent texture功能比NV2x还要强,而且Stage数量也不少,所以说NGC有shader功能并不为过,区别只是API与SDK的水平。当然我之前也说过,NGC没有VS只有硬件T&L,反而是个问题。
但尽管第一代Shader过渡性质浓厚,但仅就GS的fragment可编程性而言,恐怕还无法达到DX6.1的标准,毕竟DX6.1里有环境凹凸贴图这个dependent texture前身(而这个功能甚至NV在Geforce3之前都不支持)。GS真的就是凭借‘简单而快’来生存的。

[ 本帖最后由 hourousha 于 2023-8-4 23:19 编辑 ]
本帖最近评分记录

TOP

引用:
原帖由 hourousha 于 2023-8-4 23:15 发表

从任何意义上讲,PS2都不支持Shader。
VertexShader方面,PS2没必要支持,它使用VUs功能要更灵活,虽然优化难度比使用VS(无论硬件VS还是MS实现的软件处理版本)要高太多。
PS或Fragment Shader,GS显然是完全意 ...
我说的就是PS2的架构本身和PC没有直接可比性,因为谁都知道GS是个没啥特效单纯追求吞吐的傻块,剩下的都是EE的奇技淫巧
如果说这些活是EE(VU)干的就不算Shader那也无所谓,总之活还是这些活,干就干了
法线贴图之前别人一直是用尼奥之路举例子,那就是说这只是个效果比较好的凹凸贴图

NV1x Register Combiner确实是有人做过通用运算的早期尝试,用于一些简单的数学问题

[ 本帖最后由 Nemo_theCaptain 于 2023-8-4 23:55 编辑 ]

TOP

引用:
原帖由 卖哥 于 2023-8-4 23:13 发表
PS2架构落后但是规模庞大,结合奇技淫巧应付了当时3D游戏的需求。
但这种奇技淫巧无法复制到之后游戏机上趋于主流的3D图形开发导致落差不是很符合主楼的观点么?
为啥楼主非要认为GS弱,恰恰是强才足够带歪人呀。
牛逼了,卖哥给出正解,正是因为主机的深度定制走的是旁门左道,所以让第三方难以应付之后的主流开发,就像苏星河

TOP

引用:
原帖由 Nemo_theCaptain 于 2023-8-4 23:20 发表

我说的就是PS2的架构本身和PC没有直接可比性,因为谁都知道GS是个没啥特效单纯追求吞吐的傻块,剩下的都是EE的奇技淫巧
如果说这些活是CPU(VU)干的就不算Shader那我也无所谓
法线贴图之前别人一直是用尼奥之路 ...
其实并不只是EE的奇技淫巧,而是专用硬件平台Direct to metal的特性,就好像各种内存cast,把某种格式的纹理当成另一种格式的来使用,比如鬼武者3就把z-buffer,直接当8bit索引颜色纹理来用,而索引表里是预计算的映射深度的大气散射颜色,等于直接免费做了一次大气散射的查表操作。包括XBOX也可以直接改纹理头信息做格式cast,甚至还能通过VertexShader改变Const Buffer里的值,这些如果是PC上DirectX这种通用化的API,出于硬件兼容与安全性考虑,都不可能开放。
我也说了VU干的比VS还要更灵活。但VS强在保持了一定的灵活性外,不用费太大精力来优化,比如可以自动切换线程来隐藏指令延迟这点,就能让优化VU代码的人羡慕死。
GS法线贴图那玩意,是一开始有人研究在PS2上做延迟渲染的可能性的副产物。使用类似后处理方式做分量横向相加也是这个原因。但后来发现,GS的Edram的空间做延迟渲染实在是太小了……
想出点凹凸效果,方法是有很多,使用法线贴图,虽然相对‘准确’,但效果倒不一定永远最好——首先它对素材的要求很高。至于尼奥之路用的什么,不清楚。
本帖最近评分记录

TOP

引用:
原帖由 hourousha 于 2023-8-4 23:58 发表

其实并不只是EE的奇技淫巧,而是专用硬件平台Direct to metal的特性,就好像各种内存cast,把某种格式的纹理当成另一种格式的来使用,比如鬼武者3就把z-buffer,直接当8bit索引颜色纹理来用,而索引表里是预计算的 ...
PS2时代特效处理我印象最深的是伪HDR
AC5+0和旺达都有,比一般的bloom有更复杂的层次感
后来DF做旺达的视频我才知道实现方式
室外场景做一段代码时刻判断太阳被遮挡的程度,具体方式没说,可能类似Godray可能是Raycasting
根据这个调整全屏bloom强度,镜头或太阳遮挡程度发生变化后再改变强度

最后的效果当然不如HL2或者Crysis这种tonemap做的好的HDR
但比战争机器那种和黑白差不多的HDR细腻多了
代价么,当然就是这段代码本身,和他的执行资源了,只要有太阳就执行代码,而且时刻根据镜头相对太阳位置的区别去判断

[ 本帖最后由 Nemo_theCaptain 于 2023-8-5 00:25 编辑 ]

TOP

posted by wap, platform: Android
ps2日厂巅峰啊

TOP

发新话题
     
官方公众号及微博