Resources

If there is something important you think is missing in the current version of ZGameEditor then you can post a feature request here!

Moderator: Moderators

Post Reply
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Resources

Post by Kjell »

:idea:

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.

Yea .. I know.

K
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

What kind of projects are you building Kjell? :)

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?
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

:)

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.

K
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

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.
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

Hej,

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 ).

K
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

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.
User avatar
jph_wacheski
Posts: 1005
Joined: Sat Feb 16, 2008 8:10 pm
Location: Canada
Contact:

Post by jph_wacheski »

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.
iterationGAMES.com
Post Reply