Archiving / compression module for LÖVE

[Azhukar]

I would like to have some form of module to (de)compress data.

Several places it could be used: savegames, game mods, sending large game data (maps/levels/etc) over network.

To clarify, I'm not talking about a pure lua implementation but rather a love.compressor.* kind of deal.

[raidho36]

Why not use LibCompress?

You also could've looked up DEFLATE or LZMA algorithm and implement it by yourself and suggest an upstream patch. Though you don't even need to look anything up since LÖVE already uses zlib.

[Boolsheet]

Why not use LibCompress?

If you're asking why he doesn't want a pure Lua library, then the obvious answer is that Lua is not meant for doing data crunching on this scale. It's slow.

LÖVE already uses zlib.

LÖVE doesn't. Some of its dependencies do.

Loading a zlib wrapper as a Lua module is a valid way to approach this issue though. Sadly, the official binaries of LÖVE 0.8.0 for Windows and OS X have problems with the loading of binary modules. It should get better with 0.9.0.

Edit: Actually! LÖVE may benefit from an integrated implementation for the embedded scripts. Then again, loading would be slower and the binaries (hopefully) get sent in a compressed archive anyway.

[josefnpat]

Why not use LibCompress?

If you're asking why he doesn't want a pure Lua library, then the obvious answer is that Lua is not meant for doing data crunching on this scale. It's slow.

LÖVE already uses zlib.

LÖVE doesn't. Some of its dependencies do.

Loading a zlib wrapper as a Lua module is a valid way to approach this issue though. Sadly, the official binaries of LÖVE 0.8.0 for Windows and OS X have problems with the loading of binary modules. It should get better with 0.9.0.

Edit: Actually! LÖVE may benefit from an integrated implementation for the embedded scripts. Then again, loading would be slower and the binaries (hopefully) get sent in a compressed archive anyway.

From what I understand the zip-mounting is getting an upgrade in 0.9.0, and I am very excited about it. I hope *hint hint* that the zip and unzip functions are exposed ;)

[slime]

I hope *hint hint* that the zip and unzip functions are exposed

I don't think that's possible (with physfs 2.0 at least) - in fact, I don't think physfs of any version uses zip compression, just decompression, so I can't see physfs exposing an API for unzipping in the future.

[raidho36]

But there will be data compression functions nevertheless, right?

[slime]

Will there be? I don't know. Not for 0.9.0, I think.

What 0.9.0 will have is a function to mount a zip (or a folder) which is inside the game's save directory in love.filesystem and add it to the search paths.

This lets you download a zip or .love file to the save directory and call love.filesystem.mount("downloadedlove.love", "mystuff"), and then you can do love.graphics.newImage("mystuff/myimage.png") or whatever.

[clofresh]

How come love.filesystem.mount() can't read from the game's source directory? My use case is that I want to use OpenRaster files for game assets. OpenRaster is just a zip file of one image per layer and an xml metadata file to describe them, and since GIMP and Krita can export OpenRaster files directly, it'd be really convenient to use for game assets.

[slime]

Because the game's source directory is often zipped itself (as a .love), and PhysFS can't mount a zip from inside a zip.

Zipping a PNG file is generally not very useful, because PNG files are compressed using the exact same algorithm that zip files use.

[clofresh]

Oh I see. I guess I can just add a build step that unzips the .ora file before packaging into the .love file.

Yeah, I'd like to use .ora files more to have a compact file format that simplifies the art -> game workflow, since the layers and relative positions of those layers are preserved in the .ora metadata and can be loaded right into the game.