kc3-lang/SDL/src/video/winrt
Branch :
Log
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
 |
f5d43cf9 | 2016-08-31 12:52:55 | WinRT: added an extra NULL pointer check for SDL_*ScreenSaver() backend code | |
|
5020fe8f | 2016-08-29 20:27:21 | WinRT: added SDL_*ScreenSaver() support; fixed crash when restoring app from screensaver | |
|
5150eb36 | 2016-08-20 13:46:45 | WinRT: fixed bug where Win10 GameBar, when shown + hidden, might not restore a cursor's hidden state The repro steps were this: 1. run an sdl2 winrt/uwp app, on Win10, v10.0.10586.0 or higher 2. hide the cursor, via a call to SDL_ShowCursor(0) 3. make the Win10 game bar appear, by pressing the Windows + G hotkey 4. observe that the mouse cursor appears, in order to interact with the game bar (this is expected behavior) 5. make the Win10 game bar disappear, either by pressing the Windows + G hotkey again, or clicking somewhere in the app EXPECTED RESULT: cursor disappears, as game bar disappears ACTUAL RESULT: cursor didn't always disappear | |
 |
9f97ee8a | 2016-08-03 22:32:02 | WinRT: Removed not needed SDL_zerop() after SDL_calloc(). SDL_calloc() already sets memory to zero. | |
|
441359bd | 2016-05-14 23:29:49 | WinRT: workaround a possible Windows bug, whereby hiding cursors, disables mouse-moved events This workaround, unfortunately, requires that apps directly link to a set of Win32-style cursor resource files (that contain a transparent cursor image). Copies of suitable resource files are in src/core/winrt/, and should be included directly in an app's MSVC project. A rough explanation of this workaround/hack, and why it's needed (and seemingly can't be done through programmatic means), is in this change's code. | |
|
52fec6af | 2016-05-07 21:41:59 | WinRT: allow on-screen keyboard to be shown via SDL APIs, Win10/UWP only | |
|
caf152de | 2016-04-13 21:59:50 | WinRT: build/link fix | |
 |
9b4db2b8 | 2016-04-12 18:11:36 | Patched to compile on various platforms. | |
|
c61675dc | 2016-04-12 16:45:10 | threads: Move SDL's own thread creation to a new internal API. This allows us to set an explicit stack size (overriding the system default and the global hint an app might have set), and remove all the macro salsa for dealing with _beginthreadex and such, as internal threads always set those to NULL anyhow. I've taken some guesses on reasonable (and tiny!) stack sizes for our internal threads, but some of these might turn out to be too small in practice and need an increase. Most of them are simple functions, though. | |
|
0c923fda | 2016-03-10 21:00:44 | WinRT: Removed dead code and fixed memory leak if allocation for driver failed. | |
 |
42065e78 | 2016-01-02 10:10:34 | Updated copyright to 2016 | |
|
44c0b2da | 2015-12-31 01:54:11 | WinRT: minor code-comment cleanups | |
|
8281cc72 | 2015-12-22 00:58:47 | WinRT: Fixed bug 3210, "alt-tab doesn't work correctly with full-screened, UWP (Win10 Store) apps" | |
|
976bc9a9 | 2015-12-06 18:48:46 | WinRT: build fix for Windows Phone 8.0 | |
|
2b484818 | 2015-12-06 18:42:30 | WinRT: enabled the Win10-Store Cert Kit bug-workaround, for Windows 8.0 apps | |
|
a40d49aa | 2015-12-06 18:33:43 | WinRT: enabled the Win10-Store Cert Kit bug-workaround, for Windows 8.1 apps | |
|
898054a1 | 2015-12-06 17:32:33 | WinRT: fixed a build error when compiling Windows 8.1 .dlls | |
|
c8e3bfbf | 2015-12-06 17:07:37 | WinRT: removed an unused variable from DXGI-based display-detection code | |
|
781455fd | 2015-12-06 17:06:40 | WinRT: workaround for a possible bug in the Win10 Store's Certification Kit DXGI fails to report any displays in at least one of the "Windows App Certification Kit 10.0"'s tests for Store Apps. This was causing SDL's video initialization code to fail, when the suspect test ("Direct3D Feature Test") was run, as DXGI was unable to report a display-output at adapter-index 0, output-index 0. The workaround that is applied here attempts to detect this case, then use a hopefully-reasonable alternative means to calculate at least one display output. | |
|
25abce51 | 2015-11-29 19:33:11 | WinRT: added Win10/UWP (Universal Windows Platform) support "UWP" appears to be Microsoft's new name for WinRT/Windows-Store APIs. This set of changes updates SDL's WinRT backends to support the Win10 flavor of WinRT. It has been tested on Win10 on a desktop. In theory, it should also support Win10 on other devices (phone, Xbox One, etc.), however further patches may be necessary. This adds: - a set of MSVC 2015 project files, for use in creating UWP apps - modifications to various pieces of SDL, in order to compile via MSVC 2015 + the Win10 API set - enables SDL_Window resizing and programmatic-fullscreen toggling, when using the WinRT backend - WinRT README updates | |
|
d07aa877 | 2015-11-26 11:15:43 | WinRT: minor code cleanup in window-creation code Window flags can be detected on all WinRT platforms. | |
|
a70fe9a5 | 2015-11-26 11:09:50 | WinRT: native windows are inherently resizable (in WinRT 8.x) | |
|
7bd640d5 | 2015-11-26 02:37:51 | WinRT: bug-fix, fullscreen mode wasn't getting reported in Windows 8.0 apps This bug did not occur in Windows 8.1 apps, just Windows 8.0. | |
|
36090f57 | 2015-11-26 02:13:15 | WinRT: bug-fix, OpenGLES2 was failing to init, after recent windowing fixes Some SDL_Window flags were getting lost inside WINRT_UpdateWindowFlags, namely SDL_WINDOW_OPENGL. | |
|
f5209944 | 2015-11-26 01:36:36 | WinRT: bug-fix, fullscreen window flags weren't set if device was rotated 90 degrees | |
|
623898f7 | 2015-11-26 00:41:39 | WinRT: lots of display and windowing related fixes This change-set fixes a lot of windowing related bugs, especially with regards to Windows 8.x apps running on Windows 10 (which was the driver for this work). The primary fixes include: * listed display modes were wrong, especially when launching apps into a non-fullscreen space * reported window flags were often wrong, especially on Windows 10 * fullscreen/windowed mode switches weren't failing (they are not programmatically possible in Win 8.x apps). | |
|
0e45984f | 2015-06-21 17:33:46 | Fixed crash if initialization of EGL failed but was tried again later. The internal function SDL_EGL_LoadLibrary() did not delete and remove a mostly uninitialized data structure if loading the library first failed. A later try to use EGL then skipped initialization and assumed it was previously successful because the data structure now already existed. This led to at least one crash in the internal function SDL_EGL_ChooseConfig() because a NULL pointer was dereferenced to make a call to eglBindAPI(). |