Commit graph

627 commits

Author SHA1 Message Date
Sam Lantinga
56b58afdbe Updated the copyright year to 2015 2015-05-26 06:27:46 -07:00
Alex Szpakowski
2190985ce9 Code style cleanup in the GLES and GLES2 render backends. 2015-05-16 17:35:36 -03:00
Ryan C. Gordon
de88474dda Initial merge of Emscripten port!
With this commit, you can compile SDL2 with Emscripten
( http://emscripten.org/ ), and make your SDL-based C/C++ program
into a web app.

This port was due to the efforts of several people, including: Charlie Birks,
Sathyanarayanan Gunasekaran, Jukka Jylänki, Alon Zakai, Edward Rudd,
Bruce Mitchener, and Martin Gerhardy. (Thanks, everyone!)

--HG--
extra : rebase_source : 97af74c8a5121e926ebe89f123536b5dd6681695
2014-12-18 00:19:52 -05:00
Eric Wing
4c34a1682a Adds support to control the scaling policy/mode of SDL_RenderSetLogicalSize for both letterbox (current behavior) and a new overscan mode (expand to fill the entire screen, even if some parts draw off the screen).
The expected use case is for games that are designed with multiple aspect ratios already in mind and leave optional margins on the edges of the game which won't hurt if they are cut off.

An example use case is a game is designed for wide-screen/16:9, but then wants to deploy on an iPad which is 4:3. Normally, SDL will letterbox, which will shrink things and result in wasted space. But the designer already thought about 4:3 and designed the edges of the game so they could be cut off without any functional loss. So rather than wasting space with letterboxing, "overscan" mode will zoom the rendering to fill up the entire screen. Parts on the edges will be drawn offscreen, but since the game was already designed with this in mind, it is fine. The end result is the iPad (4:3) experience is much better since it feels like a game designed for that screen aspect ratio.

This patch introduces a new SDL_hint: SDL_HINT_RENDER_LOGICAL_SIZE_MODE.
Valid values are "letterbox" or "0" for letterboxing and "overscan" or "1" for overscan.
The default mode is letterbox to preserve existing behavior.

// Example usage:
SDL_SetHint(SDL_HINT_RENDER_LOGICAL_SIZE_MODE, "overscan");
SDL_RenderSetLogicalSize(renderer, SCREEN_WIDTH, SCREEN_HEIGHT);
2014-12-03 04:41:26 -08:00
Alex Szpakowski
38563c490c Fixed SDL_GetRendererOutputSize on iOS when high-DPI mode is enabled on a Retina device.
--HG--
branch : iOS-improvements
2014-12-01 07:31:22 -04:00
David Ludwig
d3886466c4 WinRT: fixed bug whereby offscreen-rendered content could get improperly rotated
Attributes on the host device's rotation were getting applied to offscreen
textures in an invalid manner.  This was causing some apps to look different,
depending on how the device was rotated.

--HG--
extra : rebase_source : 6c4e6b4b6386c34677532d2744d4e351ae6e9be0
2014-10-14 09:53:46 -04:00
Sam Lantinga
f9a36bc6bb Fixed bug 2699 - possible memory leak in GL_RenderReadPixels
Benoit Pierre

If glReadPixels returns an error, than the temporary buffer is not deallocated
2014-08-24 00:02:12 -07:00
Sam Lantinga
e12894a499 Fixed UV texture coordinate scale when using GL_ARB_texture_non_power_of_two 2014-08-18 11:28:16 -07:00
Sam Lantinga
cba9f49587 Fixed bug 2685 - SDL_RenderReadPixels() doesn't work with offscreen targets
Andreas Falkenhahn

SDL_RenderReadPixels() doesn't seem to work when trying to read pixels from a texture that has been created using SDL_TEXTUREACCESS_TARGET and has been selected as the render target using SDL_SetRenderTarget().

I am attaching a small program that demonstrates the issue. I get the following result here:

READ PIXEL RETURN: 0 --- COLOR CHECK: ff000000

But it should be:

READ PIXEL RETURN: 0 --- COLOR CHECK: ffff0000

Tested with SDL 2.0.3 on Windows 7.
2014-08-17 14:44:53 -07:00
Sam Lantinga
cf895bf696 Fixed bug where the render target is updated instead of the default output when the window is resized. 2014-08-17 14:34:41 -07:00
Sam Lantinga
3d8224313f Fixed bug 2681 - dereference a NULL pointer dst_fmt in SDL_CreateTextureFromSurface function
Nitz

In SDL_CreateTextureFromSurface:

SDL_PixelFormat *dst_fmt;
/* Set up a destination surface for the texture update */
         dst_fmt = SDL_AllocFormat(format);
            temp = SDL_ConvertSurface(surface, dst_fmt, 0);

Here is need of NULL check for dst_fmt because there are chances of NULL return from SDL_AllocFormat(format);
2014-08-16 23:30:44 -07:00
Sam Lantinga
5619521805 Fixed bugs 2677 and 2625, made it possible to lock render targets in D3D 2014-08-16 23:17:47 -07:00
Sam Lantinga
bafc5ef326 Take advantage of GL_ARB_texture_non_power_of_two when it's available 2014-08-14 21:31:50 -07:00
Philipp Wiesemann
d0d7ebee0f Fixed warnings about unused local variables. 2014-08-12 23:37:12 +02:00
Sam Lantinga
c7790bdb2b Added NV12 and NV21 texture support for OpenGL and OpenGL ES 2.0 renderers 2014-08-06 11:34:54 -07:00
Sam Lantinga
8d41429a9b Fixed uninitialized variable in some cases 2014-07-27 17:43:36 -07:00
Sam Lantinga
cb2cf20706 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
023d1d048c 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
0e78b5780a 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
fd466cd42f 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
ad1fe92296 Fixed compiler warnings on iOS 2014-07-07 11:00:25 -07:00
Sam Lantinga
9d42bf534d Fixed mingw64 build and warnings 2014-07-07 10:26:28 -07:00
Alfred Reynolds
156e48e6bf The YUV offset is 16 / 255, not 16 / 256 2014-07-03 10:22:12 -07:00
Sam Lantinga
7db8668ef4 Fixed YUV texture update with a subrect in OpenGL ES 2.0 - thanks Sylvain! 2014-06-25 21:06:47 -07:00
Sam Lantinga
b84c11788e 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
efdc9c1d03 Fixes OpenGL ES 2 renderer (Thanks Sylvain Becker) 2014-06-23 09:25:27 -03:00
Sam Lantinga
b13c6bae32 565 textures have higher priority than 555 textures 2014-06-22 09:42:43 -07:00
Sam Lantinga
6905c61819 Restore window OpenGL state if creating an OpenGL renderer fails 2014-06-22 02:48:43 -07:00
Sam Lantinga
2011e44843 Made SDL_PIXELFORMAT_ARGB8888 the default texture format for consistency across renderer implementations. 2014-06-21 21:46:42 -07:00
Sam Lantinga
ac04796154 Fixed compiler warning with new OpenGL ES header files 2014-06-21 12:45:54 -07:00
Sam Lantinga
6a296ae9f2 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 60edb019f0fe (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
ce9a72f4af 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
9043778f18 dront78 implemented YUV texture support for OpenGL ES 2.0 2014-06-07 11:36:08 -07:00
Gabriel Jacobo
c330e8e9e2 Chrome's Native Client backend implementation 2014-06-06 15:45:59 -03:00
Sam Lantinga
4a1537da07 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
297d5c065a 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ø
a7333943a0 SDL_opengl: Fix Mac build with new glext.h 2014-06-04 09:59:10 -07:00
Sam Lantinga
7ab938363f 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
ed89f98f5b Changed C++ style comments. 2014-05-18 21:11:30 +02:00
Gabriel Jacobo
cdc0dfa61c Fixes #2529, guard SDL_d3math.* with the proper defines 2014-05-10 16:23:06 -03:00
David Ludwig
c577e9a890 WinRT: display-information code cleanups 2014-05-09 21:28:52 -04:00
David Ludwig
7246fba47d 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
a7d24ca3a3 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ø
431aca234b 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

--HG--
extra : amend_source : 9e5ac76e3f009d9ae49bc61c350df3ba891267b5
extra : histedit_source : b92b8be4d05b19a89fa0dee57f7ed6b1e924cb99%2Cce419f6ade87bafc78ff42702c1f263d2469e7e7
2014-04-19 13:15:41 -07:00
Philipp Wiesemann
e68f76da43 Removed empty statements. 2014-04-05 23:50:09 +02:00
David Ludwig
0755238527 WinRT: Call IDXGIDevice3::Trim before app-suspend, as required on Windows 8.1
Thanks to Sylvain Becker for pointing this out!
2014-03-24 22:51:03 -04:00
Sam Lantinga
c0e9a9afaf Added an event SDL_RENDER_DEVICE_RESET, which is triggered on Direct3D 11 when the device has been lost and all textures need to be recreated. 2014-03-23 23:09:22 -07:00
Sam Lantinga
ce92ee5307 Fixing Alt-Enter handling, submitted by Nader Golbaz
I encountered a little issue: DXGI monitors application's message queue and this behavior interferes with SDL if the application already handles Alt-Enter sequence. I think it is necessary to disable this behavior.
bb174540%28v=vs.85%29.aspx
2014-03-23 22:53:50 -07:00
David Ludwig
519432a55f D3D11: Fixed a crash after a GPU device-reset on Win32 2014-03-23 16:08:32 -04:00
David Ludwig
48ecbf8800 D3D11: Added code to handle GPU-device-removed scenarios
These scenarios can happen when a GPU is switched, its driver updated, or in
some virtual machines (such as Parallels) are suspended and then resumed.  In
these cases, all GPU resources will already be lost, and it's up to the app to
recover.

For now, SDL's D3D11 renderer will handle this by freeing all GPU resources,
including all textures, and then sending a SDL_RENDER_TARGETS_RESET event.
It's currently up to an app to intercept this event, destroy all of its
textures, then recreate them from scratch.
2014-03-23 13:48:16 -04:00