|
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.
|