CodeSpell

docs/INTRO-xcode.md

@@ -11,6 +11,6 @@ We'll start by creating a simple project to build and run [hello.c](hello.c)
 - On iOS projects, select the project, select the main target, select the Info tab, look for "Custom iOS Target Properties", and remove "Main storyboard base file name" and "Application Scene Manifest"
 - Right click the project and select "Add Files to [project]", navigate to the SDL docs directory and add the file hello.c
 - Right click the project and select "Add Files to [project]", navigate to the SDL Xcode/SDL directory and add SDL.xcodeproj
-- Select the project, select the main target, select the General tab, look for "Frameworks, Libaries, and Embedded Content", and add SDL3.framework
+- Select the project, select the main target, select the General tab, look for "Frameworks, Libraries, and Embedded Content", and add SDL3.framework
 - Build and run!
 

docs/README-android.md

@@ -76,7 +76,7 @@ For more complex projects, follow these instructions:
 
    The 'android-project' directory can basically be seen as a sort of starting point for the android-port of your project. It contains the glue code between the Android Java 'frontend' and the SDL code 'backend'. It also contains some standard behaviour, like how events should be handled, which you will be able to change.
 
-2. If you are _not_ already building SDL as a part of your project (e.g. via CMake add_subdirectory() or FetchContent) move or [symlink](https://en.wikipedia.org/wiki/Symbolic_link) the SDL directory into the 'android-project/app/jni' directory. Alternatively you can [use the SDL3 Android Archive (.aar)](#using-the-sdl3-android-archive-aar), see bellow for more details.
+2. If you are _not_ already building SDL as a part of your project (e.g. via CMake add_subdirectory() or FetchContent) move or [symlink](https://en.wikipedia.org/wiki/Symbolic_link) the SDL directory into the 'android-project/app/jni' directory. Alternatively you can [use the SDL3 Android Archive (.aar)](#using-the-sdl3-android-archive-aar), see below for more details.
 
     This is needed as SDL has to be compiled by the Android compiler.
 

docs/README-emscripten.md

@@ -224,7 +224,7 @@ If you're using the SDL main callbacks, the mainloop defaults to using
 requestAnimationFrame (effectively vsync), because it calls
 emscripten_set_main_loop() with a zero fps. This is almost certainly what you
 want to do! Do this even if you aren't using the main callbacks!
-SDL will attempt to accomodate the app if it messes with vsync settings, or
+SDL will attempt to accommodate the app if it messes with vsync settings, or
 doesn't use requestAnimationFrame, but modern thinking is that this is the
 most efficient, consistent, and correct way to run a game in a web browser.
 

docs/README-migration.md

@@ -173,7 +173,7 @@ If you used SDL_QueueAudio instead of a callback in SDL2, this is also straightf
 
 SDL_AudioInit() and SDL_AudioQuit() have been removed. Instead you can call SDL_InitSubSystem() and SDL_QuitSubSystem() with SDL_INIT_AUDIO, which will properly refcount the subsystems. You can choose a specific audio driver using SDL_AUDIO_DRIVER hint.
 
-The `SDL_AUDIO_ALLOW_*` symbols have been removed; now one may request the format they desire from the audio device, but ultimately SDL_AudioStream will manage the difference. One can use SDL_GetAudioDeviceFormat() to see what the final format is, if any "allowed" changes should be accomodated by the app.
+The `SDL_AUDIO_ALLOW_*` symbols have been removed; now one may request the format they desire from the audio device, but ultimately SDL_AudioStream will manage the difference. One can use SDL_GetAudioDeviceFormat() to see what the final format is, if any "allowed" changes should be accommodated by the app.
 
 SDL_AudioDeviceID now represents both an open audio device's handle (a "logical" device) and the instance ID that the hardware owns as long as it exists on the system (a "physical" device). The separation between device instances and device indexes is gone, and logical and physical devices are almost entirely interchangeable at the API level.
 
@@ -273,7 +273,7 @@ If you need to convert U16 audio data to a still-supported format at runtime, th
     }
 ```
 
-All remaining `AUDIO_*` symbols have been renamed to `SDL_AUDIO_*` for API consistency, but othewise are identical in value and usage.
+All remaining `AUDIO_*` symbols have been renamed to `SDL_AUDIO_*` for API consistency, but otherwise are identical in value and usage.
 
 In SDL2, SDL_AudioStream would convert/resample audio data during input (via SDL_AudioStreamPut). In SDL3, it does this work when requesting audio (via SDL_GetAudioStreamData, which would have been SDL_AudioStreamGet in SDL2). The way you use an AudioStream is roughly the same, just be aware that the workload moved to a different phase.
 

docs/README-wayland.md

@@ -68,7 +68,7 @@ encounter limitations or behavior that is different from other windowing systems
 
 ### The application progress bar can't be set via ```SDL_SetWindowProgressState()``` or ```SDL_SetWindowProgressValue()```
 
-- Only some Desktop Environemnts support the underlying API. Known compatible DEs: Unity, KDE
+- Only some Desktop Environments support the underlying API. Known compatible DEs: Unity, KDE
 - The underlying API requires a desktop entry file, aka a `.desktop` file.
   Please see the [Desktop Entry Specification](https://specifications.freedesktop.org/desktop-entry-spec/latest/) for
   more information on the format of this file. Note that if your application manually sets the application ID via the

docs/doxyfile

@@ -290,10 +290,10 @@ TYPEDEF_HIDES_STRUCT   = YES
 # For small to medium size projects (<1000 input files) the default value is 
 # probably good enough. For larger projects a too small cache size can cause 
 # doxygen to be busy swapping symbols to and from disk most of the time 
-# causing a significant performance penality. 
+# causing a significant performance penalty. 
 # If the system has enough physical memory increasing the cache will improve the 
 # performance by keeping more symbols in memory. Note that the value works on 
-# a logarithmic scale so increasing the size by one will rougly double the 
+# a logarithmic scale so increasing the size by one will roughly double the 
 # memory usage. The cache size is given by this formula: 
 # 2^(16+SYMBOL_CACHE_SIZE). The valid range is 0..9, the default is 0, 
 # corresponding to a cache size of 2^16 = 65536 symbols