SolarLune
add initial externally stored levels support
This feature will only work with Open(), since that function can easily figure out the file location
(it gets it as an argument).
I don't know how to make Read() work without there breaking its API.
Fixes #8
Sorry for the late reply - gofmt changing formatting is perfectly fine, and can be added into this PR without issue.
I'm wondering, though, if it might be better to add the ability to read from a file system - that way, we could reliably know what the file system of an embedded or on-disk asset directory looks like to determine where external levels might be.
Feel free to ignore this input as I haven't used this library, however it is relevant to SolarLune's previous statement.
Using one or more of the fs interfaces (https://pkg.go.dev/io/fs) would be the best and most idiomatic go choice. I personally don't like it when libraries always assume that read operations are done with the local filesystem. Traditionally, many games ship their assets in a compressed or obfuscated format, of which access to would be best implemented via an interface. If a local file system is always presumed, then some pretty bad kludges have to be implemented to give access.
That is true. I usually have some sort of a file reader abstraction myself, which can read either from a local file system or an embedded storage (based on a filename prefix). I didn't want to break the API though. I've just started to use this library and I don't feel the courage to propose such changes. :D
Hello! I updated ldtkgo recently to add a function that can load a file from a file-system. Would you be interested in adapting your PR to use that new function now?
I'm not feeling confident about keeping this PR open anymore. I still need this feature, but I'm not working on a project with ldtk levels anymore (although I might come back to it in a few months). I'll close the PR and maybe someone can implement it (if not, I may send another PR when I have some time for it again).