什么是非常少量数据的最佳压缩库(3-4 kib?)

Max*_* E. 6 networking lossless-compression quake

我正在开发一个游戏引擎,它是Quake 2的松散后裔,添加了一些像脚本效果的东西(允许服务器向客户端详细指定特殊效果,而不是只有有限数量的硬编码效果,客户端能够这是对网络效率的灵活性的权衡.

我遇到了一个有趣的障碍.请参阅,最大数据包大小为2800字节,每个客户端每帧只能有一个数据包.

这是一个做"火花"效果的剧本(可能对子弹撞击火花,电击等有好处) http://pastebin.com/m7acdf519(如果你不明白它,不要出汗;这是我制作的自定义语法,与我提出的问题无关.)

我已尽一切可能缩小该脚本的大小.我甚至将变量名称缩减为单个字母.但结果恰好是405个字节.这意味着每帧最多可以容纳6个.我还想到了一些服务器端的更改,可以将其另外更改为12,并且协议更改可能会节省另外6个.虽然节省会因您使用的脚本而异.

然而,在那些387个字节中,我估计在效果的多次使用之间只有41个是唯一的.换句话说,这是压缩的主要候选者.

事实上,R1Q2(具有扩展网络协议的向后兼容Quake 2引擎)具有Zlib压缩代码.我可以解除这些代码,或至少密切关注它作为参考.

但Zlib一定是这里的最佳选择吗?我能想到至少一种替代方案,LZMA,并且可能会有更多.

要求:

  1. 必须非常快(如果每秒运行超过100次,则必须具有非常小的性能.)
  2. 必须将尽可能多的数据塞入2800字节
  3. 小元数据足迹
  4. GPL兼容

Zlib看起来不错,但有什么更好的吗?请记住,这些代码都没有被合并,因此有足够的实验空间.

谢谢,-Max

编辑:感谢那些建议将脚本编译成字节码的人.我应该明白这一点 - 是的,我这样做.如果你愿意,你可以在我的网站上浏览相关的源代码,虽然它仍然没有"漂亮".
这是服务器端代码:
Lua组件:http://meliaserlow.dyndns.tv: 8000/alienarena/lua_source/lua/ scriptedfx.lua
C组件:http://meliaserlow.dyndns.tv :8000/alienarena/lua_source /game/g_scriptedfx.c
对于我发布的特定示例脚本,这将获得一个低至405字节的1172字节源 - 仍然不够小.(请记住,我希望尽可能多地将这些内容放入2800字节!)

EDIT2:无法保证任何给定的数据包都会到达.每个数据包应该包含"世界状态",而不依赖于先前数据包中传达的信息.通常,这些脚本将用于传达"眼睛糖果".如果没有空间,它会从数据包中删除,这没什么大不了的.但是,如果太多的东西掉落,事情开始在视觉上看起来很奇怪,这是不可取的.

Max*_* E. 2

最终更新:这两个库看起来差不多。Zlib 的压缩率提高了大约 20%,而 LZO 的解码速度大约快两倍,但两者的性能影响都非常小,几乎可以忽略不计。这就是我的最终答案。感谢所有其他答案和评论!

更新:在实现 LZO 压缩并看到性能明显更好之后,很明显,我自己的代码对性能影响负有责任(每个数据包可能的脚本效果数量大量增加,因此我的效果“解释器”得到了更多的运用) .) 我想为自己急于推卸责任的行为深表歉意,希望大家不要感到难过。我会做一些分析,然后也许我能够得到一些对其他人更有用的数字。

原帖:

好吧,我终于开始为此编写一些代码了。我从 Zlib 开始,这是我的第一个发现。

Zlib 的压缩效果非常出色。即使使用 Z_BEST_SPEED(而不是 Z_DEFAULT_COMPRESSION)进行压缩,它也能可靠地将 8.5 kib 的数据包减少到 750 字节或更少。压缩时间也相当不错。

然而,我不知道任何东西的解压速度竟然会这么糟糕。我没有实际数字,但每个数据包至少需要 1/8 秒!(Core2Duo T550 @ 1.83 Ghz。)完全不可接受。

据我所知,与 Zlib 相比,LZMA 是较差性能与更好压缩的权衡。由于 Zlib 的压缩已经过大,而且性能也已经非常糟糕,LZMA 目前已经不被人们所关注。

如果LZO的减压时间像它声称的那样好,那么我就会使用它。我认为最终服务器在极端情况下仍然能够发送 Zlib 数据包,但客户端可以配置为忽略它们,这将是默认设置。