[physfs] 2.0 wishlist...
tree at stain.org
Tue Sep 21 08:39:36 EDT 2004
Physfs 1.0 was indeed great for our project, it integrated really easily
with the dependencies we used, and modding to support it was easy in things
like freetype and libjpeg.
Following Adam Moss' starring system, these are how relevant they are to my
current project which uses physfs:
> - Move to Subversion from CVS. This is overdue.
[***] SVN is definitely the way to go, but not going to effect the project
> - Add "mount points":
[***] This would be useful to us if it existed. We use multiple track files
(Java jar files), which include code and data. At the moment, we have to
modify the search path manually for work around potential path conflicts.
Having a clean way to this would be preferred, especially when our track
files start to share data.
> - Expose the archiver registration mechanism to the outside world, so
> you can optionally plug in support for a format at runtime. Relatively
> easy to do, I think, would clean up the guts of physfs a little
[*] Cleaner so it's good, but not useful to us, as we know we just need Dir
and Zip handlers.
> - Reduce malloc() pressure. We allocate way too much small and temporary
> shit that is better suited for alloca().
[**] Not noticed any external problems either.
> - Set up a mechanism for file enumeration that employs a callback into
> the application to avoid allocating a throwaway list when possible.
[***] Again something which we would us if it existed.
> - Allow the application to provide allocation services (with the default
> to call malloc() directly from physfs). This is extremely useful for,
> say, a PalmOS port.
[*] Not needed by us
> - Find some way to relax or remove the security model so apps can have
> roughly the same codepath for the game itself and external tools. I
> think this probably needs a little more discussion.
[***] This has been an issue with our editors, but we have a work around or
editing the WriteDir when we need to.
> Non-blocking IO
[****] This would be probably be the thing I'd like to see most of the
suggestions raised. At the moment we load all our data at the start because
we have to, as our tracks get larger so will loading times, so some sort of
async loading would be very handy.
Addition (All I can think off to be honest):
Remove bundled zlib and use standard distro. I can't see any diffs except
the use of the Z_PREFIX usage.
[**] Not important, but cleaner. Our project uses zlib as a dll shared
between several other libs (libpng, etc), so this is already how we already
use physfs. I prefer this to staticly linking in several places.
fscanf and fprintf support
[**] Again something we already have externally, because I added it to a
modified abs-file.h we use. Because we used them a lot with text files prior
to using physfs, we figured adding support to physfs was fair enough. I've
attached the abstraction file we use, they are a quick hacky job, I'm sure
they are better ways to do it. (The vsscanf method is missing under windows
so had to be botched, and a better PC specific asm hack is on the web but
this one is cross-platform.)
And that's it for now,
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the physfs