<html><body 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><br>On Jul 16, 2009, at 12:58 PM, Jeremy <<a href="mailto:jswigart@gmail.com">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"><a href="mailto:mr.danielaquino@gmail.com">mr.danielaquino@gmail.com</a></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"><a href="mailto:physfs@icculus.org">physfs@icculus.org</a></a><br>
<a href="http://icculus.org/mailman/listinfo/physfs" target="_blank"><a href="http://icculus.org/mailman/listinfo/physfs">http://icculus.org/mailman/listinfo/physfs</a></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">physfs@icculus.org</a></span><br><span><a href="http://icculus.org/mailman/listinfo/physfs">http://icculus.org/mailman/listinfo/physfs</a></span><br></div></blockquote></body></html>