Cross-platform file system support

SDL Development
1

I’ve been taking a look a method of getting good cross platform
file-system support and wondered how other people approach it.

Currently, for cross-platform work, I usually use C libraries for
file access. These are great as cross-platform file tools but they
have some pretty big limitations. For instance my save and preference
files nearly always live close to the application.

At the moment this appears to be the approach of quite a few games -
but it certainly isn’t ideal on any of the current operating systems.
I’ve had users complain about it and friends of mine complain about
it with games generally. With any other application this would be
unacceptable.

I also wonder why SDL hasn’t had extended file functions added - it
seems such a obvious omission that I wonder what the problem is.
Since SDL is such a powerful games library it seems like this is the
next step in cross platform support.

I think I’d want to do the following:

  • Get a basic directory listing
  • Create a directory
  • Get path to Home data directory (e.g. normal user document directory)
  • Get path to Preference directory.
  • Get the Normal Path separator character.
  • Get a list of Illegal/Legal directory/file characters for this OS.
  • Longer term goal - Unicode support.

Any comments?

Regards,
Rob

2

check out physicsfs i think it does alot of these things.

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 (:

PhysicsFS> ----- Original Message -----

From: rob@lightsoft.co.uk (Rob Probin)
To:
Sent: Wednesday, August 11, 2004 11:57 AM
Subject: [SDL] Cross-platform file system support

I’ve been taking a look a method of getting good cross platform
file-system support and wondered how other people approach it.

Currently, for cross-platform work, I usually use C libraries for
file access. These are great as cross-platform file tools but they
have some pretty big limitations. For instance my save and preference
files nearly always live close to the application.

At the moment this appears to be the approach of quite a few games -
but it certainly isn’t ideal on any of the current operating systems.
I’ve had users complain about it and friends of mine complain about
it with games generally. With any other application this would be
unacceptable.

I also wonder why SDL hasn’t had extended file functions added - it
seems such a obvious omission that I wonder what the problem is.
Since SDL is such a powerful games library it seems like this is the
next step in cross platform support.

I think I’d want to do the following:

  • Get a basic directory listing
  • Create a directory
  • Get path to Home data directory (e.g. normal user document directory)
  • Get path to Preference directory.
  • Get the Normal Path separator character.
  • Get a list of Illegal/Legal directory/file characters for this OS.
  • Longer term goal - Unicode support.

Any comments?

Regards,
Rob

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

3

I’ve been taking a look a method of getting good cross platform
file-system support and wondered how other people approach it.

Currently, for cross-platform work, I usually use C libraries for
file access. These are great as cross-platform file tools but they
have some pretty big limitations. For instance my save and preference
files nearly always live close to the application.

At the moment this appears to be the approach of quite a few games -
but it certainly isn’t ideal on any of the current operating systems.
I’ve had users complain about it and friends of mine complain about it
with games generally. With any other application this would be
unacceptable.

I also wonder why SDL hasn’t had extended file functions added - it
seems such a obvious omission that I wonder what the problem is. Since
SDL is such a powerful games library it seems like this is the next
step in cross platform support.

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.

Bye,

MaxAm 11.08.2004 um 20:57 schrieb Rob Probin:

4

Thanks for the ideas. The two that look good are:

PhysicsFS PhysicsFS

…which is a file-system library and the following is data directory
locator…

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

5

I use PHYSFS, and it is good, however it does not come packaged with
most Linux distributions that allow you to install via CD. That, I
find, is the only prohibition to using it. This is not a problem though
in windows where you can just drop in the DLL.

-TomT64

Rob Probin wrote:> Thanks for the ideas. The two that look good are:

PhysicsFS PhysicsFS

…which is a file-system library and the following is data directory
locator…

fnkdat - Summary [Savannah]
http://www.maccormack.net/~djm/fnkdat/

I’m going to look at PhysicsFS.

6

cant you drop in a .so or something in linux?> ----- Original Message -----

From: tomt64@users.sf.net (TomT64)
To: “A list for developers using the SDL library. (includes SDL-announce)”

Sent: Thursday, August 12, 2004 3:29 PM
Subject: Re: [SDL] Re: Cross-platform file system support

I use PHYSFS, and it is good, however it does not come packaged with
most Linux distributions that allow you to install via CD. That, I
find, is the only prohibition to using it. This is not a problem though
in windows where you can just drop in the DLL.

-TomT64

Rob Probin wrote:

Thanks for the ideas. The two that look good are:

PhysicsFS PhysicsFS

…which is a file-system library and the following is data directory
locator…

fnkdat - Summary [Savannah]
http://www.maccormack.net/~djm/fnkdat/

I’m going to look at PhysicsFS.

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

7

It can be done, via LD_LIBRARY_PATH env.var that tells your app to
look in a special place for the libs.

I’ve tested it, and it works, so you could basically do a “no
dependencies” executable package using that technique.

-ak

13.8.2004 kello 01:48, Alan Wolfe kirjoitti:

cant you drop in a .so or something in linux?>

----- Original Message -----
From: “TomT64”
To: “A list for developers using the SDL library. (includes
SDL-announce)”

Sent: Thursday, August 12, 2004 3:29 PM
Subject: Re: [SDL] Re: Cross-platform file system support

I use PHYSFS, and it is good, however it does not come packaged with
most Linux distributions that allow you to install via CD. That, I
find, is the only prohibition to using it. This is not a problem
though
in windows where you can just drop in the DLL.

-TomT64

Rob Probin wrote:

Thanks for the ideas. The two that look good are:

PhysicsFS PhysicsFS

…which is a file-system library and the following is data directory
locator…

fnkdat - Summary [Savannah]
http://www.maccormack.net/~djm/fnkdat/

I’m going to look at PhysicsFS.

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

8

There is also Boost Filesystem lLbrary:
http://www.boost.org/libs/filesystem/doc/index.htm

The drawback is that boost is too big dependence.On Thu, 2004-08-12 at 23:33, Rob Probin wrote:

Thanks for the ideas. The two that look good are:

–
Ivo Danihelka

9

Why do this when you could just statically link to it? The zlib license does
not prohibit this, in fact there are countless programs out there (both
closed and open) that statically link to zlib. PhysFS uses the same license
so it’s no different.On August 12, 2004 1848, Alan Wolfe wrote:

cant you drop in a .so or something in linux?

10

The problem with static linking is the number of Linux distributions and
their dependencies. You may release a static version, but you’d
basically have to do it for every distro you want to support to be sure
the user wouldn’t need to upgrade or install something else.

-TomT64

Simon Roby wrote:>On August 12, 2004 1848, Alan Wolfe wrote:

cant you drop in a .so or something in linux?

Why do this when you could just statically link to it? The zlib license does
not prohibit this, in fact there are countless programs out there (both
closed and open) that statically link to zlib. PhysFS uses the same license
so it’s no different.

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

11

Good point.

13.8.2004 kello 02:07, Simon Roby kirjoitti:On August 12, 2004 1848, Alan Wolfe wrote:

cant you drop in a .so or something in linux?

Why do this when you could just statically link to it? The zlib
license does
not prohibit this, in fact there are countless programs out there (both
closed and open) that statically link to zlib. PhysFS uses the same
license
so it’s no different.

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl