LateralGM Forum

I had this thought a while ago, just thought I'd throw it in here.

The nature of the gm6/gmk format makes it very difficult to work as a team. Most people end up passing the file back and forth and manually merging changes/resolving conflicts if two people work on the file concurrently.

A simple way to make gm files friendly with systems like SVN is to split the file up into a project folder. Take for example a sprite. The image could be stored as one file, and the settings for the resource could be stored in a separate text-based (most likely xml) file. The resource tree would correspond directly to the directory structure of the project folder.

Another advantage of this format is that the whole file wouldn't need to be loaded into memory. Currently, to load something like a sprite into memory on demand would be messy - either requiring that we dump the zlib data to a temp file, or remember a file offset to come back to (and this would require a timestamp or some other verification the file hasn't changed since). With this system, the image file can simply be read when required.

Obviously this idea would be for 1.7, or possibly even a plugin.

I've toyed with this idea myself as well, although was never really able to get the concept fully down. I suppose if we use the tree as the file system, it would work.

As for the "other advantage", that would require a significant rewrite of LGM

It wouldn't be too difficult to make a general interface for delayed loading - that way the implementation could be plugged in depending on where the file was read from. Anyway, it's probably a discussion for somewhere else.

Furthermore, I believe this would be very easy to implement, one would just need to work out the format specifications and such.

To keep it modular, it'd be best served as a plugin.

I created a tool like this, with some help from IsmAvatar. It uses LateralGM as a library for reading/writing the .gmk files.

You can find it on Github: http://github.com/Medo42/Gmk-Splitter