Any chance we'll see something along the lines of building a "resource package" which can be loaded by a executable in run-time? When your ZGE project's file-size extends into the regions of tens or hundreds of megabytes, saving & loading starts taking a awful amount of time.
I guess when you use 512x512 jpg textures and sampled audio and large imported meshes you can quite easily add up to those sizes you mention.
A separate resource file would not be impossible. However maybe first I can check if there is anything easy I can do to speed up the save/load. Is it the mainly the zgeproj file that's slow to save/load in the designer or is it the exe-generation?
The primary bottleneck during development is saving the .zgeproj. Not only because it seems to be the slowest .. but also since it's the operation you use the most.
For the end-user, the startup time of large exe's might be problematic .. perhaps a improved start-up dialog ( combination of Unity and Game Maker ? ) with a loading bar could help here.
A concern that would come with resource packages would be how to protect your data though.
When saving a zgeproj the data of binary properties are compressed using loss-less compression. And the problem with such compression is that it does not work well at all on noisy inputs such as photographs or sampled audio. So when using that kind of data the cpu will be very busy trying to compress things and still probably not saving more than 1% in size. However the compression works great on other data (like images with less colors or imported 3ds-models) and keeps the zgeproj-files small which makes them easy to edit in text-editors if needed. And the diskaccess when saving the file is probably the bottleneck anyway.
Have you tried to start a 10mb or larger zge-generated exe-file? How long is the delay? I figure it shouldn't take longer than the time it takes to read the data from disk when using uncompressed exe's.
Just did some tests .. strangely enough when saving a project with a imported raw sample of 100mb, the filesize of the .zgeproj ends up being 200mb. Anyway, it took about half a minute to save, which is pretty representable for what I've been experiencing.
Starting up uncompressed files is significantly faster then compressed .. so for large projects I guess that's the way to go ( in combination with a installer / zip compression ).
Well I'm glad it actually works at all with 100mb files because I've never tested it with anything that big. The double size of projects files is because the binary data is encoded as hex-strings with every byte is two characters. Something like a Base64 encoding would be more compact so maybe we can support that in the future if more users have large projects.
One idea is to save the project using a thread so that you can still work in the designer while saving. But the downside is that it makes it much more complex and sensitive to bugs, and save/load must be rock-solid functionality so that no user data is lost.
I am still torn on this isssue,. I like the single file simplicity, and my games so far are all in the <100k range so loading is not a problem at all,., however external resources could be very usefull as well. Mods could be implemented; change bitmaps,meshes, sounds, maps, whatever.., or how about generating the bitmaps and then saving them (component need for that! or even an option on the current bitmap component like the one on sound,. many uses!) to load the next time the game is run,. .
also on a resource heavy game updating would also be much easier if you just had to supply the new resources and the .exe, old stuff would already be installed.., just some reasons to consider an option for externalizing some resources. As far as protecting them an optional data scrambler could be devised,. . when saving or loarding the data is passed through a key of some sort that reorders that data making it tougher to get at,. . just another thought.
