Commit Graph

31 Commits

Author SHA1 Message Date
Sam Lantinga
6fef39d6b8 Added NV12 and NV21 texture support for OpenGL and OpenGL ES 2.0 renderers 2014-08-06 11:34:54 -07:00
Sam Lantinga
5c6c86912d Fixed uninitialized variable in some cases 2014-07-27 17:43:36 -07:00
Sam Lantinga
dfc7535ff7 Fixed bug 2657 - Memory leak in GL_CreateTexture function
Nitz

In GL_CreateTexture function:

if (GL_CheckError("glGenTexures()", renderer) < 0) {
        SDL_free(data);
        return -1;
    }

Here only data is getting free but data->pixels getting leak.
So have to free data->pixels before free data.
2014-07-26 16:52:26 -07:00
Sam Lantinga
96b613eab3 Fixed bug 2640 - Unable to SDL_SetRenderTarget to original surface for software renderer without a window
Damian Kaczmarek

Basically this bug is probably not a common use case. My goal is to allow rendering totally without a window, for example to a screenshot and I need to rely on SDL_SetRenderTarget to properly work for a purely software renderer created by SDL_CreateSoftwareRenderer.
2014-07-13 09:04:55 -07:00
Sam Lantinga
fd1da994fa Fixed bug 2639 - SDL_BLENDMODE_BLEND not working properly for software renderer, thanks to Melker Narikka 2014-07-12 16:21:56 -07:00
Sam Lantinga
d23d9c88e5 Fixed bug 2421 - SDL_RenderCopyEx off by one when rotating by 90 and -90
chasesan

When using SDL_RenderCopyEx, I get a problem on some platforms where the output is offset by +/-1 on other platforms and not on others. I tried it with a center of both 0,0 (and offsetting by width/height) and NULL (for centered).

The rotation involved is 90, and/or -90 rotation. The rotation was a constant, no arithmetic was involved when inputting it into SDL_RenderCopyEx.

This occurred with 32x32, 24x24, and 16x16 texture sizes. I apologize that I don't have more precise information, as I received the information as a bug report myself. But I have tracked the problem down to here.

My program requires pixel perfect alignment on several different platforms, so this is something of a showstopper for me.

--

Sylvain

It appears the RenderCopyEx is done as expected,
this is the red rectangle which is not correctly positionned !

So, here's patch with a 0.5 float increment, like for opengles2, for DrawLines, and also Draw Points.
2014-07-07 23:26:34 -07:00
Sam Lantinga
7187b74cf4 Fixed compiler warnings on iOS 2014-07-07 11:00:25 -07:00
Sam Lantinga
1ee96bb994 Fixed mingw64 build and warnings 2014-07-07 10:26:28 -07:00
Alfred Reynolds
2748e28230 The YUV offset is 16 / 255, not 16 / 256 2014-07-03 10:22:12 -07:00
Sam Lantinga
3d5f4a6901 Fixed YUV texture update with a subrect in OpenGL ES 2.0 - thanks Sylvain! 2014-06-25 21:06:47 -07:00
Sam Lantinga
b4deeeba05 Fixed bug 2595 - Padded, non-contiguous YUV does not display correctly using OpenGL ES 2.0 renderer
Sylvain

Ok, I found out : GLES2_UpdateTexture is just not handling the YUV, I will attach a patch.
2014-06-25 00:58:40 -07:00
Gabriel Jacobo
e63e1a5e64 Fixes OpenGL ES 2 renderer (Thanks Sylvain Becker) 2014-06-23 09:25:27 -03:00
Sam Lantinga
1b3d4e6d0e 565 textures have higher priority than 555 textures 2014-06-22 09:42:43 -07:00
Sam Lantinga
d65ac7785f Restore window OpenGL state if creating an OpenGL renderer fails 2014-06-22 02:48:43 -07:00
Sam Lantinga
5df11f8aa1 Made SDL_PIXELFORMAT_ARGB8888 the default texture format for consistency across renderer implementations. 2014-06-21 21:46:42 -07:00
Sam Lantinga
62bdecc80c Fixed compiler warning with new OpenGL ES header files 2014-06-21 12:45:54 -07:00
Sam Lantinga
e8f8e6727a Fixed bug 2595 - Padded, non-contiguous YUV does not display correctly using OpenGL ES 2.0 renderer
Alvin

The new OpenGL ES 2.0 YUV Texture support does not correctly display padded, non-contiguous YUV data.

I am using SDL2 95bd3d33482e (as provided by 'hg id --id') from Mercurial.

The YUV data I am using is provided by the FFMPEG family of libraries. According to FFMPEG's documentation, "The linesize [pitch] may be larger than the size of usable data -- there may be extra padding present for performance reasons."

The dimensions of the video file that I am using are 480x360. What I get from FFMPEG is a Ypitch of 512, and Upitch and Vpitch are both 256.

When I pack new Y, U and V buffers with only the "usable" data (Ypitch is 480 and Upitch and Vpitch are both 240), and use those new buffers, the image is display correctly.

It appears that the Ypitch, Upitch and Vpitch parameters are not being used by SDL_UpdateYUVTexture().

I use SDL_PIXELFORMAT_YV12 for my YUV texture, however, the same results are seen when I use SDL_PIXELFORMAT_IYUV.

Not sure if this is related or not, but when I render the YUV texture (padded and unpadded) to a RGB24 texture, the resulting image is greyscale (or could by just the Y channel).

The URL field for this bug entry is set to my email (SDL mailing list archive) which includes an example image of what I see when rendering padded, non-contiguous YUV data.
2014-06-21 12:38:46 -07:00
Sam Lantinga
af50403e50 Fixed bug 2575 - Current GL context tracking fails
Ronie Salgado

The GL Renderer current context tracking fails when one window is used with an SDL renderer but another separate window is used with a user handled OpenGL context.

Attached is a small program that reproduces this bug, at least in some Linux machines where an OpenGL renderer is provided by default.

Expected Output:
-"First window" should be blue.
-"Second window" should be green.

Gotten Output:
- "First window" black.
- "Second window" blue.

What happened:
The renderer created for the "first window" ends rendering into the "second window" OpenGL context.

Bug location:

SDL_render_gl.c - line 286 on hg:
static SDL_GLContext SDL_CurrentContext = NULL;

When making SDL_GL_MakeCurrent from the user perspective, that variable or the GL renderer is not notified about the OpenGL context change.

Solution proposal:
- Move the current GL context cache into another place global.
2014-06-15 18:09:39 -07:00
Sam Lantinga
9fb2cc10c0 dront78 implemented YUV texture support for OpenGL ES 2.0 2014-06-07 11:36:08 -07:00
Gabriel Jacobo
1e352d7929 Chrome's Native Client backend implementation 2014-06-06 15:45:59 -03:00
Sam Lantinga
4fd03b9582 Setting the window size changes the fullscreen display mode, unless a window display mode has been set.
Testing:
* Ran testsprite2 --fullscreen, used Ctrl+ and Ctrl- to change window sizes, verified that the display mode changed as well.
2014-06-04 10:57:52 -07:00
Sam Lantinga
c15e26d77d Fixed crash and lost pixel data when recovering from a lost device situation (e.g. alt-tab from fullscreen) 2014-06-04 10:57:40 -07:00
J?rgen P. Tjern?
d623c0b443 SDL_opengl: Fix Mac build with new glext.h 2014-06-04 09:59:10 -07:00
Sam Lantinga
49c53fd280 Use D3D9Ex when available
This hopefully works around crashes in Intel D3D9 support in Windows 8.1.
2014-05-31 11:37:12 -07:00
Philipp Wiesemann
9bc47465ca Changed C++ style comments. 2014-05-18 21:11:30 +02:00
Gabriel Jacobo
fb389950a7 Fixes #2529, guard SDL_d3math.* with the proper defines 2014-05-10 16:23:06 -03:00
David Ludwig
164e5b89d5 WinRT: display-information code cleanups 2014-05-09 21:28:52 -04:00
David Ludwig
0a879d63bd Fixed rendering-alignment issues on WinPhone 8.1, when the device was rotated
If a Windows Phone 8.1 device was rotated to anything but Portrait mode,
the Direct3D 11 renderer's output wouldn't get aligned correctly with the
screen.
2014-05-09 20:16:21 -04:00
David Ludwig
ec5f6ad595 WinRT: suppressed an unused param warning when building for Windows Phone 8.1 2014-04-30 21:12:47 -04:00
J?rgen P. Tjern?
defd90b6f6 Render: Allow empty cliprect.
This fixes an issue where an empty cliprect is treated the same as a NULL
cliprect, causing the render backends to disable clipping.

Also adds a new API, SDL_RenderIsClipEnabled(render) that allows you to
differentiate between:
 - SDL_RenderSetClipRect(render, NULL)
 - SDL_Rect r = {0,0,0,0}; SDL_RenderSetClipRect(render, &r);

Fixes https://bugzilla.libsdl.org/show_bug.cgi?id=2504
2014-04-19 13:15:41 -07:00
David Ludwig
3dcb451f85 Added a README file regarding WinRT support
To note, this file is currently formatted with CRLF line endings, rather than
LF, to allow the file to be viewed with Notepad.
2014-04-09 21:29:19 -04:00