KeyFansClub
Prz - 2005/2/9 14:52:00
寒...花了一个下午，总算写出了AVG系列的脚本压缩引擎，经过测试发现.....好像比原脚本压缩率高....)#(*$^)@#(%^
200K的文件压缩以后，比原有的压缩后的脚本还小400字节左右...不过解压后文件和原来的倒是完全一样... 不知道是我的引擎放宽了一些限制还是原引擎没有发挥足够的效果... ?_?
日文初回版 （带语音）
[注: 这个明显被插入语音的程序"偷懒了" -_-]
解压后脚本 SEEN180.TXT 298,971字节
解压前原脚本 SEEN180.PAK 336,348字节
重新打包后脚本 Text.PAK 109,666字节 (-226,682字节)
中文版 （使用 日文初回版 带语音）
解压后脚本 SEEN180.TXT 290,977字节
解压前原脚本 SEEN180.PAK 108,641字节
重新打包后脚本 Text.PAK 108,227字节 (-414字节)
日文初回版 （原版）
解压后脚本 SEEN180.TXT 286,251字节
解压前原脚本 SEEN180.PAK 105,251字节
重新打包后脚本 Text.PAK 105,238字节 (-13字节)
日文全年龄版 （原版）
[注: 这个版本大小最接近]
解压后脚本 SEEN180.TXT 286,251字节
解压前原脚本 SEEN180.PAK 105,256字节
重新打包后脚本 Text.PAK 105,244字节 (-12字节)
稍后再写一个整合打包程序，把所有的脚本解出来后重新打包，扔进AVG引擎，看看是否还能正常工作...
白井功名 - 2005/2/9 15:15:00
虽然没看懂是干么的……
不过还是拜一个orz
kfc真的是各类人才都有……orz
nitekid - 2005/2/9 20:58:00
Misha姐强人哦
从她的“末知物理地址”就可稍稍了解哦（迷之天才程序员……暴汗）
真琴护卫队 - 2005/2/9 21:06:00
恩 完全看不懂
不过帮忙顶一的说
生蛋猪 - 2005/2/9 21:45:00
因为我完全看不懂，所以……
请求支援……Over..
nomomo - 2005/2/9 21:53:00
看不懂@_@
卫江 - 2005/2/9 21:58:00
长久以来，佩服3种帖子：
1、有打量数据的帖子
2、有研究性质的帖子
3、我看不明白的帖子
Misha姊的帖子具备了全部的三条，所以....
ameboshi - 2005/2/9 22:02:00
恩……我是看不大懂……不知道可不可以实现让kanonse用原来kanon的语音？
kuangallan - 2005/2/9 22:44:00
我知道是什么~~~~想问一下，是为AVG32/16系统还是AVG2000（RealLive）用的.还有，脚本这么小，用得着压缩吗？
nitekid - 2005/2/9 22:52:00
打包是好习惯，不单单是为了压缩。
可以使文件管理有序，还可以从一定程度上防止未授权的二次开发
kuangallan - 2005/2/9 23:05:00
-_-b 你还是没有回答我什么系统用的。而且你说：“对文件的打包是好习惯，不单单是为了压缩。
可以使文件管理有序，还可以从一定程度上防止未授权的二次开发”现在能把脚本和其他文件一起打包吗？
nitekid - 2005/2/9 23:18:00
我本来也没有想回答你什么系统的事情-_-
按Misha姐的意思说，是全系列的吧，呵呵……要仔细看帖哦
这里说的打包是指“把所有的脚本解出来后重新打包”
一个文字类游戏包含很多的脚本，如果它们都作为单独的文件躺在你的游戏目录下，不是很凌乱吗（同时也是会浪费硬盘空间的）
Prz - 2005/2/9 23:37:00
Visual Arts的AVG系统目前只有AVG32和AVG2K两类系统:
当然每个系统都有一些小的分支，比如AVG3216和AVG3217，(M)CI和(D)irectSound版本，都是属于AVG32类;
AVG2000、Reallive是属于AVG2K类;
有的游戏也有稍作改动，比如Planetaraian用的Kinetic，就是Reallive+加/解密引擎。
两种系统的脚本包格式稍有不同，AVG2K系统的包多了两层加密功能，不过是静态加密，已经被破解。
(据说....Kinetic好像转成了动态加密了... >_<)
但是两个系统的底层压缩解压都是同一个算法(是LZ算法的一个分支)。此算法采用活动整合字典，理论最大压缩比为8:1，最小压缩比为8:9。
对于文本和EXE文件有良好的压缩率(一般在2:1 - 4:1之间)；
不过对于Entropy较高的文件则明显力不从心，生成的压缩文件会比原文件大... >_<
因此此算法不适合用来打包所有文件，目前确定使用范围为: 脚本文件/PDT文件/G00文件
nitekid - 2005/2/9 23:41:00
插个问题：ONE的脚本存取系统是怎样的呢，听说还没有被破解？
Prz - 2005/2/9 23:45:00
One用的是什么引擎? AVG32么，如果是的话，应该用我的AVG32脚本阅读器可以读出(尚未确认...)
http://www.keyfc.net/bbs/disp.asp?titleid=5978
最后两份，不是奶油蛋糕，也没有漂亮的图片，不要都去抢，确定自己有确确实实需要的人去买... >_<
这年头这里的人都有盲目抢购的倾向...难道是KP太便宜了?
nitekid - 2005/2/9 23:51:00
第15/16份……好悬……按某人的说法，是我把之前的人品暴掉的结果？？
YWT - 2005/2/10 0:47:00
楼主想没想过自己写一个引擎？虽然有点难度，不过我觉得应该还是会有些用的吧。-v-
就叫做KFCEngine算了-v-
脚本引擎以前我做安装程序开发环境的时候写过一个。但是Visual Effects这些特效自己从没做过。Sound和Music倒是自己写过。(主要是用IDirectSound接口)
不知楼主有没有兴趣:)
亡灵之猫 - 2005/2/10 2:38:00
以下引用YWT在2005-2-10 0:47:55的发言：
楼主想没想过自己写一个引擎？虽然有点难度，不过我觉得应该还是会有些用的吧。-v-
就叫做KFCEngine算了-v-
脚本引擎以前我做安装程序开发环境的时候写过一个。但是Visual Effects这些特效自己从没做过。Sound和Music倒是自己写过。(主要是用IDirectSound接口)
不知楼主有没有兴趣:) |
这个东西，我和朋友已经做出了一个实物，图形基于OpenGL,声音基于DSound和MCI，脚本使用二进制代码或者.ini文件，可惜压缩技术不过关，只能支持BMP图形，3DS模型和WAV音频。要是能在深层一点就好了！
YWT - 2005/2/10 4:00:00
AVG游戏的系统并不复杂，只是脚本的易用性上会有些难办......
就如同FPS游戏会用Console系统进行脚本和动作的解释与实现一样。
如果能作出一个完全使用脚本系统来驱动的引擎的话，支持的格式的问题只是小事。
脚本的函数库，变量系统和runtime compilation才是最难写的。因为脚本并非是一般的编程语言，而是赋予了程序在runtime可以进行编程并直接执行的能力。不同于一般的编译器，但有在某些方面是一样的（例如instuction table, Register Table）。脚本系统的执行机制建立在Virtual Machine之上。
Prz - 2005/2/10 7:58:00
赫赫，要做其实不难，主要是耗时间
曾经用脚本语言做了一个执行脚本的虚拟机，用脚本执行脚本...(在用我的mIRC音乐FTP自助界面的人就知道我说的是什么)
高级脚本写起来很爽，非常接近自然语言...
顺便回楼上几位: 我有计划做AVG脚本编辑器，可以修改脚本的任何细节(文字显示，声音播放，图片特效)，而且为了能够达到所见即所得，也准备内建一个模拟引擎，这样就可以即时看到所做的一切修改的效果了。
也就是说，可以自编自导一个新的AVG，也可以修改原游戏以达到KUSO的目的。（本人不为任何人使用该软件产生的一切后果负责...-_-|||）
Prz - 2005/2/10 8:09:00
顺便说一句....其实AVG32(准)全兼容的引擎已经有人写出来了
vAVG32 是基础引擎，在其上发展出了Carbon版Mac OS X引擎和各种PDA,Palm引擎；
xKanon 是另一个独立的引擎，与vAVG32的关系未知。这个是运行于Unix/Linux系统上的AVG32引擎。
AVG2K的引擎目前正在开发中，目标系统Linux，好像Clannad已经可以运行了 (至少看到了游戏开始画面的截屏)
生蛋猪 - 2005/2/10 8:26:00
这样的技术谈论贴竟然可以盖到20层，第三页…………@_@
Prz - 2005/2/10 8:40:00
证明热爱编程的Fan正在增多，不是好事么... 还有，楼上是在灌水？
漆羽静云 - 2005/2/10 18:25:00
支持MISHA 姐姐~~~~ 偶知道王二也在弄吧…………
王二 - 2005/2/10 23:14:00
以下引用漆羽静云在2005-2-10 18:25:05的发言：
支持MISHA 姐姐~~~~ 偶知道王二也在弄吧………… |
>_<汗，我的水平可没有那么高……
现在只是在慢慢学而已，研究AVG引擎当然想，只是貌似现在还不到火候……
Fantastical - 2005/2/11 19:28:00
以下引用Misha在2005-2-9 14:52:30的发言：
寒...花了一个下午，总算写出了AVG系列的脚本压缩引擎，经过测试发现.....好像比原脚本压缩率高....)#(*$^)@#(%^
200K的文件压缩以后，比原有的压缩后的脚本还小400字节左右...不过解压后文件和原来的倒是完全一样... 不知道是我的引擎放宽了一些限制还是原引擎没有发挥足够的效果... ?_?
日文初回版 （带语音）
[注: 这个明显被插入语音的程序"偷懒了" -_-]
解压后脚本 SEEN180.TXT 298,971字节
解压前原脚本 SEEN180.PAK 336,348字节
重新打包后脚本 Text.PAK 109,666字节 (-226,682字节)
中文版 （使用 日文初回版 带语音）
解压后脚本 SEEN180.TXT 290,977字节
解压前原脚本 SEEN180.PAK 108,641字节
重新打包后脚本 Text.PAK 108,227字节 (-414字节)
日文初回版 （原版）
解压后脚本 SEEN180.TXT 286,251字节
解压前原脚本 SEEN180.PAK 105,251字节
重新打包后脚本 Text.PAK 105,238字节 (-13字节)
日文全年龄版 （原版）
[注: 这个版本大小最接近]
解压后脚本 SEEN180.TXT 286,251字节
解压前原脚本 SEEN180.PAK 105,256字节
重新打包后脚本 Text.PAK 105,244字节 (-12字节)
稍后再写一个整合打包程序，把所有的脚本解出来后重新打包，扔进AVG引擎，看看是否还能正常工作... |
…………咔咔，终于回来鸟……没网的日子素很难过啊……
Mishaさん啊~~
这就素你告诉我的反写算法很easy的结果啊？~~ ^3^
Prz - 2005/2/12 6:27:00
算法明显简单，写出来就是半个小时的事
但是要将其实用化就必须要对其进行OOP封装
比如我现在的这个压缩引擎对象，可以使用两种方式压缩: 块式和流式, 分别适用于文件压缩和网络传输
而且算法的效率也是一个问题，这就涉及到循环和变量的优化。
我的新版本的引擎就是因为简化了两三行语句使得整个压缩过程有了20%-200%的速度提升。
而且我在代码的范围检查部分使用了编译器指令，在理想情况下(也就是说你可以保证输入数据完全合法)，可以关掉范围检查部分来编译，这样得到的代码速度还会快10%左右...
牧野みみも - 2005/2/12 10:33:00
我,我是小白,我,我飘过
怎么我楞是没看懂那
创始神噬天 - 2010/9/14 12:43:00
AVG32(准)全兼容的引擎已经有人写出来了？？？
1