Anisotropic filtering is meant to be used for textures at a stark
angle, not perpendicular to the camera.
--HG--
extra : rebase_source : e01c4da3bae7f1628de7c049f31f1208dbbbb24c
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.
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.
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.
Edgar Simo 2012-05-06 02:33:39 EDT
I recall that driver being buggy back in the day, but looking over the code there's a number of things being done wrong which I've fixed and it should now properly error out instead of crashing. Also make sure you initialize the haptic subsystem before using haptic commands (which I now more explicitly try to enforce).
Sebastian
Setting a window icon works just fine until a renderer is added to the window.
After adding the renderer the icon disappears.
Reproduce by:
- Take the example code from the wiki: http://wiki.libsdl.org/moin.fcg/SDL_SetWindowIcon
- Add the following two lines after SDL_FreeSurface(surface);
SDL_Delay(1000);
SDL_Renderer* ren = SDL_CreateRenderer(window, -1, SDL_RENDERER_ACCELERATED);
-compile and run
You will see the window icon correctly at first. After the Delay the Icon will disappear.
driedfruit
In X11_HideWindow, we call XUnmapWindow to unmap. According to ICCCN2.0, this should never happen, and XWithdrawWindow should be called instead.
http://www.tronche.com/gui/x/icccm/sec-4.html#s-4.1.4
"The reason for requiring the client to send a synthetic UnmapNotify event is to ensure that the window manager gets some notification of the client's desire to change state, ***even though the window may already be unmapped when the desire is expressed***."
Additionally, this can be observed at http://cgit.freedesktop.org/xorg/lib/libX11/tree/src/Withdraw.c#n65
Failure to comply leads to "MapNotify" event never appearing on non-reparenting WMs after subsequent show-hide-show requests. (I'm currently observing this behavior, thus my bug report).
Lee Salzman
I messed up in the patch I sent you regarding gobbling up the GLX error codes signaled when trying to create a context. After reading the spec I realized those error codes are relative to a base error that needs to be queried when setting up the GLX extension...
So I have made a patch that fixes it for a user I had who was still getting the bug with my old patch.
Without this patch my previous one won't work, so it is recommended to merge this...
