Andreas
With the patch applied, make is not able to find the rule for Makefile.in anymore. Removing the patch resolves the issue.
The path is in fact correct (in my case: /c/external/SDL64/SDL). But it seems the windows build of GNU Make doesn't work well with pathnames in rules. Both the dependencies in "$(srcdir)/configure: $(srcdir)/configure.in" and "Makefile: $(srcdir)/Makefile.in" will cause rules not to be found when srcdir is defined.
The same problem occurs if the patch is removed and I supply configure with a srcdir manually.
Alexey Petruchik
Although SDL_android.h is not intended to be included by client code sometimes it needed. For example you need JNIEnv pointer to make JNI calls to modified SDLActivity.java (video playback, facebook integration, in-apps). It seems a bit weird to write:
extern "C" {
#include "SDL_android.h"
}
in my AndroidJNI.cpp file.
driedfruit
SDL_RenderCopy clips dstrect against the viewport. Then it adjusts the
srcrect by "appropriate" amount of pixels. This amount is actually
wrong, quite a lot, because of the rounding errors introduced in the "*
factor / factor" scale.
real_srcrect.x += (deltax * real_srcrect.w) / dstrect->w;
real_srcrect.w += (deltaw * real_srcrect.w) / dstrect->w;
For example:
I have a 32 x 32 srcrect and a 64 x 64 dstrect. So far the
stretching is done perfectly, by a factor of 2.
Now, consider dstrect being clipped against the viewport, so it becomes
56 x 64. Now, the factor becomes 1.75 ! The adjustment to "srcrect"
can't handle this, cause srcrect is in integers.
And thus we now have incorrect mapping, with dstrect not being in the
right proportion to srcrect.
The problem is most evident when upscaling stuff, like displaying a 8x8
texture with a zoom of 64 or more, and moving it beyond the corners of
the screen. It *looks* really really bad.
Note: RenderCopyEX does no such clipping, and is right to do so. The fix would be to remove any such clipping from RenderCopy too. And then fix the software renderer, because it has the same fault, independently of RenderCopy.
[attached patch]
this leaves Software Renderer buggy, as it does it's own clipping later on
The DUFFS_LOOP_124() macro was trying to be too clever and wasn't doing the right thing, it was checking n & 4 instead of width.
I'm not sure how we didn't catch this before, but it should be fixed now.
Joseba García Echebarria
The current version of SDL HG in Android doesn't do anything when volume keys are pressed.
The change makes SDL ignore volume keys so that they're handled by the OS and the sound volume can be changed within an app.
The configure script was still overwriting SIZEOF_VOIDP so both ended up as either 4 or 8 depending on the arch. This simply removes the check from configure.in
You should be able to do wglMakeCurrent(NULL, NULL), according to MSDN, since
the first parameter is ignored if the second is NULL, but this causes problems
on some drivers, so make sure we always have a valid HDC in the first
parameter (and exit early if we already have no current context in the
NULL, NULL case).
Newer libpulses do sane defaults if you pass a NULL there. In lieu of a
proper way to specify this in SDL at the moment, this will do.
Fixes Bugzilla #1119.
According to documentation in header and wiki the index should be returned.
This change may break existing programs which assume only 0 means a success.
q66
after updating SDL2 to the latest RC I'm unable to build my game engine under mingw crosscompiling environment for Windows (32bit, hosted on freebsd 64bit).
The error is in SDL_thread.h with messages like this: http://codepad.org/jEQXd3Yq
The problem is, while _beginthreadex return type is correctly mapped to uintptr_t (as specified by Microsoft), the return type under mingw is unsigned long int (same size, different signature), resulting in the error above.
The reason it didn't error before is this: http://codepad.org/8FAbKAxz
You can see the _beginthreadex case is only used without HAVE_LIBC defined; at one point though, SDL_config_windows.h was changed like this:
-/* Enabled for SDL 1.2 (binary compatibility) */
-#define HAVE_LIBC 1
+/* This is disabled by default to avoid C runtime dependencies and manifest requirements */
resulting in these errors.
Vern Jensen
The problem is that in certain situations I'm getting THREE keyUp/keyDown events when I push certain keys.
In my event code I added:
case SDL_KEYUP:
printf("SDL KeyScanCode for KEYUP event: %d\n", event->key.keysym.scancode );
…
and
case SDL_KEYDOWN:
printf("SDL KeyScanCode for KEYDOWN event: %d\n", event->key.keysym.scancode );
…
The result of one test run where I push 2 keys and then release them is this:
SDL KeyScanCode for KEYDOWN event: 92 // Pushed keypad 4
SDL KeyScanCode for KEYDOWN event: 83 // Pushed left shift
SDL KeyScanCode for KEYUP event: 83
SDL KeyScanCode for KEYDOWN event: 225
SDL KeyScanCode for KEYUP event: 92 // Released keypad 4
SDL KeyScanCode for KEYDOWN event: 83
SDL KeyScanCode for KEYUP event: 83
SDL KeyScanCode for KEYUP event: 225 // Released left shift
There *should* be only a total of 4 events above… 2 for each key being pushed, and 2 for each being released. But instead some bogus events for numlock being pushed/released are sent from SDL. These events did not occur. I did not push numlock. The value above for numlock is 83. Comments above show when I pushed each key. As you can see, when I push left shift, THREE events are instantly sent to my application, keyDown and then keyUp for numlock, and then the valid event for left shift (the key that was actually pushed).
You could replace keypad 4 with pretty much any keyPad key and it'll still happen. You can also replace it with any arrow key and it'll happen. However, when trying it with normal letter keys on the main keyboard it didn't.
It happens with other modifier keys too, not just left shift.
The order in which the keys are pressed matter. For instance, if I do:
1) keypad 4
2) left shift
3) release left shift
4) release keypad 4
Then at step 2, I get the 3 events above (when there should be only one), but steps 3 and 4 work properly… I don't get extra keyUp/keyDown events for steps 3 or 4. Thereas if the order of steps 3 and 4 are reversed, I get the bogus extra events for numlock.
Also, the problem can occur even when pushing just a single key by itself. If I push left shift, then keypad 4, then release left shift, then release keypad 4, then the following push of left shift will cause the bug. If I continue pushing and releasing left shift though, it won't happen again until I again involve keypad keys.
---
Sam Lantinga
According to the Apple documentation, NSNumericPadKeyMask is set for any arrow or numeric keypad event. Indeed this is what's happening.
I verified that we get the correct events for the numlock key and the mod state gets set correcly, so it should be safe to remove this bogus code.
David Gow
As discussed on the list, the autotools build backend uses libtool's "release" option, giving us the SONAME libSDL2-2.0.so.0, whereas CMake doesn't, giving us libSDL2.so.0
While libSDL2.so.0 has some small advantages (being simpler and matching the names on some other OSes better), many products have already been developed expecting libSDL2-2.0.so.0, which better matches SDL 1.2's SONAME. It seems clear, therefore, that most developers prefer this name.
This patch emulates libtool's functionality, making libSDL2-2.0.so.0 the name of the shared library, while leaving libSDL2.a as the filename of the static library. Unlike with libtool, no libSDL2.so symlink is yet made. I also haven't tested this on anything but Linux, so it might break other platforms. :/
