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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

又学到新知识了。

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

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

果然我认真了就输了

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

涨知识了。。

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

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

从严格意义我倒不觉得S3TC算得上索引色，因为每个tile的色盘实际上是定义了一个颜色区间的两端值而已，实际颜色取得需要代入该区间的线性插值。 而索引色本质是一个look-up table。和前者从根本上有着不同。前者是一条线段的两个端点，而后者是一群无关联的点。

我前面也说了广义上啦 ，你严格意义上来看那当然不算了。不过下面这点是可以肯定的：目前仍然还不是所有游戏在纹理贴图上都在采用了每个像素都是具体RGB颜色值的图。