Jump to content
  • entries
    943
  • comments
    5,899
  • views
    924,395

Too Cool


Josh

1,726 views

 Share

While working with zlib, I implemented the package system, and it turned out really cool. Here's some stuff you can do

 

First, let's load the package and register it in the file system:

Package* pak = ReadPackage("mystuff.pak"); //Read the package
RegisterPackage(pak); //Register package into file system

Read a file from a package, just as if it were on the hard drive:

Stream* stream = ReadFile("mystuff/new document.txt"); //Read a file straight out of the package!

Write a file to a package, just as if it were on the hard drive:

Stream* stream = WriteFile("mystuff/new document.txt"); //Write a file straight into the package!

To save your changes permanently in the package, make sure you close it before the program ends:

pak->Close(); //Close the package when finished to save the changes

This should work in the editor, too, so you can store all your files in packages and the editor will automatically save any packages that change.

 

When a file exists both on the hard drive and in a package, the engine will preferentially read from the file on the hard drive. When a file is written, the engine will preferentially write to a package file, if one is available with the directory the file is being written to. Zip folders and file hierarchy are kept intact.

 

The idea is you can register all your packages, probably with a recursive function, and then read files from and write them to the packages, without knowing or caring whether you are dealing with a file on the hard drive or a file in a package. This is different from the abstract file system, because each file has a precise file path. The only ambiguity is when you have a file on the hard drive and in a package file with the same name, in the same directory. The package file names are considered folders. So if I had a model "teapot.mdl" in a package file "Models.pak" I would load it by calling LoadModel("Models\teapot.mdl"). If you want, you can leave all your files on the hard drive during development, and then let Leadwerks automatically package them up for publishing, and you won't have to change any code to load your files.

 

Once a package is registered, all the file system commands will include them in the file hierarchy, and there is no need to worry about packages at all. If you do write to any, you should close them before ending the program so your changes are saved.

 

My idea I mentioned last time about putting shaders in zip packages and calling the .shd files won't work, because that involves packages within packages, and I don't want to do that. So the shaders are simply going to be left as collections of associated .vert, .frag, .geom, .ctrl, and .tess files, which will be easier to keep track of when editing anyways.

 Share

3 Comments


Recommended Comments

Great news, Josh.

 

Yes. Indeed simple for the user.

This means that we just can zip levels into a pak and load them.

Really great when distributing files.

 

For my own game idea it will be perfect as new levels will be loaded from Internet.

Great news for me :)

Link to comment

Something like that. There's a few ways I can do it.

 

I'm a little worried about the potential for a crash to occur during the pack save operation, but it writes to a temporary file, then renames it when finished, so it seems like the probability of corrupting a package is no worse than the risk of saving a zip file.

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...