Show Posts
1
General discussions / Re: PhysicsFS vs an SFML virtual filesystem
« on: January 18, 2019, 09:02:22 pm »
Thanks eXpl0it3r, it was definitely way off-topic. There's a typo in the title though 
FRex, I would argue that SFML is in many ways an abstraction over several other C libraries, providing a cohesive interface into their disparate functions in a way that enables them to easily work together. I don't see the issue with even considering adding PhysicsFS, or a virtual filesystem more generally, to the collection of functionalities that SFML abstracts.
And I hadn't thought of reading different formats with endianness expectations. I was mainly considering serialization for your own data. In this use case, you only ever want or need to read and write one endianness, regardless of the endianness of the native system. So for serializing your own data, it's a huge benefit to set that in one place and have it automated for all reads and writes. Most other data formats you're reading and writing are already handled by SFML already, so I would suggest there's fairly limited utility in broader endian support. A VirtualFile class could easily pass a real filesystem path to SFML's reading/writing utilities in order to handle those resources. Or they could be integrated in the VirtualFile class so you don't need to pass them from one class to another yourself. Such as:
However, in the case of reading disparate formats that have endianness requirements, I agree that it would have to handle endianness on a file by file basis. In this case, I would suggest using functions in the VirtualFilesystem class, such as OpenFile (for native endianness), OpenFileBig, and OpenFileLittle.
I still think this would be a big improvement over PhysicsFS's functions.
And a virtual filesystem is really a very simple piece of code to write. I've written my own before because I didn't want to deal with PhysicsFS's particulars, and it's about as much work to wrap (usefully, not just a thin wrapper) it as it is to just write your own. So it would be relatively easy for SFML to provide one that's better integrated with other SFML components.
And just to take a moment to address some of the more personal attacks:
It might be helpful to reread what I've actually said, and notice that much of what you accuse me of did not come from what I wrote, but rather what you've inferred far beyond my own words.
For instance, I never said sf::Vector2 was being removed, I said that it's not out of the question to replace SFML types and utilities that are better handled with standards-based analogues, and pointed out that there has been discussion and agreement towards this end with other pieces of SFML.
There are other examples of words being put in my mouth in this way, but I really think it's beside the point of this discussion to go further into that.
FRex, I would argue that SFML is in many ways an abstraction over several other C libraries, providing a cohesive interface into their disparate functions in a way that enables them to easily work together. I don't see the issue with even considering adding PhysicsFS, or a virtual filesystem more generally, to the collection of functionalities that SFML abstracts.
And I hadn't thought of reading different formats with endianness expectations. I was mainly considering serialization for your own data. In this use case, you only ever want or need to read and write one endianness, regardless of the endianness of the native system. So for serializing your own data, it's a huge benefit to set that in one place and have it automated for all reads and writes. Most other data formats you're reading and writing are already handled by SFML already, so I would suggest there's fairly limited utility in broader endian support. A VirtualFile class could easily pass a real filesystem path to SFML's reading/writing utilities in order to handle those resources. Or they could be integrated in the VirtualFile class so you don't need to pass them from one class to another yourself. Such as:
auto file = filesystem.GetFile("file/path/here.ext");
sf::Texture texture = file.ReadTexture();
sf::Texture texture = file.ReadTexture();
However, in the case of reading disparate formats that have endianness requirements, I agree that it would have to handle endianness on a file by file basis. In this case, I would suggest using functions in the VirtualFilesystem class, such as OpenFile (for native endianness), OpenFileBig, and OpenFileLittle.
I still think this would be a big improvement over PhysicsFS's functions.
And a virtual filesystem is really a very simple piece of code to write. I've written my own before because I didn't want to deal with PhysicsFS's particulars, and it's about as much work to wrap (usefully, not just a thin wrapper) it as it is to just write your own. So it would be relatively easy for SFML to provide one that's better integrated with other SFML components.
And just to take a moment to address some of the more personal attacks:
It might be helpful to reread what I've actually said, and notice that much of what you accuse me of did not come from what I wrote, but rather what you've inferred far beyond my own words.
For instance, I never said sf::Vector2 was being removed, I said that it's not out of the question to replace SFML types and utilities that are better handled with standards-based analogues, and pointed out that there has been discussion and agreement towards this end with other pieces of SFML.
There are other examples of words being put in my mouth in this way, but I really think it's beside the point of this discussion to go further into that.