gitea/SDL3_fork
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Sync SDL3 wiki -> header

Browse Source 
[ci skip]
This commit is contained in:
SDL Wiki Bot
2025-01-01 16:06:00 +00:00
parent 9fbc767d4f
commit 6d554a9ea3
1 changed files with 18 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
include/SDL3/SDL_storage.h
View File

@@ -34,16 +34,15 @@
* are usually two separate storage devices with entirely different * are usually two separate storage devices with entirely different
* characteristics (and possibly different low-level APIs altogether!). * characteristics (and possibly different low-level APIs altogether!).
* *
* 2. **How to Access:** Another common mistake is applications assuming that all * 2. **How to Access:** Another common mistake is applications assuming that
* storage is universally writeable - again, many platforms treat game content * all storage is universally writeable - again, many platforms treat game
* and user data as two separate storage devices, and only user data is * content and user data as two separate storage devices, and only user data
* writeable while game content is read-only. * is writeable while game content is read-only.
* *
* 3. **When to Access:** The most * 3. **When to Access:** The most common portability issue with filesystem
* common portability issue with filesystem access is _timing_ - you cannot * access is _timing_ - you cannot always assume that the storage device is
* always assume that the storage device is always accessible all of the time, * always accessible all of the time, nor can you assume that there are no
* nor can you assume that there are no limits to how long you have access to * limits to how long you have access to a particular device.
* a particular device.
* *
* Consider the following example: * Consider the following example:
* *
@@ -92,13 +91,13 @@
* and saves are all presumed to be in the current working directory (which * and saves are all presumed to be in the current working directory (which
* may or may not be the game's installation folder!). * may or may not be the game's installation folder!).
* *
* 2. **How to Access:** * 2. **How to Access:** This code assumes that content paths are writeable,
* This code assumes that content paths are writeable, and that save data is * and that save data is also writeable despite being in the same location as
* also writeable despite being in the same location as the game data. * the game data.
* *
* 3. **When to Access:** This code assumes that they can be called at any time, * 3. **When to Access:** This code assumes that they can be called at any
* since the filesystem is always accessible and has no limits on how long the * time, since the filesystem is always accessible and has no limits on how
* filesystem is being accessed. * long the filesystem is being accessed.
* *
* Due to these assumptions, the filesystem code is not portable and will fail * Due to these assumptions, the filesystem code is not portable and will fail
* under these common scenarios: * under these common scenarios:
@@ -200,12 +199,11 @@
* 1. **What to Access:** This code explicitly reads from a title or user * 1. **What to Access:** This code explicitly reads from a title or user
* storage device based on the context of the function. * storage device based on the context of the function.
* *
* 2. **How to Access:** This code explicitly uses either a read or write function based on the * 2. **How to Access:** This code explicitly uses either a read or write
* context of the function. * function based on the context of the function.
* *
* 3. **When to Access:** This code explicitly opens * 3. **When to Access:** This code explicitly opens the device when it needs
* the device when it needs to, and closes it when it is finished working with * to, and closes it when it is finished working with the filesystem.
* the filesystem.
* *
* The result is an application that is significantly more robust against the * The result is an application that is significantly more robust against the
* increasing demands of platforms and their filesystems! * increasing demands of platforms and their filesystems!