SDL_RWops Enhancement Proposals

SDL Development
1

I am looking to enhance SDL_RWops in several ways and was wondering
peoples’ opinions on these. Would I be wasting my time on patches that
would not be included, or is someone else already doing this? Or, if
some of this has already been done, that would be even better. I
haven’t actually looked into the implementation details just yet (that
would be my next step).

I know some of this is already implemented in other packages, like
PhysicsFS, but what I’m looking for is just the very simplest of these
things which need to be abstracted to be truly cross-platform in the
SDL-using applications.

  1. Implement some kind of SDL_RWprintf/SDL_RWscanf functionality.

  2. Implement an understanding of directories. The idea is directories
    could be opened as RWops and could be parsed specially to open other
    RWops for files and directories therein.

  3. Some sort of SDL_RWFromConfigFile(“basename”) function, which will
    open a text or binary config file with basename in the appropriate
    location on each OS. For example, this would open "~/.basenamerc"
    in *nix, or “C:/WHEREVER_SETTINGS_ARE/basename.cfg” (or whatever is
    deemed more appropriate) in Windows, etc…

  4. Combine #3 and #2 to open settings/cache directories to be used for
    local storage of per-user data, settings, etc…

Obviously, this would be aimed at SDL-1.3. My hope is to tackle most,
if not all, of these this summer when I will have a bit of time.

Opinions/Questions?–
Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060505/84af96a5/attachment.pgp

2

Steaphan Greene escreveu:

  1. Implement some kind of SDL_RWprintf/SDL_RWscanf functionality.

  2. Implement an understanding of directories. The idea is directories
    could be opened as RWops and could be parsed specially to open other
    RWops for files and directories therein.

  3. Some sort of SDL_RWFromConfigFile(“basename”) function, which will
    open a text or binary config file with basename in the appropriate
    location on each OS. For example, this would open "~/.basenamerc"
    in *nix, or “C:/WHEREVER_SETTINGS_ARE/basename.cfg” (or whatever is
    deemed more appropriate) in Windows, etc…

  4. Combine #3 and #2 to open settings/cache directories to be used for
    local storage of per-user data, settings, etc…

Obviously, this would be aimed at SDL-1.3. My hope is to tackle most,
if not all, of these this summer when I will have a bit of time.

I think all of these are beyond the scope of SDL. When you really need a
complete platform for everything, you use a game engine, or a "fat"
library like PLIB or Allegro. I like SDL because it’s lightweight; if I
need anything else, I can use one of the many libraries built around
SDL, or even an independent one.
These functionalities may be useful, but I don’t think they need to be
part of the “core” library.—
Daniel K. O.

3

(All this is IMHO, of course):

That’s probably true of #1, and I’m happy to put it in another module
(especially since SDL no longer depends on libc). It’s also not too
bad to just use RWread/write and sprintf/sscanf to get the same
effect.

However, #2 - #4 are not particularly heavy and there is no way of doing
them in a cross-platform way that I am aware of without depending on a
library that is much heavier than should be required. This is my
motivation (justification?) for wanting to add them to the core of SDL
itself.

Do you disagree with that?On Sat, May 06, 2006 at 01:38:05AM -0300, Daniel K. O. wrote:

Steaphan Greene escreveu:

  1. Implement some kind of SDL_RWprintf/SDL_RWscanf functionality.

  2. Implement an understanding of directories. The idea is directories
    could be opened as RWops and could be parsed specially to open other
    RWops for files and directories therein.

  3. Some sort of SDL_RWFromConfigFile(“basename”) function, which will
    open a text or binary config file with basename in the appropriate
    location on each OS. For example, this would open "~/.basenamerc"
    in *nix, or “C:/WHEREVER_SETTINGS_ARE/basename.cfg” (or whatever is
    deemed more appropriate) in Windows, etc…

  4. Combine #3 and #2 to open settings/cache directories to be used for
    local storage of per-user data, settings, etc…

Obviously, this would be aimed at SDL-1.3. My hope is to tackle most,
if not all, of these this summer when I will have a bit of time.

I think all of these are beyond the scope of SDL. When you really need a
complete platform for everything, you use a game engine, or a "fat"
library like PLIB or Allegro. I like SDL because it’s lightweight; if I
need anything else, I can use one of the many libraries built around
SDL, or even an independent one.
These functionalities may be useful, but I don’t think they need to be
part of the “core” library.

–
Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060506/7a0a1c66/attachment.pgp

4

Hello Steaphan,

Saturday, May 6, 2006, 5:51:09 AM, you wrote:

SG> On Sat, May 06, 2006 at 01:38:05AM -0300, Daniel K. O. wrote:

Steaphan Greene escreveu:

  1. Implement some kind of SDL_RWprintf/SDL_RWscanf functionality.

  2. Implement an understanding of directories. The idea is directories
    could be opened as RWops and could be parsed specially to open other
    RWops for files and directories therein.

  3. Some sort of SDL_RWFromConfigFile(“basename”) function, which will
    open a text or binary config file with basename in the appropriate
    location on each OS. For example, this would open "~/.basenamerc"
    in *nix, or “C:/WHEREVER_SETTINGS_ARE/basename.cfg” (or whatever is
    deemed more appropriate) in Windows, etc…

  4. Combine #3 and #2 to open settings/cache directories to be used for
    local storage of per-user data, settings, etc…

Obviously, this would be aimed at SDL-1.3. My hope is to tackle most,
if not all, of these this summer when I will have a bit of time.

I think all of these are beyond the scope of SDL. When you really need a
complete platform for everything, you use a game engine, or a "fat"
library like PLIB or Allegro. I like SDL because it’s lightweight; if I
need anything else, I can use one of the many libraries built around
SDL, or even an independent one.
These functionalities may be useful, but I don’t think they need to be
part of the “core” library.

SG> (All this is IMHO, of course):

SG> That’s probably true of #1, and I’m happy to put it in another module
SG> (especially since SDL no longer depends on libc). It’s also not too
SG> bad to just use RWread/write and sprintf/sscanf to get the same
SG> effect.

SG> However, #2 - #4 are not particularly heavy and there is no way of doing
SG> them in a cross-platform way that I am aware of without depending on a
SG> library that is much heavier than should be required. This is my
SG> motivation (justification?) for wanting to add them to the core of SDL
SG> itself.

SG> Do you disagree with that?

Adding a system to obtain a path to per-user storage, for preferences,
savedgames etc, should be added. I currently do this for Windows, OS X
and Linux by hand, and the code is not that complicated to be honest.
Even just a function that returned the path to use that could be then
strcat()'d to would be useful.

Enumerating directories, again isn’t too hard to do but then most
compilers seem to have this one in their standard libraries.–
Best regards,
Peter mailto:@Peter_Mulholland

5

Adding a system to obtain a path to per-user storage, for preferences,
savedgames etc, should be added. I currently do this for Windows, OS X
and Linux by hand, and the code is not that complicated to be honest.
Even just a function that returned the path to use that could be then
strcat()'d to would be useful.

That would lack the flexibility I was looking for. For example, if it
were determined that the correct place to store preferences was in the
Windows registry or some zipfile somewhere, your simple path concept
wouldn’t work.

Enumerating directories, again isn’t too hard to do but then most
compilers seem to have this one in their standard libraries.

Assuming they are directories. My concept would make them generic so
any SDL app could be written to handle things that aren’t real
directories - such as directories within zipfiles or similar. Without
this in the base SDL_RWops, this feature would simply be impossible.On Sat, May 06, 2006 at 08:46:28AM +0100, Peter Mulholland wrote:

–
Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060506/b94b80a8/attachment.pgp

6

Hello Steaphan,

Saturday, May 6, 2006, 8:59:51 AM, you wrote:

SG> That would lack the flexibility I was looking for. For example, if it
SG> were determined that the correct place to store preferences was in the
SG> Windows registry or some zipfile somewhere, your simple path concept
SG> wouldn’t work.

Windows registry. Yuck. You can’t really abstract that into file
access anyway.

As for the path to inside a zip file, sure it would - just make the
code that parses the filenames understand:

mydata.zip/some/config/path/config.cfg

SG> Assuming they are directories. My concept would make them generic so
SG> any SDL app could be written to handle things that aren’t real
SG> directories - such as directories within zipfiles or similar. Without
SG> this in the base SDL_RWops, this feature would simply be impossible.

Well zip files do have directories of sorts so the dir enumeration
could return that. Generally you wouldn’t want to do that for
something inside a zipfile anyway. The only time i’ve ever used
enumerating a dir has been to generate a list of saved games in some
particular directory.–
Best regards,
Peter mailto:@Peter_Mulholland

7

Adding a system to obtain a path to per-user storage, for preferences,
savedgames etc, should be added. I currently do this for Windows, OS X
and Linux by hand, and the code is not that complicated to be honest.
Even just a function that returned the path to use that could be then
strcat()'d to would be useful.

That would lack the flexibility I was looking for. For example, if it
were determined that the correct place to store preferences was in the
Windows registry or some zipfile somewhere, your simple path concept
wouldn’t work.

Enumerating directories, again isn’t too hard to do but then most
compilers seem to have this one in their standard libraries.

Assuming they are directories. My concept would make them generic so
any SDL app could be written to handle things that aren’t real
directories - such as directories within zipfiles or similar. Without
this in the base SDL_RWops, this feature would simply be impossible.

Now this is starting to look more and more like PhysicsFS, atleast to me.
That begs the question: In what way (other than API) is your suggestion
diffrent and more light weight?On Sat, 6 May 2006, Steaphan Greene wrote:

8

My suggestion has no support whatsoever for zipfiles themselves. It
would only add the ability for functions that use generic SDL_RWops to
receive virtual directories and not just virtual files. The zipfile
support would still be in the en-user app (or in physicsfs, if that’s
what the user wanted to use).On Sat, May 06, 2006 at 01:14:22PM +0200, Mattias Karlsson wrote:

Now this is starting to look more and more like PhysicsFS, atleast to me.
That begs the question: In what way (other than API) is your suggestion
diffrent and more light weight?

–
Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060506/490c5d7e/attachment.pgp

9

SG> That would lack the flexibility I was looking for. For example, if it
SG> were determined that the correct place to store preferences was in the
SG> Windows registry or some zipfile somewhere, your simple path concept
SG> wouldn’t work.

Windows registry. Yuck. You can’t really abstract that into file
access anyway.

Yeah, it was just a random example of something that wasn’t a standard
file/directory. Who knows what M$ is going to come up with and require
in the future?

As for the path to inside a zip file, sure it would - just make the
code that parses the filenames understand:

mydata.zip/some/config/path/config.cfg

…but then SDL itself would internally have to count on this behavior
if it were to return this path, which would have to be standardized
(right now, for example, zziplib wouldn’t understand the above string).

Having it actually give you an abstracted SDL_RWops removes all of those
problems. It also adds the potential for much more features to be added
to various apps in a completely platform-independent way without any
major modifications to SDL itself. Internally SDL would only support
normal directories (just as it now only supports normal files and memory
buffers), but someone would be able to code an RWops struct that
supported something else.

Well zip files do have directories of sorts so the dir enumeration
could return that. Generally you wouldn’t want to do that for
something inside a zipfile anyway. The only time i’ve ever used
enumerating a dir has been to generate a list of saved games in some
particular directory.

Quake3 md3, quake4 md4, and Blizzard mdx model files are all actually
zipfiles with a list of files in them in various virtual directories.
Supporting these files in a cross-platform way is where I came to the
realization that SDL was missing this directory-abstraction support.

I certainly don’t require something like physicsfs, which is much too
extensive, but I otherwise have no way of writing a platform-independent
function that can take either a directory or a directory entry in a
zipfile without this additional support in SDL.

This is not to mention the case of writing a file-open or file-save
dialog in a platform independent way as well.On Sat, May 06, 2006 at 09:06:44AM +0100, Peter Mulholland wrote:

–
Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060506/c0ba24d7/attachment.pgp

10

Sounds to me like PhysicsFS is EXACTLY what you need. I’m not sure why
you’re saying it’s “much too extensive”. PhysicsFS doesn’t do much
else than what you are looking for.On 5/6/06, Steaphan Greene wrote:

I certainly don’t require something like physicsfs, which is much too
extensive, but I otherwise have no way of writing a platform-independent
function that can take either a directory or a directory entry in a
zipfile without this additional support in SDL.

–

  • SR
11

Sounds to me like PhysicsFS is EXACTLY what you need. I’m not sure why
you’re saying it’s “much too extensive”. PhysicsFS doesn’t do much
else than what you are looking for.

PhysicsFS does all of the following that doesn’t belong in the main SDL:

- Archive support
- Zipfile support
- PAK file support
- GRP file support
- HOG file support
- MVL file support
- WAD file support
- Search paths
- Filespace protection

PhysicsFS does not seem to have support for what I want to add:

- Abstraction of directories

From what I can tell (though, I have not used PhysicsFS yet, so please
correct me if I am wrong), what I am proposing is not actually supported
by PhysicsFS at all, and PhysicsFS does lots of stuff I am not
proposing. Perhaps I am just failing to be clear as to what I am
suggesting.

All I am talking about is the ability to create SDL_RWops that are
abstractions of directories as well as files, and use them to peruse
through virtual directories for virtual files, all as SDL_RWops. So, in
addition to being able to write a function that takes an SDL_RWops
structure to abstract a file, it could also be used to abstract a
directory.

That, and the ability to get a consistent and appropriate user-specific
(and perhaps global as well?) settings file and/or directory, I believe,
all belong in SDL itself.On Sat, May 06, 2006 at 03:37:51PM -0400, Simon Roby wrote:

–
Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060506/49e97e17/attachment.pgp

12

2006/5/6, Steaphan Greene :

All I am talking about is the ability to create SDL_RWops that are
abstractions of directories as well as files

SDL_RWops isn’t an abstraction for files, it’s an abstraction for I/O,
the same way C++ has streams.

I think you are taking SDL as a complete gaming platform. If it were
true, all the SDL_* libs would be merged into a single monolithic
library, like Allegro. Fortunately you don’t pay for what you don’t
use; if you want anything besides the basic multimedia handling that
SDL offers, you glue another library over it. That’s the way it always
worked, and I don’t see any reason to treat this specific
functionality as special, so that it would need to be merged inside
the core library. For example, text rendering is much more important
than directory handling, and it’s still provided by separated
libraries - that in turn use different approaches.

Why do you think you’ll have less overhead if the directory handling
is included inside SDL? And what about the people who don’t want to
use this otherwise unnecessary feature (becaue they either don’t need
it, or they already use another library)?

That, and the ability to get a consistent and appropriate user-specific
(and perhaps global as well?) settings file and/or directory, I believe,
all belong in SDL itself.
Somebody please correct me if the roadmap for SDL 1.3 includes
changing its meaning, but SDL stands for Simple DirectMedia Layer; it
doesn’t propose any solution for filesystem manipulation. I don’t
think this belongs to SDL at all, but for a ‘satelite’ library.

Anyways, the only one that can give the final word about it is Sam.
I’m among the ones that prefer SDL to remain as clean and reduced as
possible [*].—
Daniel K. O.

[*] I think that even text input (include the unicode mess) should go
to a separate library, for many reasons, but that it would be
off-topic.

13

While directory abstraction is useful, it’s definitely better done as a
separate library from SDL, and there are many of them already out there.

Strictly speaking SDL_RWops really should be a separate library, but it
was convenient to have an I/O abstraction for loading image and audio files
in the test programs (and games using SDL)

See ya!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

14

SDL_RWops isn’t an abstraction for files, it’s an abstraction for I/O,
the same way C++ has streams.

…which are abstractions of quantities of sequential data - or, in
layman’s terms, files. That’s what I meant.

I think you are taking SDL as a complete gaming platform. If it were
true, all the SDL_* libs would be merged into a single monolithic
library, like Allegro. Fortunately you don’t pay for what you don’t
use; if you want anything besides the basic multimedia handling that
SDL offers, you glue another library over it. That’s the way it always
worked, and I don’t see any reason to treat this specific
functionality as special, so that it would need to be merged inside
the core library.

Unfortunately, for it to be useful, just as SDL_RWops is at present, it
would need to be in the base library for other libraries to use it.
Also, from a design prespective, SDL_RWops is where this support would
belong. Are you suggesting I write a separate library that would
replace SDL_RWops with just the few additions I am proposing?

For example, text rendering is much more important than directory
handling, and it’s still provided by separated libraries - that in
turn use different approaches.

It’s also both platform independent (unlike directories) and much
heavier than this directory support would be. I’m basically talking
about a simple flag or two, a few more function pointers in SDL_RWops,
and a handful of simple additional functions that glue it to the
underlying dirent stuff.

Why do you think you’ll have less overhead if the directory handling
is included inside SDL?

I would certainly have less overhead than if I used physicsfs just to
peruse directories. There is also no good way I am aware to peruse
directories in any platform-independent way, and no way to take a
platform-independent directory argument without writing all this
platform-specific code myself, making my program stuck with working on
whatever systems I implement it for, rather than just depending on SDL
working on it.

And what about the people who don’t want to use this otherwise
unnecessary feature (becaue they either don’t need it, or they already
use another library)?

I wouldn’t be interfering with anything that already works, and would
not be adding any significant overhead to this existing API. And, do
you honestly feel that most games don’t require any saved settings?

Most SDL games I have seen either use a heavier library (which would
still be an option), or have had to include platform-specific code that
will find a config dir and save stuff to it. I’ve seen many an SDL app
for which this is the sole reason it only supports Windows. Kind of
defeats the point of SDL in my mind.

Somebody please correct me if the roadmap for SDL 1.3 includes
changing its meaning, but SDL stands for Simple DirectMedia Layer; it
doesn’t propose any solution for filesystem manipulation. I don’t
think this belongs to SDL at all, but for a ‘satelite’ library.

So, you favor removing the existing SDL_RWops from it? It can already
create new files and modify them, and is already in 1.2.

Anyways, the only one that can give the final word about it is Sam.
I’m among the ones that prefer SDL to remain as clean and reduced as
possible [*].

So am I, which is why I want this in there. It cleanly fits in
SDL_RWops as-is with very little internal changes and no significant
added overhead. It would be big gain for very little cost, and would
make platform-independent apps easier to write in SDL. It could
probably even allow PhysicsFS to be used more powerfully with any future
SDL_RWops directory-based implementations.On Sat, May 06, 2006 at 07:51:25PM -0300, Daniel K. O. wrote:

–
Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060506/76198a5f/attachment.pgp

15

While directory abstraction is useful, it’s definitely better done as a
separate library from SDL, and there are many of them already out there.

Strictly speaking SDL_RWops really should be a separate library, but it
was convenient to have an I/O abstraction for loading image and audio files
in the test programs (and games using SDL)

The directory abstraction I am discussing clearly belongs integrated
with SDL_RWops. Would you rather I put together a patch that extracts
SDL_RWops from SDL and makes it a separate SDL module? That would
certainly fit my needs as well if it were part of the SDL suite. The
problem with that is that RWops are used internally in SDL in several
places.

The fact that there are many libaries out there that can do parts of
what I am talking about is part of the problem. Any implementation of
some feature in the future is likely to be incompatable with any other
feature, as they will probably use different solutions. With a
standard, simple, lightweight SDL version of this, they would most
likely be intercompatable, which would make things much cleaner.

From a design standpoint: SDL provides abstractions to the video card,
audio card and various input devices. How is the filesystem less
elemental than that? Personally, I think SDL_RWops belongs in SDL
itself (though, perhaps with a cleaner name), and needs simple support
for more filesystem operations than just open, close, read and write.

Would I be wasting my time by writing a patch to do what I am discussing
for you to check out?On Sat, May 06, 2006 at 04:15:13PM -0700, Sam Lantinga wrote:

–
Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060506/d65fe268/attachment.pgp

16

2006/5/6, Steaphan Greene :

So, you favor removing the existing SDL_RWops from it? It can already
create new files and modify them, and is already in 1.2.

Now that you mention it (and that Sam already said it)… yes, I would
prefer it to be in a (hypothetical) “SDL_io” library. SDL_LoadBMP and
SDL_LoadWAV are useless when you have SDL_image and SDL_mixer. I don’t
know too much about the insides of SDL yet; does it have any other use
for SDL_RWops when you discard those WAV/BMP functions?—
Daniel K. O.

17

I’d agree that SDL_RWops should be a separate module, but no more so
than video, audio and input should be separate. The problem is,
separating these becomes just too complex. For example, the entire
audio system uses RWops internally so it doesn’t have to have everything
in memory, which is correct IMHO.

Filesystem access is a basic elemental function that is not truly
platform independent in C/C++, so, again IMHO, it belongs in SDL itself

  • unless the entire core of SDL is to be modularized. Even if it were
    to be modularized, the filesystem stuff would actually be one of the
    most basic prereqs of just about everything.On Sat, May 06, 2006 at 05:58:17PM -0700, Daniel K. O. wrote:

2006/5/6, Steaphan Greene :

So, you favor removing the existing SDL_RWops from it? It can already
create new files and modify them, and is already in 1.2.

Now that you mention it (and that Sam already said it)… yes, I would
prefer it to be in a (hypothetical) “SDL_io” library. SDL_LoadBMP and
SDL_LoadWAV are useless when you have SDL_image and SDL_mixer. I don’t
know too much about the insides of SDL yet; does it have any other use
for SDL_RWops when you discard those WAV/BMP functions?

–
Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060506/5621dd42/attachment.pgp

18

The directory abstraction I am discussing clearly belongs integrated
with SDL_RWops. Would you rather I put together a patch that extracts
SDL_RWops from SDL and makes it a separate SDL module? That would
certainly fit my needs as well if it were part of the SDL suite. The
problem with that is that RWops are used internally in SDL in several
places.

Your best bet is to extract SDL_RWops from SDL, integrate your directory
code, and then create a compatible library. If it’s lightweight enough,
it can get merged into SDL 1.3, and if not, you’ll have a useful library
that you can use with your own code and release separately if you like.

See ya!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

19

Ok. I’ll give that a shot in a few weeks when my time frees up a bit.On Sun, May 07, 2006 at 07:42:52AM -0700, Sam Lantinga wrote:

Your best bet is to extract SDL_RWops from SDL, integrate your directory
code, and then create a compatible library. If it’s lightweight enough,
it can get merged into SDL 1.3, and if not, you’ll have a useful library
that you can use with your own code and release separately if you like.

–
Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060507/151304a0/attachment.pgp

20

Sam Lantinga wrote:

Your best bet is to extract

SDL_RWops from SDL, integrate your

directory code, and then create a

compatible library. If it’s

lightweight enough, it can get

merged into SDL 1.3, and if not,

you’ll have a useful library that

you can use with your own code and

release separately if you like.

Directory browsing is different enough from file/IO abstraction that it shouldn’t be included into SDL_RWops. Rather, develope a library in the style of SDL_RWops for directories, and include a function ‘open file from directory’ that returns a SDL_RWop.

A good directory browsing abstraction would be welcomed, probably best as a SDL add on. I have a crude *nix and win32 abstraction module I could donate to the effort.