TGFC俱乐部>>游戏业界综合讨论区>>
- 翻页: < ##1 ##2 ##3 > >> (3/4页)
- 刷新/显图/登录/注册/WEB
回复列表 (173)
原帖由 KainX 于 2024-4-1 02:37 发表
……所以我说很多人对土星的播片能力有误会。
土星虽然没有硬件解码器但支持Cinepak、TrueMotion、Lucid Motion、MPEG Sofdec多种软件解码方式，影片效果会随开发者经验积累和对土星性能的挖掘而显著提升。
比 ...
……所以我说很多人对土星的播片能力有误会。
土星虽然没有硬件解码器但支持Cinepak、TrueMotion、Lucid Motion、MPEG Sofdec多种软件解码方式，影片效果会随开发者经验积累和对土星性能的挖掘而显著提升。
比 ...
光是这几张图片，明显能看得出来PS版本更亮，清晰度更高。
===================
那个世代的主机性能都很孱弱，都更擅长小场景，但是ss小场景也和ps小场景有差距，
像ff7召唤兽已经用多边形表现手指和五官了，召唤兽是与场景和敌人同屏出现的，多边形真不是ss能比的。
https://s21.ax1x.com/2024/04/01/pF7B12R.jpg
https://s21.ax1x.com/2024/04/01/pF7B3x1.jpg
https://s21.ax1x.com/2024/04/01/pF7BQPJ.jpg
https://s21.ax1x.com/2024/04/01/pF7BlG9.jpg
https://s21.ax1x.com/2024/04/01/pF7BK54.jpg
https://s21.ax1x.com/2024/04/01/pF7BGKx.jpg
[ 本帖最后由 泡泡嘴 于 2024-4-1 16:00 编辑 ]
像ff7召唤兽已经用多边形表现手指和五官了，召唤兽是与场景和敌人同屏出现的，多边形真不是ss能比的。
https://s21.ax1x.com/2024/04/01/pF7B12R.jpg
https://s21.ax1x.com/2024/04/01/pF7B3x1.jpg
https://s21.ax1x.com/2024/04/01/pF7BQPJ.jpg
https://s21.ax1x.com/2024/04/01/pF7BlG9.jpg
https://s21.ax1x.com/2024/04/01/pF7BK54.jpg
https://s21.ax1x.com/2024/04/01/pF7BGKx.jpg
[ 本帖最后由 泡泡嘴 于 2024-4-1 16:00 编辑 ]
===================
SS游戏也许能勉强接近PS上的3D效果，但肯定要花费更多的资源和人力，属于吃力不讨好，世嘉本社3D作品都没几个能移植好的，梦美VR战士这些街机游戏确实名气很大，可惜移植效果非常一般
PS当年可是出了名的容易开发，软件商肯定也要考量的
PS当年可是出了名的容易开发，软件商肯定也要考量的
===================
原帖由 一直努力寻找 于 2024-4-1 00:53 发表
mpeg1最后也是哈夫曼编码啊，ps能硬解mpeg，应该jpeg也没问题吧
mpeg1最后也是哈夫曼编码啊，ps能硬解mpeg，应该jpeg也没问题吧
ps不能硬解mpeg
ps实际上出过一个亚洲版ps
好像是7501
里面加了mpeg1解码芯片
可以直接播放vcd
ps技术文档也表示ps是硬解专用视频格式
===================
原帖由 KainX 于 2024-4-1 01:45 发表
只要是专用硬件解码器就是硬件解码，跟Huffman coding没有关系。
只要是专用硬件解码器就是硬件解码，跟Huffman coding没有关系。
你对jpeg和ps mdec完全不了解
去查文档吧
ps的视频是专用格式
===================
原帖由 KainX 于 2024-4-1 09:28 发表
FF7大部分内容土星可以做出PS的八九成效果，但是战斗模式下的半透明特效要做妥协。
还有就是前面有人说过的即时游戏中整个背景是全屏播片这种情况，虽然PS在这种情况下游戏帧数也会变得很低，但目前还没有人将类 ...
FF7大部分内容土星可以做出PS的八九成效果，但是战斗模式下的半透明特效要做妥协。
还有就是前面有人说过的即时游戏中整个背景是全屏播片这种情况，虽然PS在这种情况下游戏帧数也会变得很低，但目前还没有人将类 ...
我记得以前电软分析过
土星《骨头先生》背景是播片
土星文档也表示背景可以播片
===================
原帖由 SSforME 于 2024-4-1 12:52 发表
ps不能硬解mpeg
ps实际上出过一个亚洲版ps
好像是7501
里面加了mpeg1解码芯片
可以直接播放vcd
ps技术文档也表示ps是硬解专用视频格式
ps不能硬解mpeg
ps实际上出过一个亚洲版ps
好像是7501
里面加了mpeg1解码芯片
可以直接播放vcd
ps技术文档也表示ps是硬解专用视频格式
这个无所谓的，当时图片和视频的压缩编解码方式其实是差不多的，其实视频就可以看成连续的一帧帧的图片流吗，就比如mpeg1解码和jpeg2000之前的jpeg解码，其实许多步骤都是相同的。
ps能硬解比土星码率更高质量更高的视频，同样的技术用在图片上，自然也就能支持更高压缩率的图片。哪怕这个格式是ps自己专用的，只要sony把相关api和规范告诉第三方，第三方能往自己的游戏里塞入大段可以按照ps硬解的标准压制的cg动画，自然也可以玩游戏里塞入可以让ps硬解的压缩比更高的图片素材。
===================
原帖由 泡泡嘴 于 2024-4-1 15:45 发表
那个世代的主机性能都很孱弱，都更擅长小场景，但是ss小场景也和ps小场景有差距，
像ff7召唤兽已经用多边形表现手指和五官了，召唤兽是与场景和敌人同屏出现的，多边形真不是ss能比的。
...
那个世代的主机性能都很孱弱，都更擅长小场景，但是ss小场景也和ps小场景有差距，
像ff7召唤兽已经用多边形表现手指和五官了，召唤兽是与场景和敌人同屏出现的，多边形真不是ss能比的。
...
FF7的多边形数量确实是不少，但有两个传奇级别的妥协。
第一个你自己也看出来了，就是这游戏基本没有贴图，无论PS还是土星能处理的无贴图多边形数量都比带纹理贴图多边形的高一倍。
我之所以确信土星做FF7能达到PS版的八九分效果一个重要原因也在于此，没有贴图就不会出现前面有人说的“全屏小格子”现象。
第二个是FF7战斗模式中的作战单位包括召唤兽和BOSS都只有15FPS。
这个我前面说过，该模式运镜是30PFS、菜单操作是60FPS，如此一来跟30FPS比多边形又增加一倍。
PS做FF7能使用一般游戏的四倍数量三角形就是拿这两个重大妥协换的，那么土星来做也一样。
而且没有人说土星能100%完美移植FF7，可以整体缩水10%多边形数量再结合四边形优势以这游戏的分辨率+CRT最后看不出明显差别就够了。
另外我说这种场合对土星有利是指这是VDP2参与画面绘制的理想环境。
FF7战斗模式不仅场地狭小，而且视角完全不受玩家控制，中间涉及的几何运算相对较少，对土星而言这比做格斗游戏还要理想。
土星来做的话VDP1可以把几乎全部多边形都用在作战单位上，背景处理则交由VDP2代劳。
而PS运行FF7战斗场景时GTE不单要处理15FPS的作战单位，还要处理30FPS的背景，多少会被分走一部分资源。
[ 本帖最后由 KainX 于 2024-4-2 14:30 编辑 ]
===================
posted by wap, platform: Samsung
是5903
原帖由 @SSforME 于 2024-4-1 20:52 发表
ps不能硬解mpeg
ps实际上出过一个亚洲版ps
好像是7501
里面加了mpeg1解码芯片
可以直接播放vcd
ps技术文档也表示ps是硬解专用视频格式
ps不能硬解mpeg
ps实际上出过一个亚洲版ps
好像是7501
里面加了mpeg1解码芯片
可以直接播放vcd
ps技术文档也表示ps是硬解专用视频格式
===================
原帖由 SSforME 于 2024-4-1 20:53 发表
你对jpeg和ps mdec完全不了解
去查文档吧
ps的视频是专用格式
你对jpeg和ps mdec完全不了解
去查文档吧
ps的视频是专用格式
MDEC确实是近似JPEG的专用格式解码器。我只需要了解它是硬件解码器、成像效果近似JPEG就够了LOL
===================
原帖由 SSforME 于 2024-4-1 20:56 发表
我记得以前电软分析过
土星《骨头先生》背景是播片
土星文档也表示背景可以播片
我记得以前电软分析过
土星《骨头先生》背景是播片
土星文档也表示背景可以播片
你别说骨头先生确实有不少场景的背景是全屏播片，看来是因为PS名作用得比较多给人一种这是其特殊机能的错觉。
这么说的话我记得SEGA CD上就有这种背景是全屏播片的射击游戏，那这根本就不是什么了不起的技术哦……
===================
原帖由 KainX 于 2024-4-2 13:39 发表
FF7的多边形数量确实是不少，但有两个传奇级别的妥协。
第一个你自己也看出来了，就是这游戏基本没有贴图，无论PS还是土星能处理的无贴图多边形数量都比带纹理贴图多边形的高一倍。
我之所以确信土星做FF7能达 ...
FF7的多边形数量确实是不少，但有两个传奇级别的妥协。
第一个你自己也看出来了，就是这游戏基本没有贴图，无论PS还是土星能处理的无贴图多边形数量都比带纹理贴图多边形的高一倍。
我之所以确信土星做FF7能达 ...
ss基本没有贴图或者贴图简陋的游戏不少，就没见过建模好一点点的游戏。
ss多边形可能也就ps的60%至80%。ps的实际多边形极限能力大概有13万每秒
，ss可能也就8万左右。
特效的话差距就更大了。
ps都不是简单的单层半透明，各种半透明物体混合，比ss华丽得多，说差半个世代都不为过。
另外，你对ff7的角色动作15帧是不是有什么误解？那只是动作15帧，并不是画面15帧，战斗画面还是30帧。
[ 本帖最后由 泡泡嘴 于 2024-4-2 16:11 编辑 ]
===================
原帖由 KainX 于 2024-4-2 14:18 发表
你别说骨头先生确实有不少场景的背景是全屏播片，看来是因为PS名作用得比较多给人一种这是其特殊机能的错觉。
这么说的话我记得SEGA CD上就有这种背景是全屏播片的射击游戏，那这根本就不是什么了不起的技术哦… ...
你别说骨头先生确实有不少场景的背景是全屏播片，看来是因为PS名作用得比较多给人一种这是其特殊机能的错觉。
这么说的话我记得SEGA CD上就有这种背景是全屏播片的射击游戏，那这根本就不是什么了不起的技术哦… ...
ps有很多播片+即时演算游戏，是由于ps有专门的视频解码模块，不耗cpu和gpu资源。cpu和gpu就可以单独运算多边形，这是ps优势。
===================
posted by wap, platform: Android
ss有创造球会2，比赛画面你可以看成是战斗画面，应该是活用了vdp2，效果不俗。还有飞龙2和飞龙rpg,都很强
原帖由 @泡泡嘴 于 2024-4-2 15:14 发表
ss基本没有贴图或者贴图简陋的游戏不少，就没见过建模好一点点的游戏。
ss多边形可能也就ps的60%至80%。ps的实际多边形极限能力大概有13万每秒
，ss可能也就8万左右。
特效的话差距就更大了。
ps都不是简单的单层半透明，各种半透明物体混合，比ss华丽得多，说差半个世代都不为过。
ss基本没有贴图或者贴图简陋的游戏不少，就没见过建模好一点点的游戏。
ss多边形可能也就ps的60%至80%。ps的实际多边形极限能力大概有13万每秒
，ss可能也就8万左右。
特效的话差距就更大了。
ps都不是简单的单层半透明，各种半透明物体混合，比ss华丽得多，说差半个世代都不为过。
===================
原帖由 得过且过 于 2024-4-2 15:34 发表
posted by wap, platform: Android
ss有创造球会2，比赛画面你可以看成是战斗画面，应该是活用了vdp2，效果不俗。还有飞龙2和飞龙rpg,都很强
posted by wap, platform: Android
ss有创造球会2，比赛画面你可以看成是战斗画面，应该是活用了vdp2，效果不俗。还有飞龙2和飞龙rpg,都很强
创造球会2看似同屏人数多，建模还行，实际上稍远一点就是低模了，再远一点直接变成贴图。ss的fifa98倒全是多边形的，还算不错，不过比ps版也有差距。
===================
原帖由 泡泡嘴 于 2024-4-2 07:16 发表
ps有很多播片+即时演算游戏，是由于ps有专门的视频解码模块，不耗cpu和gpu资源。cpu和gpu就可以单独运算多边形，这是ps优势。
ps有很多播片+即时演算游戏，是由于ps有专门的视频解码模块，不耗cpu和gpu资源。cpu和gpu就可以单独运算多边形，这是ps优势。
土星有2个cpu啊，可以专门分个单独cpu去干这事。当然那个年头，cpu干这事的效率一般都不如专用的dsp，记得超级解霸当年宣传之一，就是能活用cpu的mmx还是什么指令集，软解效率很高。
===================
原帖由 一直努力寻找 于 2024-4-2 10:21 发表
这个无所谓的，当时图片和视频的压缩编解码方式其实是差不多的，其实视频就可以看成连续的一帧帧的图片流吗，就比如mpeg1解码和jpeg2000之前的jpeg解码，其实许多步骤都是相同的。
ps能硬解比土星码率更高质量 ...
这个无所谓的，当时图片和视频的压缩编解码方式其实是差不多的，其实视频就可以看成连续的一帧帧的图片流吗，就比如mpeg1解码和jpeg2000之前的jpeg解码，其实许多步骤都是相同的。
ps能硬解比土星码率更高质量 ...
很遗憾的告诉你
ps格式的压缩率是最低的
比土星的cinepak还要低
坏处是视频文件容量大
所以ps多碟游戏多
好处是解压速度快
不懂技术不要胡乱联想
多找点文档看看
===================
原帖由 KainX 于 2024-4-2 14:09 发表
MDEC确实是近似JPEG的专用格式解码器。我只需要了解它是硬件解码器、成像效果近似JPEG就够了LOL
MDEC确实是近似JPEG的专用格式解码器。我只需要了解它是硬件解码器、成像效果近似JPEG就够了LOL
MDEC比JPEG差太多了
jpeg压缩率理想情况下可以是mdec的4倍
===================
原帖由 SSforME 于 2024-4-2 11:51 发表
很遗憾的告诉你
ps格式的压缩率是最低的
比土星的cinepak还要低
坏处是视频文件容量大
所以ps多碟游戏多
好处是解压速度快
不懂技术不要胡乱联想
多找点文档看看
很遗憾的告诉你
ps格式的压缩率是最低的
比土星的cinepak还要低
坏处是视频文件容量大
所以ps多碟游戏多
好处是解压速度快
不懂技术不要胡乱联想
多找点文档看看
喷了，不懂技术，我写过jpeg解码器的，不知道你有多懂，像你这种动不动说些不着四六大话的，反而基本都是半桶水都不满出来唬人的，看你以前的发言，基本就知道是个妄人了。
ps的视频解码能力强过土星基本也是公论，别人都没你懂。
===================
要真搞过这些东西就明白，单位时间能解压缩更高的码率，获得更好的视频质量，反过来就是可以解更高的压缩比，基本是等价的。
===================
原帖由 一直努力寻找 于 2024-4-2 19:57 发表
喷了，不懂技术，我写过jpeg解码器的，不知道你有多懂，像你这种动不动说些不着四六大话的，反而基本都是半桶水都不满出来唬人的，看你以前的发言，基本就知道是个妄人了。
ps的视频解码能力强过土星基本也是 ...
喷了，不懂技术，我写过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
所以你该知道两者区别多大 ...
既然你自称写过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算法压缩
然后再 ...
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算法怎么压缩，前面的 ...
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文档
以前狼组和施柯煜提供过
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都不是简单的单 ...
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有很多播片+即时演算游戏，是由于ps有专门的视频解码模块，不耗cpu和gpu资源。cpu和gpu就可以单独运算多边形，这是ps优势。
可事实上在PS那些背景全屏播片的游戏场景里、玩家控制的多边形人物帧数也会变得极低；
反观土星的骨头先生全屏播片时前面玩家控制的活动块也很流畅（对土星来说2D活动块和3D多边形是一回事）。
我猜可能是因为PS播片时把帧缓存都占了，调度空间给多边形比较困难；
而土星帧缓存本身就比PS大，软解码播片又比较灵活，能给VDP1预留足够的空间做活动块/多边形。
===================
原帖由 SSforME 于 2024-4-2 19:51 发表
很遗憾的告诉你
ps格式的压缩率是最低的
比土星的cinepak还要低
坏处是视频文件容量大
所以ps多碟游戏多
好处是解压速度快
...
很遗憾的告诉你
ps格式的压缩率是最低的
比土星的cinepak还要低
坏处是视频文件容量大
所以ps多碟游戏多
好处是解压速度快
...
原帖由 SSforME 于 2024-4-2 21:34 发表
ps mdec的码率是固定的，硬件决定
土星后期cienpak码率也能达到相同的
理论上如果土星软解码ps mdec的视频格式
速度可能更快点
但没有意义
ps某些游戏是在ps mdec压缩格式上再用Huffman算法压缩
然后再 ...
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多种软件解码方式，影片效果会随开发者经验积累和对土星性能的挖掘而显著提升。
比 ...
……所以我说很多人对土星的播片能力有误会。
土星虽然没有硬件解码器但支持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是冷色调，不对比看不出什么，一对比就发现ps的观感不是太好。
另外土星版是在没有得到当年视频母带原片的情况下用PC版提取的视频制作的，细节上可能会存在差异。
[ 本帖最后由 werety 于 2024-4-3 15:23 编辑 ]
===================
原帖由 SSforME 于 2024-4-1 20:52 发表
ps不能硬解mpeg
ps实际上出过一个亚洲版ps
好像是7501
里面加了mpeg1解码芯片
可以直接播放vcd
ps技术文档也表示ps是硬解专用视频格式
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 ...
我查了一下，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个色 ...
不用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许多步骤都是一样的。
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的
===================
原帖由 一直努力寻找 于 2024-4-3 15:38 发表
4个Y分量就是8x8的，16x16就是4个8x8，这就是YUV420，4个Y分量对应2个uv分量，做DCT都是按8x8做的，别去瞎翻了，我看你也不太懂，就知道点名词，说些不着四六的东西，mpeg1和jpeg许多步骤都是一样的。
4个Y分量就是8x8的，16x16就是4个8x8，这就是YUV420，4个Y分量对应2个uv分量，做DCT都是按8x8做的，别去瞎翻了，我看你也不太懂，就知道点名词，说些不着四六的东西，mpeg1和jpeg许多步骤都是一样的。
说实话
你一开始认为ps可以解码mpeg1和jpeg
我就知道你没看过ps文档
对技术也是一知半解
抄代码很容易的
===================
原帖由 werety 于 2024-4-3 15:07 发表
这个diy演示上个月看过，作者还做了生化2开场cg的土星版视频，和ff8片头一样，实机录屏（美版土星和ps 9001），土星版只用了一个sh2+VDP2的一个图层（看翻译好像是让vdp2做颜色渐变处理），整体表现不亚于ps版，乍 ...
这个diy演示上个月看过，作者还做了生化2开场cg的土星版视频，和ff8片头一样，实机录屏（美版土星和ps 9001），土星版只用了一个sh2+VDP2的一个图层（看翻译好像是让vdp2做颜色渐变处理），整体表现不亚于ps版，乍 ...
其实已经有人在做土星版FF7了：https://www.youtube.com/watch?v=OLr7qQqsjDE
我现在看到这种project有点心累……
https://club.tgfcer.com/attachment.php?aid=1214063&noupdate=yes¬humb=yes
https://club.tgfcer.com/attachment.php?aid=1214064&noupdate=yes¬humb=yes
https://club.tgfcer.com/attachment.php?aid=1214065&noupdate=yes¬humb=yes
https://club.tgfcer.com/attachment.php?aid=1214066&noupdate=yes¬humb=yes
[ 本帖最后由 KainX 于 2024-4-3 17:08 编辑 ]
附件：: [您所在的用户组无法下载或查看附件]
===================
我又仔细研究了一下
jpeg标准比较复杂
通常是yuv422
但也支持yuv444 yuv420
这样宏块划分也是多样的
jpeg格式支持格式，包括四种：yuv444采样(MCU大小为8x8，各一个Y/U/V分量block)、yuv420(MCU大小为16x16，包括4个Y分量和各一个U/V分量的block)、两种YUV矩形采样（MCU大小为16x8或8x16，两个Y分量和各一个U/V分量block）
jpeg标准比较复杂
通常是yuv422
但也支持yuv444 yuv420
这样宏块划分也是多样的
jpeg格式支持格式，包括四种：yuv444采样(MCU大小为8x8，各一个Y/U/V分量block)、yuv420(MCU大小为16x16，包括4个Y分量和各一个U/V分量的block)、两种YUV矩形采样（MCU大小为16x8或8x16，两个Y分量和各一个U/V分量block）
===================
原帖由 SSforME 于 2024-4-3 16:55 发表
说实话
你一开始认为ps可以解码mpeg1和jpeg
我就知道你没看过ps文档
对技术也是一知半解
抄代码很容易的
说实话
你一开始认为ps可以解码mpeg1和jpeg
我就知道你没看过ps文档
对技术也是一知半解
抄代码很容易的
我觉得你最懂了，你说PS的MDEC图片压缩率和解压速度都不如土星、我信了！
请你赶快去跟Castorgroup联系（联系方式在129楼）、跟他合作把不需要扩张RAM的土星版生化2做出来，一个简单的DMEO就行！
===================
原帖由 KainX 于 2024-4-3 17:37 发表
我觉得你最懂了，你说PS的MDEC图片压缩率和解压速度都不如土星、我信了！
请你赶快去跟Castorgroup联系（联系方式在129楼）、跟他合作把不需要扩张RAM的土星版生化2做出来，一个简单的DMEO就行！
我觉得你最懂了，你说PS的MDEC图片压缩率和解压速度都不如土星、我信了！
请你赶快去跟Castorgroup联系（联系方式在129楼）、跟他合作把不需要扩张RAM的土星版生化2做出来，一个简单的DMEO就行！
土星版生化2作者说了不会做完
作者只是想给自己的引擎打广告
其实土星的cinepak已经流出开发工具了
ps也有工具解码ps格式视频
只要解码出来用cinepak压缩然后在土星上解码播放就行
===================
原帖由 SSforME 于 2024-4-3 17:45 发表
土星版生化2作者说了不会做完
作者只是想给自己的引擎打广告
其实土星的cinepak已经流出开发工具了
ps也有工具解码ps格式视频
只要解码出来用cinepak压缩然后在土星上解码播放就行
土星版生化2作者说了不会做完
作者只是想给自己的引擎打广告
其实土星的cinepak已经流出开发工具了
ps也有工具解码ps格式视频
只要解码出来用cinepak压缩然后在土星上解码播放就行
不需要做完，现有DEMO的那几个场景足够。
你去教他如何让土星把相同背景图片压得比PS的MDEC还低，不，一样大小就行。
能让作者那个广告DEMO在不用扩张RAM的土星上运行、兄弟你的江湖地位大概就不逊于XL2了！
而且像你这种高人请不要说转PS视频在土星放这种外行话，用PS视频当片源土星怎么可能发挥它应有的播片效果。
[ 本帖最后由 KainX 于 2024-4-3 18:02 编辑 ]
===================
PS上使用的视频压缩格式是STR
声音部分采用和XA一样的压缩和储存技术
播放str文件的软件是Cube Media Player
对于ff7-9
cg视频是ps压缩的视频质量高还是pc版质量高，这是个问题
背景图片压得比PS的MDEC还低
这个用cinepak压一下
实在不行还可以再用Huffman压缩
扩张RAM主要是应付读盘
不一定是必须的
声音部分采用和XA一样的压缩和储存技术
播放str文件的软件是Cube Media Player
对于ff7-9
cg视频是ps压缩的视频质量高还是pc版质量高，这是个问题
背景图片压得比PS的MDEC还低
这个用cinepak压一下
实在不行还可以再用Huffman压缩
扩张RAM主要是应付读盘
不一定是必须的
===================
原帖由 SSforME 于 2024-4-3 08:55 发表
说实话
你一开始认为ps可以解码mpeg1和jpeg
我就知道你没看过ps文档
对技术也是一知半解
抄代码很容易的
说实话
你一开始认为ps可以解码mpeg1和jpeg
我就知道你没看过ps文档
对技术也是一知半解
抄代码很容易的
我是没看过ps开发文档，但我对解码肯定比你懂，你那套东西明显就看出你就是知道点名词就出来瞎喷了
===================
原帖由 SSforME 于 2024-4-3 08:49 发表
我也是服了你了
真是不懂
估计你也就是抄过jpeg压缩代码
没有深入理解
宏块分割是按图像分辨率做切割的
如果宏块是16x16
那么就是16x16像素
对于yuv420
对每个色度分量来说，水平方向和竖直方向的抽样 ...
我也是服了你了
真是不懂
估计你也就是抄过jpeg压缩代码
没有深入理解
宏块分割是按图像分辨率做切割的
如果宏块是16x16
那么就是16x16像素
对于yuv420
对每个色度分量来说，水平方向和竖直方向的抽样 ...
别瞎抄了，你已经闹笑话了，别装了，你就是知道点名词的半桶水，jpeg，mpeg的代码你肯定没写过。
===================
原帖由 一直努力寻找 于 2024-4-3 19:18 发表
别瞎抄了，你已经闹笑话了，别装了，你就是知道点名词的半桶水，jpeg，mpeg的代码你肯定没写过。
别瞎抄了，你已经闹笑话了，别装了，你就是知道点名词的半桶水，jpeg，mpeg的代码你肯定没写过。
你已经说不出编解码细节了
你写的代码也是抄的
每一个步骤原理你都说不清楚
竟然还认为rle和Huffman算法是串在一起的
看来你对常见的压缩算法都不太了解
抄代码又有何用:泥鹅满地打滚:
我以前都用过x264和ffmpeg代码移植和优化的
说实话，jm标准的所有细节我也不能说都懂
但明显的知道你不熟悉
===================
还有
自己瞎bb ps能解码jpeg mpeg
被我指出来了
开始无能狂怒了
不得已承认自己没看过ps文档
:泥鹅满地打滚:
自己瞎bb ps能解码jpeg mpeg
被我指出来了
开始无能狂怒了
不得已承认自己没看过ps文档
:泥鹅满地打滚:
===================
原帖由 SSforME 于 2024-4-3 12:05 发表
你已经说不出编解码细节了
你写的代码也是抄的
每一个步骤原理你都说不清楚
竟然还认为rle和Huffman算法是串在一起的
看来你对常见的压缩算法都不太了解
抄代码又有何用:泥鹅满地打滚:
我以前都用过x264和ffmpe ...
你已经说不出编解码细节了
你写的代码也是抄的
每一个步骤原理你都说不清楚
竟然还认为rle和Huffman算法是串在一起的
看来你对常见的压缩算法都不太了解
抄代码又有何用:泥鹅满地打滚:
我以前都用过x264和ffmpe ...
既然你自称写过jpeg解码器
那我可以告诉你ps mdec和JPEG区别
ps mdec宏块大小是16x16
jpeg是8x8
JPEG最终会用到Huffman压缩算法
ps mdec省略了这一步
ps mdec的视频源是yuv420
所以你该知道两者区别多大了
我又仔细研究了一下
jpeg标准比较复杂
通常是yuv422
但也支持yuv444 yuv420
这样宏块划分也是多样的
jpeg格式支持格式，包括四种：yuv444采样(MCU大小为8x8，各一个Y/U/V分量block)、yuv420(MCU大小为16x16，包括4个Y分量和各一个U/V分量的block)、两种YUV矩形采样（MCU大小为16x8或8x16，两个Y分量和各一个U/V分量block）
jpeg标准比较复杂
通常是yuv422
但也支持yuv444 yuv420
这样宏块划分也是多样的
jpeg格式支持格式，包括四种：yuv444采样(MCU大小为8x8，各一个Y/U/V分量block)、yuv420(MCU大小为16x16，包括4个Y分量和各一个U/V分量的block)、两种YUV矩形采样（MCU大小为16x8或8x16，两个Y分量和各一个U/V分量block）
别装了，你懂个JB，用过个p，还死鸭子嘴硬呢，不要脸像你这样也真是没谁了。
看看你抄来的这些东西和你开始喷的，打不打脸？本来那年代视频解码和图像解码就没啥区别，视频就是多了点运动补偿，能硬解类似mpeg的视频编码就能硬解类似jpeg的图像编码。
rle完了就是哈夫曼，先rle编码，在哈夫曼，这有啥问题？ 你要真写过jpeg解码器根本不会觉得这是个问题，觉得是个问题就更说明你根本不知道细节，就是从网上瞎抄了一些东西，然后出来瞎拽名词，
你就是被我揭穿屁都不懂就是拽名词的，开始无能狂怒了。
===================
原帖由 SSforME 于 2024-4-3 12:07 发表
还有
自己瞎bb ps能解码jpeg mpeg
被我指出来了
开始无能狂怒了
不得已承认自己没看过ps文档
:泥鹅满地打滚:
还有
自己瞎bb ps能解码jpeg mpeg
被我指出来了
开始无能狂怒了
不得已承认自己没看过ps文档
:泥鹅满地打滚:
我从来都承认自己没看过ps开发文档，倒是你，开始装的跟多懂图像解码是的，结果是不断打自己脸，后面抄来的打前面自己的脸，简直是个大笑话。
你看过ps开发文档有屁用啊，就你这样，肯定也没开发过ps的程序，而且你应该也没看过啥ps开发文档，其实你就是看了也看不懂啥，就是知道了点名词出来瞎拽点名词，装的跟懂点啥是的，其实半桶水都没有。
你接着自己去玩吧，被打脸以后恼羞成怒又要玩泥潭杠精争取最后一句发言权那套了，反正明白人都知道你对图像解码啥水了。
===================
原帖由 一直努力寻找 于 2024-4-3 20:30 发表
我从来都承认自己没看过ps开发文档，倒是你，开始装的跟多懂图像解码是的，结果是不断打自己脸，后面抄来的打前面自己的脸，简直是个大笑话。
你看过ps开发文档有屁用啊，就你这样，肯定也没开发过ps的程序， ...
我从来都承认自己没看过ps开发文档，倒是你，开始装的跟多懂图像解码是的，结果是不断打自己脸，后面抄来的打前面自己的脸，简直是个大笑话。
你看过ps开发文档有屁用啊，就你这样，肯定也没开发过ps的程序， ...
不断被打脸的是你
一直都对我人身攻击
了解编解码的都知道谁说的对
你这种人话术就没新意
就是那套我说错的我不知道的都不重要
你纠结细节就是杠精
然而技术就是纠结细节
一个句号就能让sql失效
最近暴露的黑客就是用句号来更改代码效果
最后被搞性能优化的杠精发现了
===================
顺便贴一下我看的ps文档来源
翻译 pinokio@163.com
附录
缩写
PSX Playstation
SCEI Sony Computer Entertainment Incorporated (Sony of Japan)
SCEA Sony Computer Entertainment America (Sony of America)
SCEE Sony Computer Entertainment Europe (Sony of Europe)
GTE Geometry Transformation Engine
GPU Graphics Processing Unit
CPU Central Processing Unit
MDEC Motion DEcoding Chip
PIO Parallel Input/Output port
SPU Sound Processing Unit
BIOS Basic Input/Output System
引用参考
History of the Sony PlayStation taken from http://www.psxpower.com
The IDTR3051 ™ , R3052 ™ RISController ™ Hardware User's Manual Revision 1.4 July 15, 1994
©1992, 1994 Integrated Device Technology, Inc.
System.txt, cdinfo.txt, gpu.txt, spu.txt, gte.txt
doomed@c64.org http://psx.rules.org
gte-lite.txt
http://www.in-brb.de/~creature/
MDEC data from
jlo@ludd.luth.se and various people at PSXDEV mailing list
http://www.geocities.co.jp/Playtown/2004/
bero@geocities.co.jp
Memcard/PAD Data
HFB03536@nifty-serve.or.jp
PIO
bitmaster@bigfoot.com
Syscall
sgf22@cam.ac.uk
Mem card format: E-nash
http://www.vbug.or.jp/users/e-nash/
e-nash@i.am
Plus the many more at PSXDEV mailing list that helped ^_^
Exitcode 84905
翻译 pinokio@163.com
附录
缩写
PSX Playstation
SCEI Sony Computer Entertainment Incorporated (Sony of Japan)
SCEA Sony Computer Entertainment America (Sony of America)
SCEE Sony Computer Entertainment Europe (Sony of Europe)
GTE Geometry Transformation Engine
GPU Graphics Processing Unit
CPU Central Processing Unit
MDEC Motion DEcoding Chip
PIO Parallel Input/Output port
SPU Sound Processing Unit
BIOS Basic Input/Output System
引用参考
History of the Sony PlayStation taken from http://www.psxpower.com
The IDTR3051 ™ , R3052 ™ RISController ™ Hardware User's Manual Revision 1.4 July 15, 1994
©1992, 1994 Integrated Device Technology, Inc.
System.txt, cdinfo.txt, gpu.txt, spu.txt, gte.txt
doomed@c64.org http://psx.rules.org
gte-lite.txt
http://www.in-brb.de/~creature/
MDEC data from
jlo@ludd.luth.se and various people at PSXDEV mailing list
http://www.geocities.co.jp/Playtown/2004/
bero@geocities.co.jp
Memcard/PAD Data
HFB03536@nifty-serve.or.jp
PIO
bitmaster@bigfoot.com
Syscall
sgf22@cam.ac.uk
Mem card format: E-nash
http://www.vbug.or.jp/users/e-nash/
e-nash@i.am
Plus the many more at PSXDEV mailing list that helped ^_^
Exitcode 84905
===================
3/4页 上页 ##1 ##2 ##3 下页 尾页
[登录后才可回复]