Thanks for the ideas. The two that look good are:
PhysicsFS http://icculus.org/physfs/
…which is a file-system library and the following is data directory
locator…
http://savannah.nongnu.org/projects/fnkdat
http://www.maccormack.net/~djm/fnkdat/
I’m going to look at PhysicsFS.
Max Horn wrote:
One problem is that not all target systems even have a traditional
filesystem in the sense your list implies. And on some you want to
treat special files special; e.g. on a Dreamcast you’ll distinguish
between the (read only) game data file (stored on a CD), and your
read/write save states (stored on a memory unit). Any API which wants
to claim to be “fully portable” would have to support such special
things in some way.
I agree.
And I expect some consoles have interesting limitations on writing to
memory units/cards.
Even on “traditional” operating systems some areas are theoretically
write-protected (e.g. Applications folder on Mac OS X, the /usr/
folder in Linux and the “Program Files” on Windows).
There are also differences between traditional operating systems -
preference directories as well as user data/document directories - as
on Mac OS X (and Mac OS 9). You might want to save games and screen
shots to a data directory and save registration and screen
configuration to the “preferences” directory. Some games get this
right, others create a folder in the home directory and others
(including some very big names) just do everything in the application
directory.
Whilst these are mostly accepted by games players a good game
file-system would take account these.
Alan Wolfe wrote:
the reason this isnt part of SDL is because of bloat.
the core sdl lib has stuff commonly needed like thread support, basic
audio/video etc but if you want more functionality than that you look to one
of the many add on libs.
for instance if you want network support you can use sdl_net, but if i didnt
want to use network stuff, i could just not use sdl_net and thus keep my
binaries smaller (:
I agree about keeping the core library small.
I don’t mind using other libraries, e.g. SDL_net and SDL_mixer which
both “feel” part of SDL, even though they aren’t in the core library.
I do wonder whether some of the sections currently in the core
library shouldn’t be in an optional library. Threads is a possible
case in question - not essential for all traditional games and in
fact isn’t supported fully on all platforms. But don’t get me wrong -
SDL is one of the most well designed API’s I’ve seen. Simplicity and
power that’s not the lowest common denominator.
Regards,
Rob