The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

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

PhysFS can do the job and should work in compressed format.

2014-02-28 17:56 GMT+01:00 vlag:



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:

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 directories On Feb 28, 2014 4:47 PM, "Michael Labbé" 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:

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.

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:

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:

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:

What would would be required of the person that maintains the new SDL files library?