GMJ 发表于 2013-2-18 13:38

为什么游戏用的是索引色，存的图片又要割的这么碎？

刚才看了下ACG汉化的美工考题，修图里用的图是索引色，我就想了，为啥现在的游戏商还要用索引色？如果是出于缩小游戏体积考虑的话，那又为啥要最后压盘或者制卡的时候塞进大量的无用数据？

原来听说说加入无用数据是为了读盘流畅，那为啥不能让这些无用数据换成其他的？比如码率更大的音频，视频或者换大点的色彩空间什么的。。


http://zt.tgbus.com/acghh/Teaching/2008/09/17/1504312513.shtml
然后是图片这么碎片的保存方式。。。是为了更快的读取么？以现在的机能应该不需要这么整了吧？而且这么碎的读完还要再拼起来其实更浪费性能？

GMJ 发表于 2013-2-18 13:41

单独开一楼感谢汉化小组的付出。这一套流程下来修一张图的时间消耗太大了，想想他们为了汉化付出的闲暇时间真的是极大的牺牲。LZ我看到这个活要耗掉我多少撸管看片打游戏的时间果断缩了。。。

ymfss 发表于 2013-2-18 13:45

引用楼主GMJ于2013-02-18 13:38发表的 为什么游戏用的是索引色，存的图片又要割的这么碎？ :
刚才看了下ACG汉化的美工考题，修图里用的图是索引色，我就想了，为啥现在的游戏商还要用索引色？如果是出于缩小游戏体积考虑的话，那又为啥要最后压盘或者制卡的时候塞进大量的无用数据？
原来听说说加入无用数据是为了读盘流畅，那为啥不能让这些无用数据换成其他的？比如码率更大的音频，视频或者换大点的色彩空间什么的。。


....... images/back.gif

纯粹是日本厂商的游戏封装技术落后时代而已，而封装技术取决于主机开发厂商的开发套件有多先进，具体来说X BOX的开发套件就是天生比日系的好用，也更容易向PC平台移植。
至于无用数据换其他的，你没考虑过成本限制么？

GMJ 发表于 2013-2-18 13:46

引用第2楼ymfss于2013-02-18 13:45发表的  :

纯粹是日本厂商的游戏封装技术落后时代而已，而封装技术取决于主机开发厂商的开发套件有多先进，具体来说X BOX的开发套件就是天生比日系的好用，也更容易向PC平台移植。
至于无用数据换其他的，你没考虑过成本限制么？ images/back.gif

至于无用数据换其他的，你没考虑过成本限制么？

不不不，我不是说新加音频视频的意思，只是说把他原来要压缩的东西不压缩直接存。比如音乐制作的时候肯定不是MP3或者ogg吧，既然空间有多可以试试存WAV，ape这种无损的。如果原来是存128mp3的可以改存320mp3这样。。24FPS的3DCG视频可以做成导出成30FPS嘛，这种在存储的时候可以选质量好点的方式，比起单纯填充无用数据不是更有意义么，或者干脆把游戏中未采用的曲子插图剧本收集下做个收集要素塞也是嘛，毕竟都做出来了不用都是浪费。做游戏里单独做收集系统麻烦的可以直接简单粗暴的用游戏币购买解锁。

forgetman 发表于 2013-2-18 13:56

这个和破解出来的东西有关
实际上制作的时候，制作人员使用的工具和平台，看到的是一张很正常的图片
打包加密后就变成破解者破解后所看到的那样

索引色是为了容量，也是老技术的关系了

这样说，开发一套游戏开发用的平台和工具，投入成本是非常大的
所以在有新的工具之前，就还是用原来的索引色打包模式啊等等这样的技术和手段来制作
结果一用就用了十几年

后来载体容量很大了，大家还是在用老工具，怎么办？
那就填充一些没用的废数据进去，比如同样的资源文件复制个好几遍……
用高清的贴图多好啊？但美工不肯画啊，你原来的低清的画成高清的要多给钱啊，一谈给钱投资方不干了啊
音乐同理啊
所以就成了楼主你看到的情况了

oz01 发表于 2013-2-18 14:03

虽然我知道这么说很不好听，不过不懂技术的话最好不要猜
索引色是PS2时代以及在这之前比较常用，因为那时候主机的内存显存都非常有限
现代到了ps3时代，我是没看到还有用索引色的，都用dds了
加入无用数据是为了把数据往光盘外圈推，外圈数据读取速度比内圈高一些

forgetman 发表于 2013-2-18 14:03

引用第3楼GMJ于2013-02-18 13:46发表的:

至于无用数据换其他的，你没考虑过成本限制么？

不不不，我不是说新加音频视频的意思，只是说把他原来要压缩的东西不压缩直接存。比如音乐制作的时候肯定不是MP3或者ogg吧，既然空间有多可以试试存WAV，ape这种无损的。如果原来是存128mp3的可以改存320mp3这样。。24FPS的3DCG视频可以做成导出成30FPS嘛，这种在存储的时候可以选质量好点的方式，比起单纯填充无用数据不是更有意义么，或者干脆把游戏中未采用的曲子插图剧本收集下做个收集要素塞也是嘛，毕竟都做出来了不用都是浪费。做游戏里单独做收集系统麻烦的可以直接简单粗暴的用游戏币购买解锁。 images/back.gif

还是那句话
视开发环境而定

我就有遇到过，引擎支持的最大帧数就是那么多，你要再加点 他就读错了
声音也有，只支持mp3，码率高了它也不给响 ogg就更别想了

forgetman 发表于 2013-2-18 14:06

索引色确实是因为内存的关系用的方法

但开发工具开发环境不更新 他还是就这么读

反正都做2d卡通人物 你256色完全够用了

GMJ 发表于 2013-2-18 14:27

又学到新知识了。

姐控123 发表于 2013-2-18 14:36

有时一些怪的亚种，用的精灵图都是一样，这时只需要换下调色板就成，像素数据不用多放一份。所以会有调色板数据跟像素数据分离开的情况。
另外有些是因为硬件的限制，像GBA和DS，活动的精灵只能是16色。

再有LZ给的链接图，不零碎，是连续的。只是一张图切开成多个8x8的tile，再连续存放在一起。为什么要这样分割，简单来说，是因为分割的话，每小块里重复的数据就可以比一行一行连续存放的多，从而提高压缩比。另一个原因就是可以把用少量重复的tile来拼成一张大地图。

oz01 发表于 2013-2-18 14:42

引用第6楼forgetman于2013-02-18 14:03发表的:

还是那句话
视开发环境而定

我就有遇到过，引擎支持的最大帧数就是那么多，你要再加点 他就读错了
....... images/back.gif

果然我认真了就输了

forgetman 发表于 2013-2-18 14:51

引用第10楼oz01于2013-02-18 14:42发表的:

果然我认真了就输了 images/back.gif

早期的引擎 总有些奇怪的问题
比如你模型转完 还需要专门的插件导入成他专属格式
所谓专属格式，在开发工具内解开来，就是一张一张连续的静态图片
然后它个sb 250只能显示24张
你弄个30帧的动作，最后6帧他就选择性的无视掉了……
然后连续播放这个动作时，最后那6帧，它就是不给显示啊 不给显示……

oz01 发表于 2013-2-18 15:15

引用第11楼forgetman于2013-02-18 14:51发表的:

早期的引擎 总有些奇怪的问题
比如你模型转完 还需要专门的插件导入成他专属格式
所谓专属格式，在开发工具内解开来，就是一张一张连续的静态图片
然后它个sb 250只能显示24张
....... images/back.gif

GMJ 发表于 2013-2-18 16:04

引用第9楼姐控123于2013-02-18 14:36发表的:
有时一些怪的亚种，用的精灵图都是一样，这时只需要换下调色板就成，像素数据不用多放一份。所以会有调色板数据跟像素数据分离开的情况。
另外有些是因为硬件的限制，像GBA和DS，活动的精灵只能是16色。

再有LZ给的链接图，不零碎，是连续的。只是一张图切开成多个8x8的tile，再连续存放在一起。为什么要这样分割，简单来说，是因为分割的话，每小块里重复的数据就可以比一行一行连续存放的多，从而提高压缩比。另一个原因就是可以把用少量重复的tile来拼成一张大地图。 images/back.gif

亚种精灵这个办法处理起来看起来确实能省下不少存储空间，但在现在存储介质大到空虚的时候这个方法本身意义其实很小了已经。
PS里色相拉一下另存为也可以。

那个8X8分割存储压缩率比较高现在保存的压缩算法也没有这种优化么？比如一张颜色差不多的图8*128的保存和分割成8*8的16份保存，种体积应该8*128的小吧？除非他分割成8*8的16分除了在这张地图A里用了下，地图B的时候又能掉出来用下，等下建筑C里还能用下。不过这样岂不是要把所有分割后的素材拼在一起，文件那么大读取来得及么？

GMJ 发表于 2013-2-18 16:08

引用第13楼GMJ于2013-02-18 16:04发表的:

亚种精灵这个办法处理起来看起来确实能省下不少存储空间，但在现在存储介质大到空虚的时候这个方法本身意义其实很小了已经。
PS里色相拉一下另存为也可以。

那个8X8分割存储压缩率比较高现在保存的压缩算法也没有这种优化么？比如一张颜色差不多的图8*128的保存和分割成8*8的16份保存，种体积应该8*128的小吧？除非他分割成8*8的16分除了在这张地图A里用了下，地图B的时候又能掉出来用下，等下建筑C里还能用下。不过这样岂不是要把所有分割后的素材拼在一起，文件那么大读取来得及么？ images/back.gif

我以前读的起点文里有个YY就是所有电脑显示的图像都是由16777216种颜色存储的，主角每个颜色存一个像素大小，然后就就用这些最基本单位拼所有图像资源从技能图标到大地图到模型贴图打造客户端超小但内容丰富的游戏。。。

切成1个像素这么夸张的先不谈，原理是这个原理么？

forgetman 发表于 2013-2-18 16:18

引用第12楼oz01于2013-02-18 15:15发表的:

images/back.gif

汉化大大是没接触过那些人物是3d渲染，背景是2d的游戏吧

neunundneunzig 发表于 2013-2-18 16:35

姐控123 发表于 2013-2-18 17:13

引用第13楼GMJ于2013-02-18 16:04发表的 :
那个8X8分割存储压缩率比较高现在保存的压缩算法也没有这种优化么？比如一张颜色差不多的图8*128的保存和分割成8*8的16份保存，种体积应该8*128的小吧？除非他分割成8*8的16分除了在这张地图A里用了下，地图B的时候又能掉出来用下，等下建筑C里还能用下。不过这样岂不是要把所有分割后的素材拼在一起，文件那么大读取来得及么？ http://bbs.saraba1st.com/2b/images/back.gif

“那个8X8分割存储压缩率比较高现在保存的压缩算法也没有这种优化么？”
大部分情况下，一行行像素的数据改压缩算法都没有8*8分割后压缩比好。再加上还要考虑解压的效率，所以都尽量采用硬件自身就支持硬解压的压缩算法。在不压缩时，保存成16个8*8跟保存成8*128的数据量是一样大的，没区别。保存成16个8*8，不代表就要有16个文件头。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
而且确实这些地图tiles是可以重复利用的。举个最经典的例子：机器人大战系列。确实不少游戏的地图素材是放一起的。不过读取时按MAP数据求出偏移，读取时是可以直接访问那一小块像素数据，不需要整个素材库调入内存。　

其实就算现在游戏软件的载体是比以前限制小了，也不代表就能挥霍啊，连家用机的那些3D纹理贴图还是使用的有损压缩呢。

trentswd 发表于 2013-2-18 19:06

索引也就是为了节省每个像素存图片的大小，所以索引位数多了的情况索引和直接rgb有什么本质区别吗……
16777215就是rgb的ffffff的十进制。说穿了就是普通的24位bmp啊……

----发送自 Samsung Galaxy Nexus,Android 4.2.1

GMJ 发表于 2013-2-18 19:59

引用第18楼trentswd于2013-02-18 19:06发表的  :
索引也就是为了节省每个像素存图片的大小，所以索引位数多了的情况索引和直接rgb有什么本质区别吗……
16777215就是rgb的ffffff的十进制。说穿了就是普通的24位bmp啊……

----发送自 Samsung Galaxy Nexus,Android 4.2.1 images/back.gif

对，哪个YY小说就是想说他的图像数据库就一张1600W像素点的BMP图，重复使用率MAX。所以体积小到爆。用PS建立了一下文档，不压缩的话才47M

GMJ 发表于 2013-2-18 20:01

引用第17楼姐控123于2013-02-18 17:13发表的:

“那个8X8分割存储压缩率比较高现在保存的压缩算法也没有这种优化么？”
大部分情况下，一行行像素的数据改压缩算法都没有8*8分割后压缩比好。再加上还要考虑解压的效率，所以都尽量采用硬件自身就支持硬解压的压缩算法。在不压缩时，保存成16个8*8跟保存成8*128的数据量是一样大的，没区别。保存成16个8*8，不代表就要有16个文件头。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
而且确实这些地图tiles是可以重复利用的。举个最经典的例子：机器人大战系列。确实不少游戏的地图素材是放一起的。不过读取时按MAP数据求出偏移，读取时是可以直接访问那一小块像素数据，不需要整个素材库调入内存。　
....... images/back.gif

哪个什么80G客户端的网游炙热帝国2不会就是因为没这样处理所以这么大的吧。。

姐控123 发表于 2013-2-18 20:23

回 20楼(GMJ) 的帖子

先确认这80G里是不是有很多播片用的CG。
另外你说的起点那个真是让人喷饭，16777216色的调色板，那一个像素点颜色的索引号数据，本身就要24位也就是3个字节，那不如直接用24位高彩图好了，还不需要那个1600W色的庞大调色盘。

点男 发表于 2013-2-18 20:32

虽然对游戏引擎没研究, 但我现在是学做CG的, 学校要求最后作品的每帧渲染速度不能长于一小时, 这还是学生作品在专业的工作站渲染的速度, 就算游戏引擎支持, 每秒多6帧你算算一段两分钟的CG要多渲染多长时间, 成本啊成本, 而且就算能弄到30F/S看起来也没什么不一样

oz01 发表于 2013-2-18 21:03

256索引色，32位色板部分1kB
每个象素1字节
1024*1024就是1MB+1kB
RGBA每个象素4字节
1024*1024就是4MB
差距一目了然

GMJ 发表于 2013-2-18 21:06

Re:回 20楼(GMJ) 的帖子

引用第21楼姐控123于2013-02-18 20:23发表的 回 20楼(GMJ) 的帖子 :
先确认这80G里是不是有很多播片用的CG。
另外你说的起点那个真是让人喷饭，16777216色的调色板，那一个像素点颜色的索引号数据，本身就要24位也就是3个字节，那不如直接用24位高彩图好了，还不需要那个1600W色的庞大调色盘。 images/back.gif

都说了是起点YY小说你认真就输了

GMJ 发表于 2013-2-19 08:42

引用第23楼oz01于2013-02-18 21:03发表的:
256索引色，32位色板部分1kB
每个象素1字节
1024*1024就是1MB+1kB
RGBA每个象素4字节
1024*1024就是4MB
....... images/back.gif

索引色对压缩体积帮助这么大，为啥不能用在印刷上？反正只要色盘是CMYK的色就好了嘛

胡说 发表于 2013-2-19 09:31

胡说 发表于 2013-2-19 09:35

w酱 发表于 2013-2-19 11:08

次世代谁用索引色，PS3之前主机的性能都很可怜，迫不得已的做法
单就PSP的GIM图也可以支持多于256色，官方工具应该是支持直接颜色模式的，但是实机效率就是，而且容易爆内存

yyahtt 发表于 2013-2-19 11:31

涨知识了。。

姐控123 发表于 2013-2-19 12:17

引用第28楼w酱于2013-02-19 11:08发表的:
次世代谁用索引色 ，PS3之前主机的性能都很可怜，迫不得已的做法
单就PSP的GIM图也可以支持多于256色，官方工具应该是支持直接颜色模式的，但是实机效率就是 ，而且容易爆内存images/back.gif

不清楚这位朋友知不知道DDS里的几种DXTC压缩就是一种单元内索引色图，不过在计算每个像素颜色时有插值运算，而并不是简单的索引。现在次世代游戏的纹理图不少用的就是加密过的DDS文件。

hourousha 发表于 2013-2-19 13:12

oz01 发表于 2013-2-19 13:32

现在滥用DXT的问题也挺严重的
DXT那效果
ps3版星海4可以作为典型参照

姐控123 发表于 2013-2-19 13:44

引用第31楼hourousha于2013-02-19 13:12发表的:

DDS的本质是按tile（8x8 or 4x4）设定只有两色的色盘，而tile中每个texel的最终颜色只由这两个颜色插值，所以dds的颜色准确性很差，在一些情况（比如本身texture颜色就不多）下效果还不如8bit索引色。
现在游戏中不使用索引色的主因是从DX9硬件开始索引色纹理就不被硬件支持了，虽然可以用shader模拟，但要模拟texture filter比较麻烦消耗也大，划不来。 images/back.gif

我前面引用的那位朋友他说次世代不用索引色图，我是针对那位朋友说的。DDS的DXTC其实可以说就是种广义的tile内索引色图(忽略那个具体的插值运算)，而不是每个像素都是RGB颜色值。就是为了说明现在本世代游戏仍然有在用索引色图技术而已 。DDS跟传统的图内XX色调色板索引图敦优敦劣不是重点。

hourousha 发表于 2013-2-19 14:17

姐控123 发表于 2013-2-19 14:33

回 34楼(hourousha) 的帖子

我前面也说了广义上啦 ，你严格意义上来看那当然不算了。不过下面这点是可以肯定的：目前仍然还不是所有游戏在纹理贴图上都在采用了每个像素都是具体RGB颜色值的图。
页: [1]
查看完整版本: 为什么游戏用的是索引色，存的图片又要割的这么碎？