This keep documentation future-accurate and more importantly: it will
produce correct results before we tag the official release in git, so
they'll be correct in the tag and the release tarball.
This will let us automate this so it's managed for us, and as things go
from development to official releases, the documentation will automatically
update!
Otherwise a formula like `x = y * 2;` would treat that '*' as the start of
an italicized section when converting to MediaWiki format, and match any
other '*' in the content as the end marker.
Details:
Currently doing 4 system calls per WM_INPUT message, which can cause the thread handling the message loop to be swapped out several times:
* GetProp - to get window data from the window handle
* GetRawInputData - to retrieve the raw input data
* 2 calls to GetMessageExtraInfo - to ignore synthetic mouse events generated for touchscreens
In this change:
* Replaced GetProp by iterating the list of windows maintained by SDL (with a fallback to GetProp). Note that this will affect all messages and not just WM_INPUT
* only calling GetMessageExtraInfo if a touchscreen has been detected
Fix for https://jira.valve.org/browse/CSGO-4855
@saml
This is a work-in-progress, but the idea is it can convert between our
wiki and the SDL header's doxygen comments, so we can attempt to keep them
in sync.
This might be a fool's errand, but I'm optimistic it'll work enough that we
can clean up little issues as we go, as long as we have some discipline
about how we write documentation. If nothing else, it's going to result in
a solid spring-cleaning of both the wiki and the headers!
Ozkan Sezer
Our config.guess and config.sub are rather outdated.
Attached new versions of them here.
However, build-scripts/config.sub.patch do not apply
to these new versions: I don't know if and where that
patch is still needed.
Joshua Root
The change resulting from Bug 4208 changed the compatibility_version of libSDL2 from 9.0.0 to 1.0.0. This is simply wrong.
This means that programs linked against 2.0.9 are considered by the dynamic linker to be compatible with all previous versions of libSDL2. This is not the case since new public symbols have been added.
The way compatibility_version and current_version are meant to work is:
* current_version increases every time the library changes in any way.
* compatibility_version is increased to match current_version whenever new public symbols are added.
Thus both versions should only ever increase. The solution to the Xcode project and autotools not having matching versions should have been to increase the version(s) in the Xcode project.
Reference: https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/VersionInformation.html
Sylvain
armeabi is almost deprecated for android-ndk higher that r13b.
either it doesn't compile (ICE), or it executes wrongly (using long long for instance).
android people advices to use armeabi-v7a (or use r13b).
Also added native code to the Android gradle project, which allows using gradle or Android Studio to build the entire SDL application without a separate ndk-build step.
Mark Callow
README-android says to copy or link the SDL source tree to the jni folder in your Android project. It is not desirable to have to compile SDL with every application; furthermore the Android NDK has support for prebuilt libraries.
Attached is script (to be put in build-scripts) that builds the Android version of the libraries. The script builds both the existing SDL2 module and a new SDL2_main module. This is a static library containing the code from src/main/android/SDL_android_main.c. Also attached is a patch for Android.mk adding this module.
Note that when building an application's native .so using this prebuilt libSDL2main, you must use a link option, such as --whole-archive, that forces inclusion of the code in the .so because the functions in SDL_android_main are called only from Java.
