It would be very nice to have this functions besides that we already have
in SDL_RWops
Why not use boost?
Also, while we’re at it, why not also have a function to get all files in a
directory?On 28 February 2014 18:31, Alexey Petruchik <alexey.petruchik at gmail.com>wrote:
It would be very nice to have this functions besides that we already have
in SDL_RWops
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
The main advantage of using SDL is that boost won?t work in compressed formats like Android?s apk. File exists is pretty easy to build on the application side though.On Friday, 28 February 2014 at 16:34, Ivan Rubinson wrote:
Why not use boost?
Also, while we’re at it, why not also have a function to get all files in a directory?
On 28 February 2014 18:31, Alexey Petruchik <alexey.petruchik at gmail.com (mailto:alexey.petruchik at gmail.com)> wrote:
It would be very nice to have this functions besides that we already have in SDL_RWops
SDL mailing list
SDL at lists.libsdl.org (mailto:SDL at lists.libsdl.org)
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org (mailto:SDL at lists.libsdl.org)
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
PhysFS can do the job and should work in compressed format. 
2014-02-28 17:56 GMT+01:00 vlag <valentin.soudier at gmail.com>:
PhysFS can do the job and should work in compressed format. [image:
Smile]
PhysFS is a bit limited in terms of writing though; you decide on one write
path and all files opened for writing go relative to there.
Along the way, in my engine, editor and autoupdate patcher, I?ve had to write a lot of cross platform code that works with directories. Some of the stuff I use frequently:
isdir
mkdir / rmdir
appendpath (similar to the Cocoa append path, that guarantees exactly one trailing slash)
opendir / readdir / closedir (capable of recursively iterating through a tree)
getcwd
removefile
Nearly every one of these calls for #ifdefs and different implementations on different platforms.
I would be happy to contribute them back to SDL if there is an appetite for these things. I can either give them as-is (heavily tested code) or schedule some time in late April to make them idiomatic to SDL.
Thoughts from maintainers?
Michael Labb?On Feb 28, 2014, at 8:36 AM, Gorm Lai wrote:
The main advantage of using SDL is that boost won?t work in compressed formats like Android?s apk. File exists is pretty easy to build on the application side though.
On Friday, 28 February 2014 at 16:34, Ivan Rubinson wrote:
Why not use boost?
Also, while we’re at it, why not also have a function to get all files in a directory?
On 28 February 2014 18:31, Alexey Petruchik <alexey.petruchik at gmail.com> wrote:
It would be very nice to have this functions besides that we already have in SDL_RWops
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I want it! I want it real bad 
that’s exactly what I’m trying to
accomplish, and on Windows I need to install the redistributable or I won’t
be able to do anything with directoriesOn Feb 28, 2014 4:47 PM, “Michael Labb?” wrote:
Along the way, in my engine, editor and autoupdate patcher, I’ve had to
write a lot of cross platform code that works with directories. Some of
the stuff I use frequently:isdir
mkdir / rmdir
appendpath (similar to the Cocoa append path, that guarantees exactly one
trailing slash)
opendir / readdir / closedir (capable of recursively iterating through a
tree)
getcwd
removefileNearly every one of these calls for #ifdefs and different implementations
on different platforms.I would be happy to contribute them back to SDL if there is an appetite
for these things. I can either give them as-is (heavily tested code) or
schedule some time in late April to make them idiomatic to SDL.Thoughts from maintainers?
Michael Labb?
On Feb 28, 2014, at 8:36 AM, Gorm Lai wrote:
The main advantage of using SDL is that boost won’t work in compressed
formats like Android’s apk. File exists is pretty easy to build on the
application side though.On Friday, 28 February 2014 at 16:34, Ivan Rubinson wrote:
Why not use boost?
Also, while we’re at it, why not also have a function to get all files in
a directory?On 28 February 2014 18:31, Alexey Petruchik <alexey.petruchik at gmail.com>wrote:
It would be very nice to have this functions besides that we already have
in SDL_RWops
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I do not believe that this kinda of API would be a good fit for core SDL. There is a ?large? can of worms and complexity involved when you start writing a file system API. Things like drive letters, directory separators, unicode handling, etc… the SDL RWOPS is designed to be very simple and ?dumb? in that it only works on opened files. Yes there are a few wrappers to use the standard C fopen to open files, but those do not handle unicode cleanly on some platforms (I?m looking a Win32 here )…
PhysFS definitely handles the focus of filesystem access around games very well and handles the issues of where you can write, dir slashes, drive letters, and unicode very well via the sandbox model which works GREAT for games!
boost::filesystem handles that in a non-sandbox solution to the issue and you CAN use the boost::iostreams around boost::filesystem or against any other type of file storage (such as your compress Android APK )… I?ve done this before and it?s not that difficult… I actually wrote a iostream filter that takes the text output of ngrep (network grep) and converts it back into a binary stream for an application to consume and process.
Now, if someone want?s to make a general file system API that cleanly handles the drive letters, unicode, and dir separators, case-sensitivity etc… IT could definitely be offered as a library that works with SDL like so many others are.On Feb 28, 2014, at 7:26 PM, R Manard wrote:
I want it! I want it real bad
On Feb 28, 2014 4:47 PM, “Michael Labb?” wrote:
Along the way, in my engine, editor and autoupdate patcher, I?ve had to write a lot of cross platform code that works with directories. Some of the stuff I use frequently:isdir
mkdir / rmdir
appendpath (similar to the Cocoa append path, that guarantees exactly one trailing slash)
opendir / readdir / closedir (capable of recursively iterating through a tree)
getcwd
removefileNearly every one of these calls for #ifdefs and different implementations on different platforms.
I would be happy to contribute them back to SDL if there is an appetite for these things. I can either give them as-is (heavily tested code) or schedule some time in late April to make them idiomatic to SDL.
Thoughts from maintainers?
Michael Labb?
On Feb 28, 2014, at 8:36 AM, Gorm Lai wrote:
The main advantage of using SDL is that boost won?t work in compressed formats like Android?s apk. File exists is pretty easy to build on the application side though.
On Friday, 28 February 2014 at 16:34, Ivan Rubinson wrote:
Why not use boost?
Also, while we’re at it, why not also have a function to get all files in a directory?
On 28 February 2014 18:31, Alexey Petruchik <alexey.petruchik at gmail.com> wrote:
It would be very nice to have this functions besides that we already have in SDL_RWops
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL_RWops doesn’t only work on opened files; it’s a generic stream interface hat can work on any streamable data, no matter what its source is.
MasonOn Saturday, March 1, 2014 2:42 PM, Edward Rudd wrote:
the SDL RWOPS is designed to be very simple and ?dumb? in that it only works on opened files.
Correct, and that source has to be already ?opened?, as it only supports read, write, seek, tell, and close…On Mar 1, 2014, at 8:35 PM, Mason Wheeler wrote:
SDL_RWops doesn’t only work on opened files; it’s a generic stream interface hat can work on any streamable data, no matter what its source is.
Mason
On Saturday, March 1, 2014 2:42 PM, Edward Rudd <@Edward_Rudd> wrote:
the SDL RWOPS is designed to be very simple and ?dumb? in that it only works on opened files.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
You missed a few macros that are implemented in terms of those functions. Basically it provides the fstream interface for files or for anything else that can be implemented in those terms. Memory, zip or other archives, TCP streams? all have been done.
JosephSent via mobile
On Mar 1, 2014, at 17:51, Edward Rudd wrote:
Correct, and that source has to be already ?opened?, as it only supports read, write, seek, tell, and close…
On Mar 1, 2014, at 8:35 PM, Mason Wheeler wrote:
SDL_RWops doesn’t only work on opened files; it’s a generic stream interface hat can work on any streamable data, no matter what its source is.
Mason
On Saturday, March 1, 2014 2:42 PM, Edward Rudd wrote:
the SDL RWOPS is designed to be very simple and ?dumb? in that it only works on opened files.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
My original question was: is there an appetite? Three people have emailed me, asking for the code off-list. FYI ? people want this.
I don?t have the time to parcel out useful bits of my engine into separate libraries, unfortunately. Perhaps it will make sense for me to open source it in the future.
If someone else would like to come forward and maintain such a library under similar licensing to SDL, I?d be happy to send them the code as a starting point.
Michael Labb?On Mar 1, 2014, at 2:42 PM, Edward Rudd wrote:
I do not believe that this kinda of API would be a good fit for core SDL. There is a ?large? can of worms and complexity involved when you start writing a file system API. Things like drive letters, directory separators, unicode handling, etc… the SDL RWOPS is designed to be very simple and ?dumb? in that it only works on opened files. Yes there are a few wrappers to use the standard C fopen to open files, but those do not handle unicode cleanly on some platforms (I?m looking a Win32 here
PhysFS definitely handles the focus of filesystem access around games very well and handles the issues of where you can write, dir slashes, drive letters, and unicode very well via the sandbox model which works GREAT for games!
boost::filesystem handles that in a non-sandbox solution to the issue and you CAN use the boost::iostreams around boost::filesystem or against any other type of file storage (such as your compress Android APK )… I?ve done this before and it?s not that difficult… I actually wrote a iostream filter that takes the text output of ngrep (network grep) and converts it back into a binary stream for an application to consume and process.
Now, if someone want?s to make a general file system API that cleanly handles the drive letters, unicode, and dir separators, case-sensitivity etc… IT could definitely be offered as a library that works with SDL like so many others are.
On Feb 28, 2014, at 7:26 PM, R Manard wrote:
I want it! I want it real bad
On Feb 28, 2014 4:47 PM, “Michael Labb?” <@Michael_Labbe> wrote:
Along the way, in my engine, editor and autoupdate patcher, I?ve had to write a lot of cross platform code that works with directories. Some of the stuff I use frequently:isdir
mkdir / rmdir
appendpath (similar to the Cocoa append path, that guarantees exactly one trailing slash)
opendir / readdir / closedir (capable of recursively iterating through a tree)
getcwd
removefileNearly every one of these calls for #ifdefs and different implementations on different platforms.
I would be happy to contribute them back to SDL if there is an appetite for these things. I can either give them as-is (heavily tested code) or schedule some time in late April to make them idiomatic to SDL.
Thoughts from maintainers?
Michael Labb?
On Feb 28, 2014, at 8:36 AM, Gorm Lai wrote:
The main advantage of using SDL is that boost won?t work in compressed formats like Android?s apk. File exists is pretty easy to build on the application side though.
On Friday, 28 February 2014 at 16:34, Ivan Rubinson wrote:
Why not use boost?
Also, while we’re at it, why not also have a function to get all files in a directory?
On 28 February 2014 18:31, Alexey Petruchik <alexey.petruchik at gmail.com> wrote:
It would be very nice to have this functions besides that we already have in SDL_RWops
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
What would would be required of the person that maintains the new SDL files
library?