So far Spelunky-PSP's build process involved resource-compiling all its assets into header files, resulting in a single executable that could be placed around the filesystem without having to copy anything else. As for portability and convenience, this feature proved to be extra handy when building a web version - no assets had to be streamed through the network, it was enough to download the WASM module with the game. However, as the project progresses and I'm soon to work on the new levels (and thus introducing way more assets), the current workflow of having to resource-compile assets, re-compile and re-link the project every time an asset is changed/added turns out to be too complicated.
That's the rationale for this MR: to extend current solution with a build-time switch to optionally use real or resource-compiled (called virtual interchangeably) filesystem. This way I can work much easier on adding assets in development builds and still use the previous approach of a single executable in production builds.
Before merging:
[x] - Rethink git-lfs pros and cons for shipping asset files
The repository contains multiple files (game assets) with size ranging between 1-10 MB, which is a good case for git-lfs adoption. What's more, I have already used git-lfs in other, professional projects with much satisfaction. The difference is, said projects were backed by internal, self-hosted infrastructure. Here I am relying on Github and its cloud solution, and its billing docs state:
Every account using Git Large File Storage receives 1 GiB of free storage and 1 GiB a month of free bandwidth. If the bandwidth and storage quotas are not enough, you can choose to purchase an additional quota for Git LFS. Unused bandwidth doesn't roll over month-to-month.
Bandwidth and storage usage only count against the repository owner's account. In forks, bandwidth and storage usage count against the root of the repository network. Anyone with write access to a repository can push files to Git LFS without affecting their personal bandwidth and storage quotas or purchasing data packs. Forking and pulling a repository counts against the parent repository's bandwidth usage.
You must manage billing settings and paid features for each of your accounts separately. You can switch between settings for your personal account, organization accounts, and enterprise accounts using the context switcher on each settings page.
So - I receive some small amount of free git-lfs storage (1 GB) and some amount of bandwidth (1 GB) for free.
I can work with that, given the size of the assets, with a slight possibility of running out of space in a very distant future and having to pay for storage. The bandwidth quota is shady in my opinion; I read the docs multiple times and still could not shake the feeling off that malicious actors could just clone my repository multiple times to suck my bandwidth and make me pay more for the service (not to mention real people cloning the project and forks counting to the bandwidth... of the root project).
Being realistic, it's only me working on this project - there's no need to go out of my way and pay monthly fee just to make things "super correct" from software engineering point of view and introducing git-lfs, even though I like it and know its benefits, such as smaller repository size and faster cloning/fetching. In the end, files are reasonably small <10 MB, the amount of them is not overwhelming and once added, they are not modified.
There are some other, potential problems that git-lfs introduces, such as problems with repository migration, but I don't deem them worth discussing as the argument above is enough for me not to adopt it.
So far Spelunky-PSP's build process involved resource-compiling all its assets into header files, resulting in a single executable that could be placed around the filesystem without having to copy anything else. As for portability and convenience, this feature proved to be extra handy when building a web version - no assets had to be streamed through the network, it was enough to download the WASM module with the game. However, as the project progresses and I'm soon to work on the new levels (and thus introducing way more assets), the current workflow of having to resource-compile assets, re-compile and re-link the project every time an asset is changed/added turns out to be too complicated.
That's the rationale for this MR: to extend current solution with a build-time switch to optionally use real or resource-compiled (called virtual interchangeably) filesystem. This way I can work much easier on adding assets in development builds and still use the previous approach of a single executable in production builds.
Before merging:
The repository contains multiple files (game assets) with size ranging between 1-10 MB, which is a good case for git-lfs adoption. What's more, I have already used git-lfs in other, professional projects with much satisfaction. The difference is, said projects were backed by internal, self-hosted infrastructure. Here I am relying on Github and its cloud solution, and its billing docs state:
So - I receive some small amount of free git-lfs storage (1 GB) and some amount of bandwidth (1 GB) for free. I can work with that, given the size of the assets, with a slight possibility of running out of space in a very distant future and having to pay for storage. The bandwidth quota is shady in my opinion; I read the docs multiple times and still could not shake the feeling off that malicious actors could just clone my repository multiple times to suck my bandwidth and make me pay more for the service (not to mention real people cloning the project and forks counting to the bandwidth... of the root project).
Being realistic, it's only me working on this project - there's no need to go out of my way and pay monthly fee just to make things "super correct" from software engineering point of view and introducing git-lfs, even though I like it and know its benefits, such as smaller repository size and faster cloning/fetching. In the end, files are reasonably small <10 MB, the amount of them is not overwhelming and once added, they are not modified.
There are some other, potential problems that git-lfs introduces, such as problems with repository migration, but I don't deem them worth discussing as the argument above is enough for me not to adopt it.