-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SDL3 Filesystem Subsystem wishlist #6644
Comments
Not a wishlist item, but an old issue: Especially now that |
I've reopened it so we don't forget. |
Wel, closed it again. It really looks like a non-issue today. |
Possible wishlist: Maybe a callback based RW with user-supplied read, seek, tell, etc function pointers? If that'd be interesting for many, of course. |
The intent is for you to just be able to instantiate your own SDL_rwops object, fill in the pointers, and pass it to any API that uses SDL_rwops. That's why the structure definition is public. |
OK |
any chance we can get query functions for user media directories (ie ~/music/) too while we're at it? |
Working with GDK storage this week and it turns out what they have for save storage is still pretty much what XNA's looked like, so will post it here since I will likely be making something very similar to this: |
Started up a separate bug for concrete API discussion in #8129. |
This happened in #7654. |
I don't know how much interest there would be in practice, but Apple has their own cloud save API: https://developer.apple.com/documentation/gamekit/saving_the_player_s_game_data_to_an_icloud_account Notably, this is AFAIK the only reasonable way to store save data on tvOS (since persistent storage on the local filesystem isn't available there). |
The beginnings of SDL_Storage are now in main - this would be my checklist for calling this done:
We pretty much already have Switch working, just need to migrate our current system to this API. We should probably check PlayStation as well but that can probably come later. |
It seems like the GameKit cloud save API is inexplicably unavailable on tvOS, despite the rest of GameKit and CloudKit both being available. I must have missed that when I posted about it before. I'm not sure what would be reasonable to do for tvOS because of this. This is despite Apple claiming that Apple Arcade games on tvOS have their saves synced via Game Center. I'm very confused on what they're expecting developers to do here....? |
Just consolidating back down to one issue. @flibitijibibo said this:
And @TylerGlaiel mentioned this:
I think everything else from #8129 was resolved in some way or another. |
@flibitijibibo, is there anything that might change the ABI for this at this point? |
Nothing other than a PlayStation implementation, aside from that all my remaining items are additions like async support so this should be safe to lock down. |
Would the additions require changes to SDL_StorageInterface? |
Oh, right, we have the public vtable - yes, that would be a breakage. I'm currently trapped in GPU land so I won't be able to figure out async support; did we ever make async I/O for the low level filesystem? |
We didn't. @icculus, do you want to share the details? |
So I intended to make this grand and glorious design that just made all SDL_IOStreams (SDL_RWops) async, faking it with a thread behind the scenes when there wasn't a platform API that handled it, and that was a mess for several reasons. Now I'm thinking of a very small interface that is completely unrelated to SDL_IOStream that only handles async i/o. The Windows version will use "overlapped" i/o internally with it, etc. The problem at the moment, beyond this code not yet existing, is the obvious need for SDL_Storage to offer it, since there will certainly be a cloud API somewhere that benefits from it, even if basic file i/o doesn't improve. But this needs an addition to the vtable. I'm inclined to add a |
Do we want several reserved function pointers? How do we guarantee the table is zeroed in the API usage? |
So the idea is when we add/change stuff (RARELY), we just make a version 2 of the struct and a new entry point that knows about the new thing, and change the old entry point to provide reasonable defaults for the stuff that wasn't in version 1, before passing it on to version 2. I'd just rather our first change post-3.2.0 not be to make a version 2 of the table. :)
Dereference the reserved pointer if it isn't NULL. :) This is all a terrible idea, let's just try to get this into 3.2.0 instead, even if the async interface just always returns -1 immediately for now. |
Originally posted by @flibitijibibo in #3519 (comment)
The text was updated successfully, but these errors were encountered: