It's faster because there is normally less file IO. The files are less fragmented, so there is less seeking, The files are compressed so there is less reading. The cpu cost of the uncompression is typically insignificant compared to the IO cost.<br>
<br><div class="gmail_quote">On Thu, Jul 16, 2009 at 3:34 PM, Daniel Aquino <span dir="ltr"><<a href="mailto:mr.danielaquino@gmail.com">mr.danielaquino@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#FFFFFF"><div>Well I was just looking for even more reasons to use it.<br><br></div><div>By operate do you mean you can also edit files in the archive?</div><div><br></div><div>Why is it faster, doesn't the unzipping cause delay too?</div>
<div><br></div><div>Can you specify a byte pointer to load? so I could append an archive to my binary which would make switching versions as seemless as clicking on an exe?</div><div><br></div><div><br></div><div>Do you normally release archives with only changed files or would you simply replace the entire main archive?</div>
<div><br></div><div>I'm trying to think of the best practice for releasing updates while still being able to roll back if at all possible....</div><div><br>Sent from my iPhone</div><div><div></div><div class="h5"><div>
<br>On Jul 16, 2009, at 12:58 PM, Jeremy <<a href="mailto:jswigart@gmail.com" target="_blank">jswigart@gmail.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>You are asking a question with which you discount the answers as part of the question.<br>
Not a very fair question. What are the benefits of driving a car, other than getting someplace in a timely manner, other than not being exposed to the elements, etc.<br>
<br>Being able to treat all files as if they were raw files with no regard to whether or not they are in an archive is a significant simplification of the file IO process. The by product of that simplifying the update process by the mount order of archives is a nice added benefit. In general loading data from large pack files has performance benefits as well, such as significantly reduced load times. Physfs gives you that benefit in a way that essentially allows you to operate on the files as if they were just raw files in a folder, whether they are or not. It's common during development of a project to have all the files loose in the folders, since they change so often. Come release time, you throw them in a zip and load times are improved, and it's much easier to release and update, while saving a bit of on disk space, at no additional work on the projects file system.<br>
<br><div class="gmail_quote">On Thu, Jul 16, 2009 at 11:49 AM, Daniel Aquino <span dir="ltr"><<a href="mailto:mr.danielaquino@gmail.com" target="_blank"></a><a href="mailto:mr.danielaquino@gmail.com" target="_blank">mr.danielaquino@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
As I sit here I'm wondering what the benefits really are for putting<br>
in the work needed to get physfs into a game...<br>
<br>
I obviously know that I could provide updates as zip's that could<br>
easily be rolled back.<br>
<br>
The user can also easily override any file by adding his own to the<br>
write folder.<br>
<br>
You could specify paths to other zips/directories on the cli and it<br>
all just flows there is no need to point at 1 physical directory and<br>
then glue it all all together your self...<br>
<br>
But beyond that what is the benefits ?<br>
<br>
I was trying to reduce the complexity of rolling out version with<br>
multiple files... Previously I use to just push a new exe and it was<br>
simple to click on the exe you wanted to launch... Now that I have lua<br>
and other dll's in the project it's a multi file update that<br>
overwrites previous entries which looses the ability to pick the<br>
version you want to play in... So I was figuring I could come up<br>
with a small boot strapper that would load up a bunch of locations<br>
using physfs, present a list of exe's to the end user, then extract it<br>
and launch it... Then the concept would be that the exe knows (perhaps<br>
based on date strings in the file names) which updates came previous<br>
to it self and doesn't load up any new ones... This way updates could<br>
come in a zip and you can still play multiple versions...<br>
<br>
Any ideas?<br>
_______________________________________________<br>
physfs mailing list<br>
<a href="mailto:physfs@icculus.org" target="_blank"></a><a href="mailto:physfs@icculus.org" target="_blank">physfs@icculus.org</a><br>
<a href="http://icculus.org/mailman/listinfo/physfs" target="_blank"></a><a href="http://icculus.org/mailman/listinfo/physfs" target="_blank">http://icculus.org/mailman/listinfo/physfs</a><br>
</blockquote></div><br>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>physfs mailing list</span><br><span><a href="mailto:physfs@icculus.org" target="_blank">physfs@icculus.org</a></span><br>
<span><a href="http://icculus.org/mailman/listinfo/physfs" target="_blank">http://icculus.org/mailman/listinfo/physfs</a></span><br></div></blockquote></div></div></div><br>_______________________________________________<br>
physfs mailing list<br>
<a href="mailto:physfs@icculus.org">physfs@icculus.org</a><br>
<a href="http://icculus.org/mailman/listinfo/physfs" target="_blank">http://icculus.org/mailman/listinfo/physfs</a><br>
<br></blockquote></div><br>