Commit Graph

12 Commits

Author SHA1 Message Date
Sam Lantinga
bcdf8b916b Added SDL_fmod() and SDL_fmodf() 2017-11-04 17:35:03 -07:00
Sam Lantinga
34502143d9 Added float versions of SDL's math functions 2017-11-04 15:34:14 -07:00
Ryan C. Gordon
620f5342b5 stdlib: An implementation of SDL_scalbn using ldexp() (thanks, Ozkan!).
Fixes Bugzilla #3767.
2017-08-29 00:36:17 -04:00
Sam Lantinga
fcf83e7908 Fixed bug 3768 - provide a quick copysign() solution for watcom
Ozkan Sezer

The following patch provides a quick copysign solution for Watcom/x86
2017-08-21 16:30:24 -07:00
Sam Lantinga
45b774e3f7 Updated copyright for 2017 2017-01-01 18:33:28 -08:00
Sam Lantinga
40b571c91e Fixed bug 3468 - _allshr in SDL_stdlib.c is not working properly
Mark Pizzolato

On Windows with Visual Studio, when building SDL as a static library using the x86 (32bit) mode, several intrinsic operations are implemented in code in SDL_stdlib.c.

One of these, _allshr() is not properly implemented and fails for some input.  As a result, some operations on 64bit data elements (long long) don't always work.

I classified this bug as a blocker since things absolutely don't work when the affected code is invoked.  The affected code is only invoked when SDL is compiled in x86 mode on Visual Studio when building a SDL as a static library.  This build environment isn't common, and hence the bug hasn't been noticed previously.

I reopened #2537 and mentioned this problem and provided a fix.  That fix is provided again here along with test code which could be added to some of the SDL test code.  This test code verifies that the x86 intrinsic routines produce the same results as the native x64 instructions which these routines emulate under the Microsoft compiler.  The point of the tests is to make sure that Visual Studio x86 code produces the same results as Visual Studio x64 code.  Some of the arguments (or boundary conditions) may produce different results on other compiler environments, so the tests really shouldn't be run on all compilers.  The test driver only actually exercised code when the compiler defines _MSC_VER, so the driver can generically be invoked without issue.
2016-11-06 10:01:08 -08:00
Sam Lantinga
8109b1378a Partial fix for bug 3092 - Statically link sdl2 with /MT for msvc
Mike Linford

I'm also having trouble statically linking SDL2 on Visual Studio 2015 with /MT. My symptom is that memcpy is being defined twice.
2016-10-17 21:47:33 -07:00
Sam Lantinga
9db5e9aae9 Made #if defined(X) consistent 2016-10-10 02:58:29 -07:00
Sam Lantinga
e2fd1c0fe3 Backed out commit 80ce90dbc266, this causes Visual Studio build failure on buildbot 2016-01-02 11:17:06 -08:00
Sam Lantinga
ac444cd313 Fixed bug 3092 - Statically link sdl2 with /MT for msvc
Martin Gerhardy

According to https://msdn.microsoft.com/de-de/library/2kzt1wy3%28v=vs.120%29.aspx when one is using /MT for msvc compilations the libcmt.lib is already linked to the binary. This lib includes the symbol that is now guarded (see attached patch) by the #ifndef _MT.
2016-01-02 10:25:53 -08:00
Sam Lantinga
42065e785d Updated copyright to 2016 2016-01-02 10:10:34 -08:00
Philipp Wiesemann
0e45984fa0 Fixed crash if initialization of EGL failed but was tried again later.
The internal function SDL_EGL_LoadLibrary() did not delete and remove a mostly
uninitialized data structure if loading the library first failed. A later try to
use EGL then skipped initialization and assumed it was previously successful
because the data structure now already existed. This led to at least one crash
in the internal function SDL_EGL_ChooseConfig() because a NULL pointer was
dereferenced to make a call to eglBindAPI().
2015-06-21 17:33:46 +02:00