引用:

原帖由 一直努力寻找 于 2024-4-2 19:57 发表


喷了，不懂技术，我写过jpeg解码器的，不知道你有多懂，像你这种动不动说些不着四六大话的，反而基本都是半桶水都不满出来唬人的，看你以前的发言，基本就知道是个妄人了。

ps的视频解码能力强过土星基本也是 ...

既然你自称写过jpeg解码器
那我可以告诉你ps mdec和JPEG区别
ps mdec宏块大小是16x16
jpeg是8x8
JPEG最终会用到Huffman压缩算法
ps mdec省略了这一步

ps mdec的视频源是yuv420

所以你该知道两者区别多大了

引用:

原帖由 一直努力寻找 于 2024-4-2 20:16 发表
要真搞过这些东西就明白，单位时间能解压缩更高的码率，获得更好的视频质量，反过来就是可以解更高的压缩比，基本是等价的。

ps mdec的码率是固定的，硬件决定

土星后期cienpak码率也能达到相同的
理论上如果土星软解码ps mdec的视频格式
速度可能更快点

但没有意义

ps某些游戏是在ps mdec压缩格式上再用Huffman算法压缩
然后再软解压Huffman算法把数据传到ps mdec

引用:

原帖由 SSforME 于 2024-4-2 13:30 发表

既然你自称写过jpeg解码器
那我可以告诉你ps mdec和JPEG区别
ps mdec宏块大小是16x16
jpeg是8x8
JPEG最终会用到Huffman压缩算法
ps mdec省略了这一步

ps mdec的视频源是yuv420

所以你该知道两者区别多大 ...

8x8和16x16DCT没啥大区别，16x16的计算会更复杂点，以当时的计算能力明显8x8更合适，所以92年的jpeg标准也是用的8x8，后来据说有的新编码标准有用16x16的，sony反而超前了？

不用Huffman算法怎么压缩，前面的DCT和量化都是为了压缩做准备啊，不压缩不是白忙乎？jpeg是先rle再哈夫曼，就算不用哈夫曼 sony肯定也有自己的压缩算法吧，而且前面步骤都通过dsp让硬件处理，这最后一步应该也容易集成进去，为什么不做？

还是你的意思是前面的DCT和量化是硬件dsp做的，最后一步哈夫曼是软件做的，当然游戏机是只用解码不用编码的，就是反过来解码的时候，经过哈夫曼编码的视频或者图像数据是软件解，然后的反向量化和IDCT是硬件dsp做的。

yuv420很正常吧，jpeg，mpeg都是要转换成yuv的，yuv420已经是最省的，以当时的显示设备清晰度分辨率这些，yuv420应该跟422，444这些没啥大区别吧。

你的说法我感觉许多都不符合逻辑，我没看过ps开发文档，你这个说法有没有依据我比较怀疑。

[ 本帖最后由 一直努力寻找 于 2024-4-2 15:30 编辑 ]

引用:

原帖由 SSforME 于 2024-4-2 13:34 发表

ps mdec的码率是固定的，硬件决定

土星后期cienpak码率也能达到相同的
理论上如果土星软解码ps mdec的视频格式
速度可能更快点

但没有意义

ps某些游戏是在ps mdec压缩格式上再用Huffman算法压缩
然后再 ...

mdec到底做的什么？ jpeg就是dct，量化，然后压缩（通过rle和哈夫曼），解码的时候反过来，要按你的说法mdec都已经压缩了，还要软件再哈夫曼一遍干啥，压缩两遍？

[ 本帖最后由 一直努力寻找 于 2024-4-2 15:38 编辑 ]

引用:

原帖由 一直努力寻找 于 2024-4-2 23:25 发表


8x8和16x16DCT没啥大区别，16x16的计算会更复杂点，以当时的计算能力明显8x8更合适，所以92年的jpeg标准也是用的8x8，后来据说有的新编码标准有用16x16的，sony反而超前了？

不用Huffman算法怎么压缩，前面的 ...

ps mdec是做完rle就打包了
Huffman算法被省略了

ps这样做是省算力吧

还有宏块大小还是有影响

mpeg2才支持8x8
所以宏块越小，算力要求越高
你说反了

我根据的是一份ps文档
以前狼组和施柯煜提供过

引用:

原帖由 SSforME 于 2024-4-2 15:45 发表

ps mdec是做完rle就打包了
Huffman算法被省略了

ps这样做是省算力吧

还有宏块大小还是有影响

mpeg2才支持8x8
所以宏块越小，算力要求越高
你说反了

我根据的是一份ps文档
以前狼组和施柯煜提供过

我查了一下，mpeg1标准也是按8x8来做DCT的，16x16也是被分成6个8x8，4个Y分量，2个是Cb和Cr分量，一般说的8x8，16x16都是指dct时候的大小，16x16的计算量更大。
而且mpeg1好像就只支持yuv420，422和444都是mpeg2才开始支持的，所以那年头只支持yuv420很正常。

ps的mdec都做rle了，为啥不做哈夫曼，这两步基本都是连在一起的。

引用:

原帖由 泡泡嘴 于 2024-4-2 15:14 发表

ss基本没有贴图或者贴图简陋的游戏不少，就没见过建模好一点点的游戏。
ss多边形可能也就ps的60%至80%。ps的实际多边形极限能力大概有13万每秒
，ss可能也就8万左右。
特效的话差距就更大了。
ps都不是简单的单 ...

多边形输出方面我同意你的说法，即便是Slave SH-2和SCU DSP能充分参与运算这种理想状态土星最多也就能达到PS的80%。
不过这只是土星VDP1对比PS的GTE，前面提过多次土星还有个VDP2能够用2D图层代替一部分工作，把多边形做到相近效果VDP1本就不需要与GTE打平。

半透明特效这个着实让人心累，土星VDP1提供的3D半透明唯一的问题是不能同时对VDP1图层和VDP2图层生效，技术层面上并没有跟PS差那么远。
但现实里大量低分辨率网格替代品造成在使用AV端子之上的高级视频输出方式时看起来真的比PS差半个世代LOL

至于FF7的战场帧数、你可以这么理解：把背景去掉只剩一堆多边形单位在黑色虚空里战斗，这就是个15FPS游戏；把多边形战斗单位去掉变成在空旷的场地上不停变换视角，那这是个30FPS游戏。
当年FF7发售PC版时SQUARE把战场镜头和UI的帧数都跟作战单位同步到15FPS、连后来的STEAM版都是如此，结果被人吐槽了二十多年。随便搜一下各种帧数MOD多的是，你感受一下区别就知道了。
其实这种前场活动单位跟背景帧数不同步的游戏并不罕见，因为FF7的30FPS镜头本身也不流畅且不稳定，多边形人物又不是玩家直接操控，再加上分辨率较低所以感觉不明显。

引用:

原帖由 泡泡嘴 于 2024-4-2 15:16 发表

ps有很多播片+即时演算游戏，是由于ps有专门的视频解码模块，不耗cpu和gpu资源。cpu和gpu就可以单独运算多边形，这是ps优势。

可事实上在PS那些背景全屏播片的游戏场景里、玩家控制的多边形人物帧数也会变得极低；
反观土星的骨头先生全屏播片时前面玩家控制的活动块也很流畅（对土星来说2D活动块和3D多边形是一回事）。

我猜可能是因为PS播片时把帧缓存都占了，调度空间给多边形比较困难；
而土星帧缓存本身就比PS大，软解码播片又比较灵活，能给VDP1预留足够的空间做活动块/多边形。

引用:

原帖由 SSforME 于 2024-4-2 19:51 发表

很遗憾的告诉你
ps格式的压缩率是最低的
比土星的cinepak还要低
坏处是视频文件容量大
所以ps多碟游戏多
好处是解压速度快
...

引用:

原帖由 SSforME 于 2024-4-2 21:34 发表

ps mdec的码率是固定的，硬件决定

土星后期cienpak码率也能达到相同的
理论上如果土星软解码ps mdec的视频格式
速度可能更快点

但没有意义

ps某些游戏是在ps mdec压缩格式上再用Huffman算法压缩
然后再 ...

当年卡婊开发土星版生化危机2时就有传言要用扩张内存卡，后来爱好者自制的版本也确实用了RAM卡加载背景图片。
哥们我强烈建议你跟Castorgroup（现土星生化2引擎开发者）联系一下，提醒他土星软解图片压缩率跟解压速度都不逊于PS、不需要RAM卡。
我是真心希望你能帮他解决当年卡婊解决不了的事！
Castorgroup油管频道链接：https://www.youtube.com/@castorgroup6080/videos

[ 本帖最后由 KainX 于 2024-4-3 02:49 编辑 ]

引用:

原帖由 KainX 于 2024-4-1 02:37 发表

……所以我说很多人对土星的播片能力有误会。
土星虽然没有硬件解码器但支持Cinepak、TrueMotion、Lucid Motion、MPEG Sofdec多种软件解码方式，影片效果会随开发者经验积累和对土星性能的挖掘而显著提升。

比 ...

这个diy演示上个月看过，作者还做了生化2开场cg的土星版视频，和ff8片头一样，实机录屏（美版土星和ps 9001），土星版只用了一个sh2+VDP2的一个图层（看翻译好像是让vdp2做颜色渐变处理），整体表现不亚于ps版，乍一看土星版的色调还比ps版好一些，色调很暖。
另外你关于土星做ff7战斗场景的说法，我在油管评论区也看到过类似假设，战斗场景的天空（天花板）、地板、周边背景可以全部用vdp2实现，让vdp1负责背景以为的可动图像元素，不过特效还是个大问题。
另外就是动画和多边形人物同屏显示，这种情况是在特定流程中出现的，没有太大的随机性，如果能够活用两个处理器，或许也可以实现，但战斗场景里也有部分“大招”用到了播片机能，不知道能否活用到两个处理器？？？

引用:

原帖由 majian1 于 2024-4-1 12:51 发表


光是这几张图片，明显能看得出来PS版本更亮，清晰度更高。

所以说视频就不能看截图，要看可动的视频才行，我看了这个，土星版分辨率不亚于ps版，而且土星版偏暖色调，非常耐看，ps是冷色调，不对比看不出什么，一对比就发现ps的观感不是太好。
另外土星版是在没有得到当年视频母带原片的情况下用PC版提取的视频制作的，细节上可能会存在差异。

[ 本帖最后由 werety 于 2024-4-3 15:23 编辑 ]

引用:

原帖由 SSforME 于 2024-4-1 20:52 发表

ps不能硬解mpeg
ps实际上出过一个亚洲版ps
好像是7501
里面加了mpeg1解码芯片
可以直接播放vcd
ps技术文档也表示ps是硬解专用视频格式

能看VCD的亚版PS是5903，纯白色外壳，主板上外挂了一块mpeg解码板，样子就像早期SFC的独立声卡版本一样。

引用:

原帖由 一直努力寻找 于 2024-4-3 00:07 发表


我查了一下，mpeg1标准也是按8x8来做DCT的，16x16也是被分成6个8x8，4个Y分量，2个是Cb和Cr分量，一般说的8x8，16x16都是指dct时候的大小，16x16的计算量更大。
而且mpeg1好像就只支持yuv420，422和444都是mpeg ...

不用Huffman很好理解
成本问题

sfc的街霸zero2就是用dsp实现类似Huffman的熵压缩算法
可见当时熵压缩算法成本比较高

mpeg1宏块是
一个宏块包含例一个16x16亮度块（4个亮度block）和两个8x8的色度块（2个色度block)
https://blog.csdn.net/qq_42139383/article/details/110920664

引用:

原帖由 SSforME 于 2024-4-3 07:23 发表

不用Huffman很好理解
成本问题

sfc的街霸zero2就是用dsp实现类似Huffman的熵压缩算法
可见当时熵压缩算法成本比较高

mpeg1宏块是
一个宏块包含例一个16x16亮度块（4个亮度block）和两个8x8的色度块（2个色 ...

4个Y分量就是8x8的，16x16就是4个8x8，这就是YUV420，4个Y分量对应2个uv分量，做DCT都是按8x8做的，别去瞎翻了，我看你也不太懂，就知道点名词，说些不着四六的东西，mpeg1和jpeg许多步骤都是一样的。

引用:

原帖由 一直努力寻找 于 2024-4-3 15:38 发表


4个Y分量就是8x8的，16x16就是4个8x8，这就是YUV420，4个Y分量对应2个uv分量，做DCT都是按8x8做的，别去瞎翻了，我看你也不太懂，就知道点名词，说些不着四六的东西，mpeg1和jpeg许多步骤都是一样的。

我也是服了你了
真是不懂
估计你也就是抄过jpeg压缩代码

没有深入理解
宏块分割是按图像分辨率做切割的
如果宏块是16x16
那么就是16x16像素

对于yuv420
对每个色度分量来说，水平方向和竖直方向的抽样率都是2:1

16x16像素对应于16x16 y分量
那么uv就是8x8的