Commit Graph

120 Commits

Author SHA1 Message Date
Ozkan Sezer
c68d3ab785 Watcom supports __FUNCTION__ identifier (and surely not __PRETTY_FUNCTION__)
Partially fixes Bugzilla #3758.
2017-08-17 21:35:46 -04:00
Sam Lantinga
04e76499ea Fixed build warning 2017-08-14 20:37:07 -07:00
Sam Lantinga
9451cd81ae Fixed compiler warnings 2017-08-14 20:07:30 -07:00
Sam Lantinga
aebe17d34f Fixed bug 2344 - CHECK_WINDOW_MAGIC should include __FILE__ and __LINE__
Martin Gerhardy

just for easier debugging issues in the own code...

SDL_CreateRenderer should maybe also use this macro

Ryan C. Gordon

I'll go one better: it should have an SDL_assert().
2017-08-14 16:34:54 -07:00
Sam Lantinga
36ba92485c Fixed setting the texture blend mode in the OpenGL ES2 renderer 2017-08-14 10:04:59 -07:00
Sam Lantinga
c59d9923b3 Implemented more flexible blending modes for accelerated renderers
This fixes bug 2594 - Propose new blend mode, SDL_BLENDMODE_BLEND_DSTA

	blendMode = SDL_ComposeCustomBlendMode(SDL_BLENDFACTOR_SRC_ALPHA,
	                                       SDL_BLENDFACTOR_ONE_MINUS_SRC_ALPHA,
	                                       SDL_BLENDOPERATION_ADD,
	                                       SDL_BLENDFACTOR_ZERO,
	                                       SDL_BLENDFACTOR_ONE,
	                                       SDL_BLENDOPERATION_ADD);

This fixes bug 2828 - Subtractive Blending

	blendMode = SDL_ComposeCustomBlendMode(SDL_BLENDFACTOR_SRC_ALPHA,
	                                       SDL_BLENDFACTOR_ONE,
	                                       SDL_BLENDOPERATION_SUBTRACT,
	                                       SDL_BLENDFACTOR_ZERO,
	                                       SDL_BLENDFACTOR_ONE,
	                                       SDL_BLENDOPERATION_SUBTRACT);


This goes partway to fixing bug 3684 - Add support for a pre-multiplied alpha blending mode

	blendMode = SDL_ComposeCustomBlendMode(SDL_BLENDFACTOR_ONE,
	                                       SDL_BLENDFACTOR_ONE_MINUS_SRC_ALPHA,
	                                       SDL_BLENDOPERATION_ADD,
	                                       SDL_BLENDFACTOR_ONE,
	                                       SDL_BLENDFACTOR_ONE_MINUS_SRC_ALPHA,
	                                       SDL_BLENDOPERATION_ADD);
2017-08-14 05:51:44 -07:00
Sam Lantinga
f8e1874d01 Fixed bug 2646 - Problems with software renderer when SDL_SetRenderLogicalSize set
Fixed setting the software renderer clip rectangle when a viewport is set
2017-08-13 22:50:23 -07:00
Sam Lantinga
7af3786def Fixed bug 2755 - SDL2 fails to build on Solaris 10 u3
UX-admin

I am compiling with the Sun Studio 12 u2 compiler. There are multiple issues with the build, but this particular issue appears to be that it is illegal to declare a union of a struct of floats and a float. While GCC 4.8.1 does not flag this as an error, Sun Studio is much more standards compliant and strict, halting further compilation with an error.
2017-08-13 21:55:42 -07:00
Sam Lantinga
ca5c304814 Fixed bug 3744 - missing SDLCALL in several functions
Ozkan Sezer

The attached patch adds missing SDLCALL to several functions, so that
they properly match the headers as intended.
2017-08-13 21:06:52 -07:00
Sam Lantinga
af9ec8f6b5 Fixed copy-paste error, thanks Alen! 2017-08-13 20:13:11 -07:00
Sam Lantinga
6f843b902d Fixed bug 3243 - SDL_SetRenderDrawColor() behaves wrong with RGBA=0
Simon Hug

The bug is in the GL_ResetState and GLES_ResetState functions which get called after a new GL context is created. These functions set the cached current color to transparent black, but the GL specification says the initial color is opaque white.

The attached patch changes the values to 0xffffffff to reflect the initial state of the current color. Should the ResetState functions get called anywhere else in the future, this probably has to call the GL functions itself to ensure that the colors match.
2017-08-12 12:59:22 -07:00
Sam Lantinga
4c239e55f9 Fixed bug 3297 - Horizontal and Vertical flip swapped on PSP
Littlefighter19

When trying to mirror something on the PSP, I've stumbled upon the problem,
that using SDL_RenderCopyEx with SDL_FLIP_HORIZONTAL flips the image vertically, vise-versa SDL_FLIP_VERTICAL flips the image horizontally.
Proposed patch would be swapping the check in line 944 with the one in line 948 in SDL_render_psp.c
2017-08-11 20:54:06 -07:00
Sam Lantinga
6de66e984f Fixed bug 3324 - SDL_RenderReadPixels: Wrong rect coordinates with software renderer
Daniel

SDL_RenderReadPixels with SDL_RENDERER_SOFTWARE reads pixels from wrong coordinates.

SW_RenderReadPixels adjusts the rect coordinates according to the viewport. But since this is already done by SDL_RenderReadPixels, the final rect has x2 bigger X and Y.
2017-08-11 11:54:24 -07:00
Sam Lantinga
ef54d5a8f0 Fixed building on various versions of GCC - YUV MMX code is disabled for now 2017-08-07 10:28:59 -07:00
Philipp Wiesemann
8aa147fa09 Fixed compiler warnings about type conversions.
Found by buildbot.
2017-08-04 23:00:30 +02:00
Sam Lantinga
9dbe5a9686 Fixed bug 3311 - Broken touch positions with SDL_RenderSetLogicalSize & HIGHDPI on iOS
Eric wing

Hi, I think I found a bug when using SDL_WINDOW_ALLOW_HIGHDPI with SDL_RenderSetLogicalSize on iOS. I use SDL_RenderSetLogicalSize for all my stuff. I just tried turning on SDL_WINDOW_ALLOW_HIGHDPI on iOS and suddenly all my touch/mouse positions are really broken/far-off-the-mark.

I actually don't have a real retina device (still) so I'm seeing this using the iOS simulator with a 6plus template.

Attached is a simple test program that can reproduce the problem. It uses RenderSetLogicalSize and draws some moving happy faces (to show the boundaries/space of the LogicalSize and that it is working correctly for that part).

When you click/touch, it will draw one more happy face where your button point is.

If you comment out SDL_WINDOW_ALLOW_HIGHDPI, everything works as expected. But if you compile with it in, the mouse coordinates seem really far off the mark. (Face appears far up and to the left.)


Alex Szpakowski on the mailing list suggests the problem is
"I believe this is a bug in SDL_Render?s platform-agnostic mouse coordinate scaling code. It assumes the units of the mouse coordinates are always in pixels, which isn?t the case where high-DPI is involved (regardless of whether iOS is used) ? they?re actually in ?DPI independent? coordinates (which matches the window size, but not the renderer output size)."

Additionally, if this is correct, the Mac under Retina is also probably affected too and "as well as any other platform SDL adds high-dpi support for in the future".
2017-08-02 13:38:46 -07:00
Ryan C. Gordon
18f2b27b73 Whoops, forgot to commit the actual fix. :) 2017-07-26 13:54:11 -04:00
Ryan C. Gordon
7ecc48c3ba Disable MMX inline assembly on Clang for now.
We should probably rewrite this with SSE compiler intrinsics or something
anyhow.
2017-07-26 13:43:25 -04:00
Sam Lantinga
36998b823e Fixed bug 3689 - MMX YUV renderer crash
felix

The functions in src/render/SDL_yuv_mmx.c contain the following inline assembly snippet:

        /* tap dance to workaround the inability to use %%ebx at will... */
        /*  move one thing to the stack... */
        "pushl $0\n"  /* save a slot on the stack. */
        "pushl %%ebx\n"  /* save %%ebx. */
        "movl %0, %%ebx\n"  /* put the thing in ebx. */
        "movl %%ebx,4(%%esp)\n"  /* put the thing in the stack slot. */
        "popl %%ebx\n"  /* get back %%ebx (the PIC register). */

Here's how it ended up in a binary on my old laptop:

   0xb5c17dbd <ColorRGBDitherYV12MMX1X+93>:	push   $0x0
   0xb5c17dbf <ColorRGBDitherYV12MMX1X+95>:	push   %ebx
   0xb5c17dc0 <ColorRGBDitherYV12MMX1X+96>:	mov    0xc(%esp),%ebx
   0xb5c17dc4 <ColorRGBDitherYV12MMX1X+100>:	mov    %ebx,0x4(%esp)
   0xb5c17dc8 <ColorRGBDitherYV12MMX1X+104>:	pop    %ebx

Apparently the compiler, oblivious to the fact that the assembly snippet manipulates the %esp register, decided to refer to the operand via that same register instead of via %ebp (I believe -fomit-frame-pointer enables this). This causes %ebx to be loaded with the wrong value, which later leads to a null pointer dereference.

Recent GCC can use the %ebx register normally: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47602#c16>. There is even an explicit constraint "b" for allocating it.
2017-07-20 10:48:57 -07:00
Ryan C. Gordon
9288983682 Merged Eric Wing's overscan patch.
Fixes Bugzilla #2799.
2017-06-06 14:06:40 -04:00
Philipp Wiesemann
63b3e06f75 Corrected names of header file guards. 2017-06-03 23:00:15 +02:00
Ryan C. Gordon
02773811b3 render: GL_DestroyRender() should activate first.
Otherwise, we might destroy a different GL context's resources.
2017-05-18 21:00:11 -04:00
Philipp Wiesemann
266816b4aa Removed newlines from error messages. 2017-03-26 21:00:19 +02:00
Ryan C. Gordon
ca0bf151d5 Fix some more compiler warnings on armcc. 2017-03-03 16:38:17 -05:00
Ryan C. Gordon
07519a6b95 Removed a bunch of unnecessary #ifdefs. 2017-02-26 00:40:04 -05:00
David Ludwig
b13c443cd8 WinRT: removed buildbot debug code, pending further research 2017-02-24 20:49:14 -05:00
David Ludwig
f7bfa3b79e WinRT: more buildbot debug code 2017-02-24 20:19:28 -05:00
David Ludwig
ecb1eb823e WinRT: added code to help debug a buildbot error 2017-02-24 19:59:57 -05:00
Sam Lantinga
13433c4a61 Fixed bug 3569 - GL_UpdateViewport leaves PROJECTION matrix selected
Tom Seddon

GL_ActivateRenderer may call GL_UpdateViewport, which leaves the GL_PROJECTION matrix selected. But after GL_ResetState, the GL_MODELVIEW matrix is selected, suggesting that's the intended default state.

It seems at least like these should be consistent. Presumably GL_UpdateViewport should be doing a glMatrixMode(GL_MODELVIEW) before it finishes.
2017-01-27 21:23:27 -08:00
Sam Lantinga
9d9e92cf46 Fixed bug 3304 - Android black screen on resume
Richard Russell

Resuming from a suspended state results in a black screen.  This only happens when using GLES 1.1 (GLES 2 resumes correctly) and when the render target has been changed using SDL_SetRenderTarget.  This problem is new in 2.0.4.

The attached test case demonstrates the issue.

Sylvain Becker has apparently found a fix as follows:

"In the opengles leaf function (in 'src/render/opengles/SDL_render_gles.c'), it appears there is a call to 'GLES_ActivateRenderer' in 'GLES_SetRenderTarget', which is not present in opengles2. When commenting out this 'GLES_ActivateRenderer', it seems to resume fine".

This appears to fix the testcase perfectly, but I don't know whether it could have any undesirable side-effects.
2017-01-08 10:41:22 -08:00
Ryan C. Gordon
c1ac4c6835 Better fix for static analysis issue in SDL_DestroyRenderer().
Follow up fix for Bugzilla #3544.
2017-01-06 21:17:33 -05:00
Sam Lantinga
3df77ced1e Just roll back the entire portion of the commit from a8253d439914 which caused bug 3544 until we figure out what the right static analysis fix is. 2017-01-06 00:40:22 -08:00
Sam Lantinga
356c2eadf4 Fixed bug 3544 - Memory freeing bug in SDL_DestroyRenderer/SDL_DestroyTexture
felix

Here's a snippet of SDL_DestroyRenderer from hg revision 10746:7540ff5d0e0e:

    SDL_Texture *texture = NULL;
    SDL_Texture *nexttexture = NULL;
    /* ... */
    for (texture = renderer->textures; texture; texture = nexttexture) {
        nexttexture = texture->next;
        SDL_DestroyTexture(texture);
    }

SDL_DestroyTexture removes the texture from the linked list pointed to by the renderer and ends up calling SDL_DestroyTextureInternal, which contains this:

    if (texture->native) {
        SDL_DestroyTexture(texture->native);
    }

If it happens that texture->native is an alias of nexttexture two stack frames up, SDL_DestroyRenderer will end up trying to destroy an already freed texture. I've had this very situation happen in dosemu2.

Bug introduced in revision 10650:a8253d439914, which has a somewhat ironic description of "Fixed all known static analysis bugs"...
2017-01-06 00:32:06 -08:00
Sam Lantinga
45b774e3f7 Updated copyright for 2017 2017-01-01 18:33:28 -08:00
Ryan C. Gordon
fb5fd67ccb Fixed all known static analysis bugs, with checker-279 on macOS. 2016-11-24 21:41:09 -05:00
Ryan C. Gordon
e93e91f0b5 Pacify some GCC strict-aliasing compiler warnings. 2016-11-23 21:52:48 -05:00
Ryan C. Gordon
40c2a6fb55 Fixed more compiler warnings. 2016-11-23 11:49:26 -05:00
Sam Lantinga
3615633571 Renaming of guard header names to quiet -Wreserved-id-macro
Patch contributed by Sylvain
2016-11-20 21:34:54 -08:00
Philipp Wiesemann
97aa577589 Fixed empty parameter list in signatures of internal functions. 2016-11-16 22:08:51 +01:00
Sam Lantinga
0d24495b15 Removed unused constants
Except for SDL_bmp.c where they are historically interesting and I've left them in.
2016-11-15 01:24:58 -08:00
Sam Lantinga
ab8bd3d96b Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx
Simon Hug

The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.)

Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient.

The following blend modes have issues when drawn at an angle.

NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode.

MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations.

BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is.

This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function.

There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers.

The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode...

It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster?

As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode.

I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
Sam Lantinga
57d01d7d67 Patch from Sylvain to fix clang warnings 2016-11-13 22:57:41 -08:00
Sam Lantinga
77000ff8cb Fixed bug 1822 - Inconsistent renderer behaviour on rotation
Sylvain 2016-11-07 08:49:34 UTC

when rotated +90 or -90, some transparent lines appears, though there is no Alpha or ColorKey.

if you set a dummy colorkey, it will remove the line ...
if you set a some alpha mod, the +90/-90 get transparent but not the 0/180  ...
2016-11-11 13:38:39 -08:00
Sam Lantinga
057bca8a68 Better fix for last point in D3D11 renderer, thanks to Nader Golbaz 2016-11-06 15:15:32 -08:00
Sam Lantinga
330e2952d8 Fixed bug 2421 for D3D11 - SDL_RenderCopyEx off by one when rotating by 90 and -90.
Nader Golbaz

Updated patch for direct3d renderers
2016-11-06 08:47:40 -08:00
Sam Lantinga
4ed4997cc4 Fixed bug 2421 for D3D9 - SDL_RenderCopyEx off by one when rotating by 90 and -90
Nader Golbaz

Updated patch for direct3d renderers
2016-11-06 08:42:46 -08:00
Sam Lantinga
8e2634eb13 Fixed divide by zero if setting integer scale without setting logical width and height 2016-10-14 00:51:57 -07:00
Sam Lantinga
e4af8ce968 Fixed typo getting the drawable size 2016-10-13 04:57:31 -07:00
Sam Lantinga
662f966cd9 Fixed bug 3355 - false "Invalid renderer" after creating an "opengles2" renderer.
Call SDL_GL_GetDrawableSize() directly because we may be in the initialization path and SDL_GetRendererOutputSize() will fail because the renderer magic isn't set up yet.
2016-10-13 08:46:34 -07:00
Sam Lantinga
36e40d30fc Fixed bug 2923 - Add SDL_PIXELFORMAT_RGBA32 for byte-wise 32bit RGBA data
Daniel Gibson

Ok, I followed the simple approach of just making SDL_PIXELFORMAT_RGBA32 an alias of SDL_PIXELFORMAT_RGBA8888/SDL_PIXELFORMAT_ABGR8888, depending on endianess. And I did the same for SDL_PIXELFORMAT_ARGB32, .._BGRA, .._ABGR.

SDL_GetPixelFormatName() will of course return SDL_PIXELFORMAT_RGBA8888 (or SDL_PIXELFORMAT_ABGR8888) instead of SDL_PIXELFORMAT_RGBA32, but as long as that's mentioned in the docs it shouldn't be a problem.
2016-10-11 23:19:05 -07:00