kmx git

Commit	Date	Message
d763a9f6	2015-06-19T23:22:53	Fixed bug 2538 - SDL_SetTextureAlphaMod does not work with SDL_FlipMode or rotation in the software renderer Adam M. When setting a texture alpha mod other than 255 and also specifying a flip mode in the software renderer, the rendering fails. When the texture has an alpha channel, it becomes invisible when flipped. When the texture does not have an alpha channel, it is flipped but the colors are wrong: the alpha mod makes the texture darker rather than more translucent. 0) Initialize a software renderer. 1) Load 16-bit 565 or 32-bit texture. 2) Set texture blend mode to BLEND. 3) Set texture alpha mod to 150. 4) Draw the texture flipped horizontally and/or vertically.
b7ede6cc	2015-06-19T23:20:43	Fixed bug 1550 - SDL_RenderCopy/CopyEx in software should optionally render 8bit alpha Adam M. There are three problems in the code that I see. 1. SW_RenderCopyEx enables a color key on surface_scaled even if the source surface didn't have a color key. 2. SW_RenderCopyEx doesn't copy blend mode, color mod, or alpha mod from src to surface_scaled. 3. When SDL_BlitScaled(src, srcrect, surface_scaled, &tmp_rect) is called, it blends the src pixels into surface_scaled instead of overwriting them (if src has blending, etc. enabled). I've attached a patch that 1) fixes the three problems that I mentioned, 2) adds the requested performance improvement of using the regular blit function if no rotation or flipping is needed, 3) avoids cloning the source surface if no stretching is required, and simplifies the rotation code slightly.
82ae4f6f	2015-06-19T22:12:47	[mq]: 3027_rleperf.diff
a4eb0dea	2015-06-14T19:10:51	Fixed bug 2908 - Fix clang warnings Simon Deschenes My build system still shows warning as errors. The first warning says that the member named instances can never be false (or NULL) as it is a static array, and we should check for instances[index] which we do anyway.
fd8b7c1c	2015-06-05T19:41:18	Fixed comments at conditional compilation macros.
38549a7b	2015-06-04T00:56:11	Fixed bug 2625 - Direct3D9 with SDL_TEXTUREACCESS_TARGET textures causes an application crash Roberto I have debugged the code checking the function calls when Direct3D is the renderer, remember that with software and OpenGL renderers, this issue is not happening. - Create the texture: SDL_Texture *pTex = SDL_CreateTexture(pRenderer, iFormat, SDL_TEXTUREACCESS_TARGET, pSurf->w, pSurf->h); - Update the texture: SDL_UpdateTexture(pTex, NULL, pSurf->pixels, pSurf->pitch); SDL_render.c, SDL_UpdateTexture(): return renderer->UpdateTexture(renderer, texture, rect, pixels, pitch); SDL_render_d3d.c, D3D_UpdateTexture(): if (D3D_UpdateTextureRep(data->device, &texturedata->texture, texture->format, rect->x, rect->y, rect->w, rect->h, pixels, pitch) < 0) { SDL_render_d3d.c, D3D_UpdateTextureRep(): if (D3D_CreateStagingTexture(device, texture) < 0) { SDL_render_d3d.c, D3D_CreateStagingTexture(): result = IDirect3DDevice9_CreateTexture(..., D3DPOOL_SYSTEMMEM, ...) --> FAIL! with INVALIDCALL code After checking a bit the Microsoft documentation, I found this: D3DUSAGE_RENDERTARGET can only be used with D3DPOOL_DEFAULT. (https://msdn.microsoft.com/en-us/library/windows/desktop/bb172625%28v=vs.85%29.aspx) The call that fails, is using D3DUSAGE_RENDERTARGET with D3DPOOL_SYSTEMMEM which is unsupported, hence the INVALIDCALL return code.
da190975	2015-05-28T18:57:10	Fixed clip rectangle calculation when there is a viewport offset
6a3ad8a9	2015-05-28T12:18:05	Fixed bug 2367 - Bad mouse motion coordinates with two windows where one has changed logical size Andreas Ragnerstam I have two windows where one has a renderer where the logical size has been changed with SDL_RenderSetLogicalSize. When I get SDL_MOUSEMOTION events belonging to the non-scaled window these will have been scaled with the factor of the scaled window, which is not expected. Adding some printf debugging to SDL_RendererEventWatch of SDL_render.c, where (event->type == SDL_MOUSEMOTION), I found that for every mouse motion SDL_RendererEventWatch is called twice and the event->motion.x and event.motion.y are set twice for the event, once for each renderer where only the last one set will be saved to the event struct. This will work fine if both renderers have the same scale, but otherwise the motion coordinates will be scaled for the renderer belonging to another window than the mouse was moved in. I guess one solution would be to check that window == renderer->window for SDL_MOUSEMOTION events, similar to what is done for when SDL_WINDOWEVENT events. I get the same error on both X11 and Windows. The same problem also exists for SDL_MOUSEBUTTONDOWN and SDL_MOUSEBUTTONUP events.
d5a57853	2015-05-26T16:42:36	Drop out of SDL_UpdateTexture() early if the rectangle is zero pixels. Hopefully makes static analysis happy about a zero-byte malloc elsewhere.
2c4a6ea0	2015-05-26T06:27:46	Updated the copyright year to 2015
fcee3e73	2015-05-16T17:35:36	Code style cleanup in the GLES and GLES2 render backends.
b72938c8	2015-04-20T12:22:44	Windows: Always set the system timer resolution to 1ms by default. An existing hint lets apps that don't need the timer resolution changed avoid this, to save battery, etc, but this fixes several problems in timing, audio callbacks not firing fast enough, etc. Fixes Bugzilla #2944.

d763a9f6

2015-06-19T23:22:53

Fixed bug 2538 - SDL_SetTextureAlphaMod does not work with SDL_FlipMode or rotation in the software renderer Adam M. When setting a texture alpha mod other than 255 and also specifying a flip mode in the software renderer, the rendering fails. When the texture has an alpha channel, it becomes invisible when flipped. When the texture does not have an alpha channel, it is flipped but the colors are wrong: the alpha mod makes the texture darker rather than more translucent. 0) Initialize a software renderer. 1) Load 16-bit 565 or 32-bit texture. 2) Set texture blend mode to BLEND. 3) Set texture alpha mod to 150. 4) Draw the texture flipped horizontally and/or vertically.

b7ede6cc

2015-06-19T23:20:43

Fixed bug 1550 - SDL_RenderCopy/CopyEx in software should optionally render 8bit alpha Adam M. There are three problems in the code that I see. 1. SW_RenderCopyEx enables a color key on surface_scaled even if the source surface didn't have a color key. 2. SW_RenderCopyEx doesn't copy blend mode, color mod, or alpha mod from src to surface_scaled. 3. When SDL_BlitScaled(src, srcrect, surface_scaled, &tmp_rect) is called, it blends the src pixels into surface_scaled instead of overwriting them (if src has blending, etc. enabled). I've attached a patch that 1) fixes the three problems that I mentioned, 2) adds the requested performance improvement of using the regular blit function if no rotation or flipping is needed, 3) avoids cloning the source surface if no stretching is required, and simplifies the rotation code slightly.

82ae4f6f

2015-06-19T22:12:47

[mq]: 3027_rleperf.diff

a4eb0dea

2015-06-14T19:10:51

Fixed bug 2908 - Fix clang warnings Simon Deschenes My build system still shows warning as errors. The first warning says that the member named instances can never be false (or NULL) as it is a static array, and we should check for instances[index] which we do anyway.

fd8b7c1c

2015-06-05T19:41:18

Fixed comments at conditional compilation macros.

38549a7b

2015-06-04T00:56:11

Fixed bug 2625 - Direct3D9 with SDL_TEXTUREACCESS_TARGET textures causes an application crash Roberto I have debugged the code checking the function calls when Direct3D is the renderer, remember that with software and OpenGL renderers, this issue is not happening. - Create the texture: SDL_Texture *pTex = SDL_CreateTexture(pRenderer, iFormat, SDL_TEXTUREACCESS_TARGET, pSurf->w, pSurf->h); - Update the texture: SDL_UpdateTexture(pTex, NULL, pSurf->pixels, pSurf->pitch); SDL_render.c, SDL_UpdateTexture(): return renderer->UpdateTexture(renderer, texture, rect, pixels, pitch); SDL_render_d3d.c, D3D_UpdateTexture(): if (D3D_UpdateTextureRep(data->device, &texturedata->texture, texture->format, rect->x, rect->y, rect->w, rect->h, pixels, pitch) < 0) { SDL_render_d3d.c, D3D_UpdateTextureRep(): if (D3D_CreateStagingTexture(device, texture) < 0) { SDL_render_d3d.c, D3D_CreateStagingTexture(): result = IDirect3DDevice9_CreateTexture(..., D3DPOOL_SYSTEMMEM, ...) --> FAIL! with INVALIDCALL code After checking a bit the Microsoft documentation, I found this: D3DUSAGE_RENDERTARGET can only be used with D3DPOOL_DEFAULT. (https://msdn.microsoft.com/en-us/library/windows/desktop/bb172625%28v=vs.85%29.aspx) The call that fails, is using D3DUSAGE_RENDERTARGET with D3DPOOL_SYSTEMMEM which is unsupported, hence the INVALIDCALL return code.

da190975

2015-05-28T18:57:10

Fixed clip rectangle calculation when there is a viewport offset

6a3ad8a9

2015-05-28T12:18:05

Fixed bug 2367 - Bad mouse motion coordinates with two windows where one has changed logical size Andreas Ragnerstam I have two windows where one has a renderer where the logical size has been changed with SDL_RenderSetLogicalSize. When I get SDL_MOUSEMOTION events belonging to the non-scaled window these will have been scaled with the factor of the scaled window, which is not expected. Adding some printf debugging to SDL_RendererEventWatch of SDL_render.c, where (event->type == SDL_MOUSEMOTION), I found that for every mouse motion SDL_RendererEventWatch is called twice and the event->motion.x and event.motion.y are set twice for the event, once for each renderer where only the last one set will be saved to the event struct. This will work fine if both renderers have the same scale, but otherwise the motion coordinates will be scaled for the renderer belonging to another window than the mouse was moved in. I guess one solution would be to check that window == renderer->window for SDL_MOUSEMOTION events, similar to what is done for when SDL_WINDOWEVENT events. I get the same error on both X11 and Windows. The same problem also exists for SDL_MOUSEBUTTONDOWN and SDL_MOUSEBUTTONUP events.

d5a57853

2015-05-26T16:42:36

Drop out of SDL_UpdateTexture() early if the rectangle is zero pixels. Hopefully makes static analysis happy about a zero-byte malloc elsewhere.

2c4a6ea0

2015-05-26T06:27:46

fcee3e73

2015-05-16T17:35:36

Code style cleanup in the GLES and GLES2 render backends.

b72938c8

2015-04-20T12:22:44

Windows: Always set the system timer resolution to 1ms by default. An existing hint lets apps that don't need the timer resolution changed avoid this, to save battery, etc, but this fixes several problems in timing, audio callbacks not firing fast enough, etc. Fixes Bugzilla #2944.

kc3-lang/SDL/src/render

src/render

Log