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.
There are cases where something is both a file and (virtually) a
directory (such as a zipfile, or tar stream, or similar). Separating
the two would be less useful than I am aiming for.
A good directory browsing abstraction would be welcomed, probably best
as a SDL add on.
I’d be worried if it were some outside library that it would just be one
of many and there would still be no standard way to use it. I look at
SDL as a good way to create free, cross-platform games, not just
commercial ones, and would love it if when anyone wrote free code to
handle some sort of file or directory, it would use the same scheme as
any other SDL app would use. SDL_RWops already handles this rather well
for files, I’d like to take it the rest of the way.
I have a crude *nix and win32 abstraction module I could donate to the
effort.
I’d certainly like to see what you have, provided you don’t mind it
being used as a reference for (or perhaps a component of) a GPL module,
or only LGPL if it became part of SDL itself.On Sun, May 07, 2006 at 01:32:58PM +0000, cal at splitreflection.com 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/20060507/92dd98db/attachment.pgp
Steaphan Greene escreveu:
-
Implement some kind of SDL_RWprintf/SDL_RWscanf functionality.
-
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.
-
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…
-
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.
(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?
I think you are missing the point of the RW ops. They are for
abstracting low level reading and writing to and from various sources.
Setting up the source is up to you.
I would be happy to see the functionality in #2 through #4 in a library
that is associated with SDL that can be built with SDL and make use of
the libc replacement and so on. But, that library is not related to
RWops and should not be part of RW ops. As i said before, RW ops is an
abstraction of reading and writing, where the objects you read and write
from come from is not part of the RW abstraction.
Bob PendletonOn Sat, 2006-05-06 at 00:51 -0400, Steaphan Greene wrote:
On Sat, May 06, 2006 at 01:38:05AM -0300, Daniel K. O. wrote:
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-------------------------------------+
I think you are missing the point of the RW ops. They are for
abstracting low level reading and writing to and from various sources.
Setting up the source is up to you.
No, I’m really not (though I do see what you are saying, and I think I
understand your concerns). I think I am just failing to explain what I
am proposing.
I will write up the code for my suggestion (as an external library) so
people will (hopefully) understand what I meant. I speak C much better
than I speak English. 
I would be happy to see the functionality in #2 through #4 in a
library that is associated with SDL that can be built with SDL and
make use of the libc replacement and so on. But, that library is not
related to RWops and should not be part of RW ops. As i said before,
RW ops is an abstraction of reading and writing, where the objects you
read and write from come from is not part of the RW abstraction.
Right. I am basically talking about abstracting “channels” of
information that can be “switched”, which could be directories, levels
of detail in a BLP, actual channels in an input device, etc… I will
write it up and see if you all still disagree with me.On Mon, May 08, 2006 at 01:57:12PM -0500, Bob Pendleton 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/20060508/5e07c3b0/attachment.pgp
Steaphan Greene wrote:
There are cases where something is both a file and (virtually) a
directory (such as a zipfile, or tar stream, or similar). Separating
the two would be less useful than I am aiming for.
Then the implimentation for that case has something like ‘open directory from zipfile’. This could have variations accepting a filename of a RWop. The private data for the directory abstraction would point to the file (or RWop) from which the data is read. The code then using the abstracted directory has no need to know it’s coming from a file and not a regular directory. Trying to cram directory functions into RWops would be an uncomfortable fit.
Then the implimentation for that case has something like ‘open
directory from zipfile’. This could have variations accepting a
filename of a RWop. The private data for the directory abstraction
would point to the file (or RWop) from which the data is read. The
code then using the abstracted directory has no need to know it’s
coming from a file and not a regular directory. Trying to cram
directory functions into RWops would be an uncomfortable fit.
Could be. I’m gonna stop trying to justify myself here and just
implement it and I’ll see how clean my concept really is. Maybe once I
go through the actual design process, I’ll come to the same conclusion
as the rest of you apparently have. I’ll post my results here when I
get there (in a few weeks, most likely).On Mon, May 08, 2006 at 08:06:22PM +0000, cal at splitreflection.com 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/20060508/62dfdfcc/attachment.pgp
Hi!
I just signed to this mailing list. Couldn’t wait more after reading this topic.
IMHO we need just take zziplib which has SDL_RWops support make it
compile correctly with latest Zlib and SDL - and that’s all!
The library is dead simple and does exactly what is needed - directory
abstraction! No more! No need to write something else or use bloated
(IMHO) PhysFS.
All please see here: http://zziplib.sourceforge.net/
and here: http://zziplib.sourceforge.net/zzip-sdl-rwops.html
I played with it last year and IMHO this is what really needed.
The only problems I had - compiling it from source under MinGW
(haven’t tried it on Linux yet).
No need to write something else or use bloated (IMHO) PhysFS.
Another satisfied customer.
–ryan.
Hello !
No need to write something else or use bloated (IMHO) PhysFS.
Another satisfied customer.
What i miss in PhysFS and in ZZipLib
is a good encryption method.
I want to protect the GFX, Music,
Level Data and so on. You can easily crack
the simple ZIP password scheme.
CU
What i miss in PhysFS and in ZZipLib
is a good encryption method.
I want to protect the GFX, Music,
Level Data and so on. You can easily crack
the simple ZIP password scheme.
I don’t see big problem here. You can easily add crypting function for
zziplib (there are XOR example on their site) using one of many crypto
libraries available. There are few small and simple such libraries.
But anyway this is not perfect protection, because you need to store
password somewhere in the game binaries, and some smart user could
find it.
IMHO it is enought to use plain simple and superfast XOR crypting as
foolproof method of hiding game data from user. Because encryption
method means nothing when the password could be found in binaries.
Ryan C. Gordon wrote:
No need to write something else or use bloated (IMHO) PhysFS.
Another satisfied customer.
–ryan.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
i like physfs. works like a charm. bloat? no. feature rich. but: maybe
you could make it more modular. i would wish that there were sort of
simple plugin mechanism so that one could ommit wad file and other
supported containers. if one simply needs zip, one should be able to use
some sort of “base physfs”. to keep the executable small and free of
unwanted stuff.
??? ??? wrote:
What i miss in PhysFS and in ZZipLib
is a good encryption method.
I want to protect the GFX, Music,
Level Data and so on. You can easily crack
the simple ZIP password scheme.
I don’t see big problem here. You can easily add crypting function for
zziplib (there are XOR example on their site) using one of many crypto
libraries available. There are few small and simple such libraries.
But anyway this is not perfect protection, because you need to store
password somewhere in the game binaries, and some smart user could
find it.
IMHO it is enought to use plain simple and superfast XOR crypting as
foolproof method of hiding game data from user. Because encryption
method means nothing when the password could be found in binaries.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
can agree to that: simple encryption to keep away “amateur” programmers
like me that collect good sounds and textures from other freeware games
but real protection? no way. a good hacker can always capture for
example textures directly by linking into the opengl drivers somehow or
grabbing sound directly from memory once decrypted… does one not only
needs to search memory for the wav header once soundfx is loaded?
Ryan C. Gordon wrote:
No need to write something else or use bloated (IMHO) PhysFS.
Another satisfied customer.
i like physfs. works like a charm. bloat? no. feature rich. but: maybe
you could make it more modular. i would wish that there were sort of
simple plugin mechanism so that one could ommit wad file and other
supported containers. if one simply needs zip, one should be able to use
some sort of “base physfs”. to keep the executable small and free of
unwanted stuff.
Hint: ./configure --helpOn Mon, 29 May 2006, Andre Krause wrote:
IMHO we need just take zziplib which has SDL_RWops support make it
compile correctly with latest Zlib and SDL - and that’s all! The
library is dead simple and does exactly what is needed - directory
abstraction! No more! No need to write something else or use bloated
(IMHO) PhysFS.
Zziplib is useful, though it has portability problems. However, this
was not what I was proposing. For example, if zziplib can peruse
directories for us, and let’s say, Ttarlib (fictional) can navigate tar
files and Rrarlib (also fictional) can navigate rar files, how can one
write something that needs several files that may be in directories, tar
files, rar files, or some future archive format without knowing how to
use each of these libraries?
All I was proposing was abstracting the directory so that zziplib and
others could provide a standard interface for navigating the directory
(or virtual directory) so software doesn’t need to be aware of zziplib
or anything else in order to write something that needs to navigate
through several files in a direcrory structure. Examples of
applications that could really use this kind of support include model
loaders/renderers and directory browsers.
However, I am not talking about implementing either of these
applications, or zipfile support, or anything else. Just the standard
abstraction of these directory-like structures to allow the versatile
communication of these things just as easilly as data streams are
communicated now using SDL_RWops.
I’ve repeatedly failed to explain this here, so I am just going to
implement my suggestion and see what people say.On Mon, May 29, 2006 at 11:36:36AM +0300, ??? ??? wrote:
–
Steaphan Greene
Lecturer, Computer Science, Binghamton University
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/20060531/59275ed6/attachment.pgp
However, I am not talking about implementing either of these
applications, or zipfile support, or anything else. Just the standard
abstraction of these directory-like structures to allow the versatile
communication of these things just as easilly as data streams are
communicated now using SDL_RWops.
I’ve repeatedly failed to explain this here, so I am just going to
implement my suggestion and see what people say.
OK, let’s see. The more choice - the better.
BTW, here are another directory abstraction library - give it a try.
Get navfs (and vartypes) from http://www.crusaderky.altervista.org/?s=downloads
OK, let’s see. The more choice - the better.
Actually, what I’m trying for is one clear common denomonator that all
can use to intercommunicate in all SDL apps, just like RWops for data
streams.
BTW, here are another directory abstraction library - give it a try.
Get navfs (and vartypes) from
http://www.crusaderky.altervista.org/?s=downloads
That is interesting, I was not aware of it.
It is still actually more comprehensive than I intend, and not as
flexible as I want (“it uses FILE* for transparency and MS Windows does
not allow use of FILE* other than for regular files”) - and it not
really suited for inclusion into SDL in its state, but that’s a handy
thing to know about, thanks! It will certainly be useful.On Thu, Jun 01, 2006 at 09:44:22AM +0300, ??? ??? wrote:
–
Steaphan Greene
Lecturer, Computer Science, Binghamton University
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/20060601/cbc798cb/attachment.pgp