PhysicsFS with other libraries

Started by
4 comments, last by Ariste 14 years, 1 month ago
I've been looking at packing game assets into archive files (like Doom, Quake, etc.). I've done some research and PhysicsFS seems to be almost exactly what I need. The problem is some libraries I'm using expect file names (SQLite for example). Some libraries can be given data in memory as opposed to filenames but in the case of SQLite that doesn't make much sense. The solution so far seems to be to leave such files out of the archives. Perhaps in this case I should be making archives of certain types of assets (e.g. textures.zip, sounds.zip, etc.) instead of one archive with all the data in it, and leave things like SQLite files on the "normal" file system? Anyone have any thoughts/experience? Thanks
Advertisement
I have used PhysicsFS with SFML and I didn't have a problem having my sounds and images in the same archive, but I suppose this might depend more on the API you are using and exactly what you are doing.
Quote:Original post by wicked357
I have used PhysicsFS with SFML and I didn't have a problem having my sounds and images in the same archive, but I suppose this might depend more on the API you are using and exactly what you are doing.


Sorry, I should have clarified what I meant by separate archives. I meant as a way to organize assets. I could also have all assets in one archive and leave files such as SQLite databases outside the archives.
I imagine your SQLite DB files won't be too big? One thing you could possibly do is extract them to a temporary location, and delete or repack them on exit. The first obvious problem with this is that if your app crashes you might loose changes in the DB files (might be able to work around this with some smarts about what to do if an file already exists?)
"I am a donut! Ask not how many tris/batch, but rather how many batches/frame!" -- Matthias Wloka & Richard Huddy, (GDC, DirectX 9 Performance)

http://www.silvermace.com/ -- My personal website
Quote:Original post by silvermace
I imagine your SQLite DB files won't be too big? One thing you could possibly do is extract them to a temporary location, and delete or repack them on exit. The first obvious problem with this is that if your app crashes you might loose changes in the DB files (might be able to work around this with some smarts about what to do if an file already exists?)


Thanks for the reply. The files shouldn't be too big, probably only a few megabytes each. I had planned to only have readable files in the archive and any writable files (i.e. save games/configs) in a separate directory as just normal (not archive) files so losing changes wouldn't be a problem.

I had thought about extracting files I want to read from the archive to a temporary folder and getting SQLite to load them from there, but that just seemed like a bit of a hack (and avoids any performance benefits archive files would have given, not that that's too important for what I'm doing). It could certainly easily done and for all I know, other games do this (anyone can correct me if I'm wrong here).

I guess if I don't need the extra file system performance of using archive files, I should just forget about them? Though, it is nice to have all assets packed up in the one file, and you can easily "update" the game's data by providing new archives with the changed files (like in Quake).
Is your problem only that you need actual file names? If so, you could wrap PhysFS in some classes (FileSystem, Archive, Directory) that "remember" their real paths. That way you could refer to your SQLite files by their interpolated filesystem paths and still be able to recover their actual paths.

This topic is closed to new replies.

Advertisement