To fix this we need to ignore the alpha channel in the colorkey comparison, which is the way colorkey comparisons are defined in SDL.
We also need to reset the alpha and color modulation when converting a surface.
If the user is using their context from a non-main thread, we could be
calling -[NSOpenGLContext update] on our thread, while they were
accessing it on their thread.
With this change, we schedule updates when the event comes in on the
main thread, and act on them when the user calls SDL_GL_MakeCurrent or
SDL_GL_SwapWindow.
This uses a better mouse grab if you define SDL_MAC_NO_SANDBOX. This
mouse grab uses CGEventTapCreate, which you cannot access if you have
sandboxing enabled.
From Sythical:
Hello, I've created a simple SDL2 application which draws a texture on the screen. The problem I'm having is that if I launch another program which loads the UAC popup or if I lock my PC and then login again, the application stops drawing the texture. I tried adding SDL_Delay(10000) after SDL_RenderPresent(renderer). This made the texture stay on the screen for a little bit but the texture wasn't drawn again after the delay. Here's my code:
#include "SDL.h"
int main(int argc, char *argv[])
{
SDL_Renderer *renderer;
SDL_Window *window;
SDL_Surface *surface;
SDL_Texture *rect_texture;
SDL_Event main_event;
SDL_Rect rect_data;
int enable_vsync = 1;
if(SDL_Init(SDL_INIT_VIDEO) < 0) return 1;
window = SDL_CreateWindow("SDL2 Application", SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, 600, 600, SDL_WINDOW_RESIZABLE);
renderer = SDL_CreateRenderer(window, -1, enable_vsync ? SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC : SDL_RENDERER_ACCELERATED);
SDL_SetRenderDrawColor(renderer, 20, 20, 30, 255);
surface = SDL_LoadBMP("icon.bmp");
rect_texture = SDL_CreateTextureFromSurface(renderer, surface);
rect_data.w = 32; rect_data.h = 32;
rect_data.x = 300; rect_data.y = 300;
while(main_event.type != SDL_QUIT)
{
SDL_PollEvent(&main_event);
SDL_RenderClear(renderer);
SDL_RenderCopy(renderer, rect_texture, NULL, &rect_data);
SDL_RenderPresent(renderer);
}
SDL_DestroyTexture(rect_texture);
SDL_DestroyRenderer(renderer);
SDL_DestroyWindow(window);
SDL_Quit();
return 0;
}
This prevents a rogue call to SetWindowPos() from changing the state unexpectedly.
Also moved the size correction code above the window position query, because the initial window size can affect the positioning.
Anisotropic filtering is meant to be used for textures at a stark
angle, not perpendicular to the camera.
--HG--
extra : rebase_source : e01c4da3bae7f1628de7c049f31f1208dbbbb24c
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.
