sdl2-compat: Removed some sdl12-compat things I'd forgotten to delete.

From a9bf3d25223a2e6589355d843848e08097cd342b Mon Sep 17 00:00:00 2001
From: "Ryan C. Gordon" <[EMAIL REDACTED]>
Date: Tue, 22 Nov 2022 15:39:19 -0500
Subject: [PATCH] Removed some sdl12-compat things I'd forgotten to

--- | 151 +++++-------------------------------------------------
 1 file changed, 12 insertions(+), 139 deletions(-)

diff --git a/ b/
index 6048ce0..e6bed2e 100644
--- a/
+++ b/
@@ -39,14 +39,14 @@ them.
 These are quick-start instructions; there isn't anything out of the ordinary
 here if you're used to using CMake. 
-You'll need to use CMake to build sdl12-compat. Download at
+You'll need to use CMake to build sdl2-compat. Download at
 []( or install from your package manager
 (`sudo apt-get install cmake` on Ubuntu, etc).
 Please refer to the [CMake documentation](
 for complete details, as platform and build tool details vary.
-You'll need a copy of SDL3 to build sdl12-compat, because we need the
+You'll need a copy of SDL3 to build sdl2-compat, because we need the
 SDL3 headers. You can build this from source or install from a package
 manager. Windows and Mac users can download prebuilt binaries from
 [SDL's download page](; make sure you
@@ -70,7 +70,7 @@ cmake --build build

On Windows or macOS, you might prefer to use CMake’s GUI, but it’s the same
-idea: give it the directory where sdl12-compat is located, click “Configure,”
+idea: give it the directory where sdl2-compat is located, click “Configure,”
choose your favorite compiler, then click “Generate.” Now you have project
files! Click “Open Project” to launch your development environment. Then you
can build however you like with Visual Studio, Xcode, etc.
@@ -118,12 +118,7 @@ cmake --build build32

macOS users can try adding -DCMAKE_OSX_ARCHITECTURES='arm64;x86_64' instead
of -DCMAKE_C_FLAGS=-m32 to make a Universal Binary for both 64-bit Intel and
-Apple Silicon machines. If you have an older (or much older!) version of Xcode,
-you can try to build with “i386” or maybe even “powerpc” for 32-bit Intel or
-PowerPC systems, but Xcode (and macOS itself) has not supported either of
-these for quite some time, and you will likely struggle to get SDL2 to compile
-here in small ways, as well…but with some effort, it’s maybe possible to
-run SDL2 and sdl12-compat on Apple’s abandoned architectures.
+Apple Silicon machines.

Building for older CPU architectures on Windows:

@@ -134,169 +129,47 @@ CMake, when it asks you what compiler to target in the CMake GUI.

Configuration options:

-sdl12-compat has a number of configuration options which can be used to work
+sdl2-compat has a number of configuration options which can be used to work
around issues with individual applications, or to better fit your system or

These options are all specified as environment variables, and can be set by
running your application with them set on the command-line, for example:


will run %command% with high-dpi monitor support enabled, but OpenGL
scaling support disabled.

(While these environment variables are checked at various times throughout
-the lifetime of the app, sdl12-compat expects these to be set before the
+the lifetime of the app, sdl2-compat expects these to be set before the
process starts and not change during the life of the process, and any
places where changing it later might affect operation is purely accidental
-and might change. That is to say: don’t write an SDL 1.2-based app with
+and might change. That is to say: don’t write an SDL2-based app with
plans to tweak these values on the fly!)

The available options are:

– SDL12COMPAT_DEBUG_LOGGING: (checked at startup)
± SDL2COMPAT_DEBUG_LOGGING: (checked at startup)
If enabled, print debugging messages to stderr. These messages are
mostly useful to developers, or when trying to track down a specific

– SDL12COMPAT_FAKE_CDROM_PATH: (checked during SDL_Init)

  • A path to a directory containing MP3 files (named trackXX.mp3, where
  • XX is a two-digit track number) to be used by applications which play
  • CD audio. Using an absolute path is recommended: relative paths are
  • not guaranteed to work correctly.

– SDL12COMPAT_OPENGL_SCALING: (checked during SDL_Init)

  • Enables scaling of OpenGL applications to the current desktop resolution.
  • If disabled, applications can change the real screen resolution. This
  • option is enabled by default, but not all applications are compatible
  • with it: try changing this if you can only see a black screen.

– SDL12COMPAT_FIX_BORDERLESS_FS_WIN: (checked during SDL_SetVideoMode)

  • Enables turning borderless windows at the desktop resolution into actual
  • fullscreen windows (so they’ll go into a separate space on macOS and
  • properly hide dock windows on other desktop environments, etc).
  • If disabled, applications may not get the full display to theirselves as
  • they expect. This option is enabled by default, but this option is here
  • so it can be manually disabled, in case this causes some negative result
  • we haven’t anticipated.

– SDL12COMPAT_SCALE_METHOD: (checked during SDL_Init)

  • Choose the scaling method used when applications render at a non-native
  • resolution. The options are nearest, for nearest-neighbour sampling
  • (more pixelated) and linear for bilinear sampling (blurrier).

– SDL12COMPAT_HIGHDPI: (checked during SDL_SetVideoMode)

  • Advertise the application as supporting high-DPI displays. Enabling
  • this will usually result in sharper graphics, but on some applications
  • text and other elements may become very small.

– SDL12COMPAT_SYNC_TO_VBLANK: (checked during SDL_SetVideoMode)

  • Force the application to sync (or not sync) to the vertical blanking
  • interval (VSync). When enabled, this will cap the application’s
  • framerate to the screen’s refresh rate (and may resolve issues with
  • screen tearing).

– SDL12COMPAT_USE_KEYBOARD_LAYOUT: (checked during SDL_Init)

  • Make all keyboard input take the current keyboard layout into account.
  • This may need to be disabled for applications which provide their own
  • keyboard layout support, or if the position of the keys on the keyboard
  • is more important than the character they produce. Note that text input
  • (in most applications) will take the keyboard layout into account
  • regardless of this option.


  • Use SDL2’s higher-level Game Controller API to expose joysticks instead of
  • its lower-level joystick API. The benefit of this is that you can exert
  • more control over arbitrary hardware (deadzones, button mapping, device
  • name, etc), and button and axes layouts are consistent (what is physically
  • located where an Xbox360’s “A” button is will always be SDL 1.2 joystick
  • button 0, “B” will be 1, etc). The downside is it might not expose all of
  • a given piece of hardware’s functionality, or simply not make sense in
  • general…if you need to use a flight stick, for example, you should not
  • use this hint. If there is no known game controller mapping for a joystick,
  • and this hint is in use, it will not be listed as an availble device.

– SDL12COMPAT_WINDOW_SCALING: (checked during SDL_SetVideoMode)

  • When creating non-fullscreen, non-resizable windows, use this variable to
  • size the window differently. If, for example, you have a 4K monitor and the
  • game is running in a window the size of a postage stamp, you might set this
  • to 2 to double the size of the window. Fractional values work, so “1.5”
  • might be a more-pleasing value on your hardware. You can even shrink the
  • window with values less than 1.0! When scaling a window like this,
  • sdl12-compat will use all the usual scaling options
  • can’t scale the contents of the window for various technical reasons, it
  • will create the window at the originally-requested size. If this variable
  • isn’t specified, it defaults to 1.0 (no scaling).

– SDL12COMPAT_MAX_VIDMODE: (checked during SDL_Init)

  • This is a string in the form of WxH, where W is the maximum width
  • and H is the maximum height (for example: 640x480). The list of valid
  • resolutions that will be reported by SDL_ListModes and SDL_VideoModeOK will
  • not include any dimensions that are wider or taller than these sizes. A size
  • of zero will be ignored, so for 0x480 a resolution of 1920x480 would be
  • accepted). If not specified, or set to 0x0, no resolution clamping is done.
  • This is for old software-rendered games that might always choose the largest
  • resolution offered, but never conceived of 4K displays. In these cases, it
  • might be better for them to use a smaller resolution and let sdl12-compat
  • scale their output up with the GPU.

– SDL_MOUSE_RELATIVE_SCALING: (checked during SDL_SetVideoMode)

  • If enabled, relative mouse motion is scaled when the application is
  • running at a non-native resolution. This may be required with some
  • applications which use their own mouse cursors. See also:


  • Enabled by default.
  • If disabled, calls to SDL_UpdateRects() from non-main threads are
  • converted into requests for the main thread to carry out the update later.
  • The thread that called SDL_SetVideoMode() is treated as the main thread.


  • Enabled by default.
  • If disabled, calls to SDL_PumpEvents() from non-main threads are
  • completely ignored.
  • The thread that called SDL_SetVideoMode() is treated as the main thread.

– SDL12COMPAT_ALLOW_SYSWM: (checked during SDL_Init)
± SDL2COMPAT_ALLOW_SYSWM: (checked during SDL_Init)
Enabled by default.
If disabled, SDL_SYSWMEVENT events will not be delivered to the app, and
SDL_GetWMInfo() will fail; this is useful if you have a program that
tries to access X11 directly through SDL’s interfaces, but can survive
without it, becoming compatible with, for example, Wayland, or perhaps

  • just avoiding a bug in target-specific code. Note that sdl12-compat already
  • disallows SysWM things unless SDL2 is using its “windows” or “x11” video
  • backends, because SDL 1.2 didn’t have wide support for its SysWM APIs
  • outside of Windows and X11 anyhow.
  • just avoiding a bug in target-specific code.

-# Compatibility issues with OpenGL scaling

-The OpenGL scaling feature of sdl12-compat allows applications which wish to
-run at a non-native screen resolution to do so without changing the system
-resolution. It does this by redirecting OpenGL rendering calls to a “fake”
-backbuffer which is scaled when rendering.

-This works well for simple applications, but for more complicated applications
-which use Frame Buffer Objects, sdl12-compat needs to intercept and redirect
-some OpenGL calls. Applications which access these functions without going
-though SDL (even if via a library) may not successfully render anything, or
-may render incorrectly if OpenGL scaling is enabled.

-In these cases, you can disable OpenGL scaling by setting the environment

Compatibility issues with applications directly accessing underlying APIs

Some applications combine the use of SDL with direct access to the underlying
OS or window system. When running these applications on the same OS and SDL
video driver (e.g. a program written for X11 on Linux is run on X11 on Linux),
-sdl12-compat is usually compatible.
+sdl2-compat is usually compatible.

However, if you wish to run an application on a different video driver, the
application will be unable to access the underlying API it is expecting, and