On an X set-up with multiple monitors running separate X screens (as
opposed to merging them into one large X screen using Xinerama), the
selected X visual needs to be one for the screen where the colormap,
window, and other X resources are created. In fact, all these need to
match, and the GL context as well.
Most of the SFML windowing and graphics code uses (X)DefaultScreen()
for that, which is fine. Combined with XOpenDisplay(NULL), this will
create the window on the screen (and monitor) selected by the DISPLAY
enviroment variable. :0.0 will be the first monitor, :0.1 the second,
etc.
However, XGetVisualInfo() will return visuals for *all* screens, not
just the default one. They seem to be ordered by screen number, but I
don't think the standard makes any guarantees there.
If the visual doesn't match up with the screen, this will abort with
an X error. BadMatch, in many cases.
This means that in addition to other filtering,
GlxContext::selectBestVisual() needs to filter the visuals by screen
number, otherwise SFML won't work at all on any screens but the first.
This fixes issue #724.
When mesa updated their headers, they changed the include guard
from __glxext_h_ to __glx_glxext_h_, which breaks compilation
due to conflicting declarations. This commit modifies the preprocessor
directives to allow for compilation with older and newer mesa header
versions.
Fixes: #1472
- remove Wait and SizeAll cursors as they don't look nice
(Wait is not spining and produces a broken rendering,
SizeAll is a simple white cursor.)
- fix memory management for NSCursor.
- ignore selector warnings.
Added 1 pixel padding for glyph uv's and increased glyph quads boundaries by 1 pixel so the glyphs aren't cropped when text is being scrolled with sub-pixel increments
Before this change, `sf::Font` always rendered/provided one character
per Unicode codepoint, even if that character wasn't represented by the
current font file or duplicated. This caused more texture space to be
used than necessary, which is especially apparent, when trying to render
a large amount of unhandled glyphs (the texture would literally fill up
with empty squares representing missing characters).
When applying an outline thickness to sf::Text in combination with a
strikethrough and/or an underlined style, the ensureGeometryUpdate
function adds unwanted vertices if the string contains two consecutive
'\n' charecter.
To fix this we need to add an additional check in the if statements to
check if both the current and previous character it's a new line
character.
Calling tell() and thus std::ftell() for every reading iteration ate up
80-90% of the whole read call. By manually tracking the current position
the calls to tell() can be safely removed.
Windows should have no issue with this change, as it addresses
files in a case-insensitve manner. Said header is installed in
lowercase on mingw-w64, and won't build since commit
22f1b85515
Signed-off-by: Marty E. Plummer <hanetzer@startmail.com>
This commit drops the previous custom CMake toolchain file for Android
in favor of CMake's new built-in toolchain for this (CMake >3.7.2).
This makes building SFML for Android a lot simpler and more straight
forward, working almost as smooth as other platforms.
To configure your build directory, all you have to do is defining just a
few variables the first time you invoke CMake.
**Required Variables**
* `CMAKE_SYSTEM_NAME` must be `Android`, so CMake knows we actually want
to cross-compile.
* `CMAKE_ANDROID_NDK` must point to the NDK's installation directory,
e.g. `/usr/android/ndk` or `c:/android/ndk`.
**Recommended Variables**
* `CMAKE_ANDROID_STL_TYPE` defines the STL implementation to be used.
You should use `c++_shared`, although others might work.
**Optional Variables**
* `CMAKE_SYSTEM_VERSION` can be set to pick a specific SDK version other
than the latest.
* `CMAKE_ANDROID_ARCH_ABI` defines the target architecture and ABI, for
example `armeabi` or `armeabi-v7a`.
Based on your system, you might want to enforce a specific generator to
prevent issues, e.g. using `MinGW Makefiles`.
Previously when updating the header fields, SFML assumed the number of
samples written would be the number of samples per channel, which wasn't
the case. Therefore for stereo files the written file length was actually
twice the correct value. This fix uses the file size written as a basis,
no longer counting the samples written alltogether.
This fixes issue #1280.
