The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

Presenting the 2.0.2 RELEASE CANDIDATE 1http://www.libsdl.org/tmp/download-2.0.php



We plan to release this early next week, so please download and try this out with your applications.


In addition to many bugs being fixed, here are the major changes since 2.0.1:

General:
* Added SDL_GL_ResetAttributes() to reset OpenGL attributes to default values
* Added an API to load a database of game controller mappings from a file:
    SDL_GameControllerAddMappingsFromFile(), SDL_GameControllerAddMappingsFromRW()
* Added game controller mappings for the PS4 and OUYA controllers
* Added SDL_GetDefaultAssertionHandler() and SDL_GetAssertionHandler()
* Added SDL_DetachThread()
* Added SDL_HasAVX() to determine if the CPU has AVX features
* Added SDL_vsscanf(), SDL_acos(), and SDL_asin() to the stdlib routines
* EGL can now create/manage OpenGL and OpenGL ES 1.x/2.x contexts, and share
  them using SDL_GL_SHARE_WITH_CURRENT_CONTEXT
* Added a field "clicks" to the mouse button event which records whether the event is a single click, double click, etc.
* The screensaver is now disabled by default, and there is a hint SDL_HINT_VIDEO_ALLOW_SCREENSAVER that can change that behavior.
* Added a hint SDL_HINT_MOUSE_RELATIVE_MODE_WARP to specify whether mouse relative mode should be emulated using mouse warping.
* testgl2 does not need to link with libGL anymore
* Added testgles2 test program to demonstrate working with OpenGL ES 2.0
* Added controllermap test program to visually map a game controller


Windows:
* Support for OpenGL ES 2.x contexts using either WGL or EGL (natively via
  the driver or emulated through ANGLE)
* Added a hint SDL_HINT_VIDEO_WIN_D3DCOMPILER to specify which D3D shader compiler to use for OpenGL ES 2 support through ANGLE
* Added a hint SDL_HINT_VIDEO_WINDOW_SHARE_PIXEL_FORMAT that is useful when creating multiple windows that should share the same OpenGL context.
* Added an event SDL_RENDER_TARGETS_RESET that is sent when D3D9 render targets are reset after the device has been restored.


Mac OS X:
* Added a hint SDL_HINT_MAC_CTRL_CLICK_EMULATE_RIGHT_CLICK to control whether Ctrl+click should be treated as a right click on Mac OS X. This is off by default.


Linux:
* Fixed fullscreen and focused behavior when receiving NotifyGrab events
* Added experimental Wayland and Mir support, disabled by default


Android:
* Joystick support (minimum SDK version required to build SDL is now 12,
  the required runtime version remains at 10, but on such devices joystick
  support won't be available).
* Hotplugging support for joysticks
* Added a hint SDL_HINT_ACCEL_AS_JOY to control whether the accelerometer should be listed as a 3 axis joystick, which it will by default.

Any chance you can look at my patch in bug 2197 "OpenGL 3.3 on OS X Mavericks"?

Hey Sam, is it possible in the future to add support for detaching a
window cleanly which was created via CreateFrom. I have an issue with
OGRE windows SDL is attached to locking up on SDL_HideWindow, even if
I could, I imagine OGRE would take issue to the window not existing
anymore. It would help if I could just detach SDL (without destroying
or hiding it) from the window then let OGRE clean it up. Right now I
just do not SDL_Quit and it leaves a tiny bit of non cleaned up memory
around. Basically I want an inverse of SDL_CreateWindowFrom.

On Sat, Mar 1, 2014 at 5:41 PM, Daniel C. Sinclair
wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 3/1/14, 5:41 PM, Daniel C. Sinclair wrote:

Just pushed your patch, it'll be in RC2 or whatnot.

--ryan.



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

This fix is in the latest 2.0.2 RC upload.


On Sat, Mar 1, 2014 at 6:40 PM, Ryan C. Gordon wrote:

Andre, please submit a bug to bugzilla.libsdl.orgFeel free to attach a suggested API and implementation as well.



On Sat, Mar 1, 2014 at 6:34 PM, Andre D wrote:

hello, quick question, i have a PSP that i turned into a basic joystick with a homebrew (FuSa), so, SDL detect all the buttons but the Hat and the Axis events are backwards, so the hat in the psp gives me the axis motion event, is there anything i can do to fix this, i know i can just use the special condition base on the name of the joystick, i was just wondering about it.



2014-03-01 20:12 GMT-07:00 Sam Lantinga:



--
Javier Flores

Hi. There are some problems I’ve noticed with the latest fullscreen changes for OS X (commit a2910aa6c056).

* When in fullscreen with a resizable FULLSCREEN_DESKTOP window, the top menubar and the bottom dock become visible and clickable when the mouse is moved to those locations. I really don’t want this to happen for some games (it interferes with the normal operation of the game if the mouse is used) - but it might be fine with others.

* When in fullscreen with a non-resizable FULLSCREEN_DESKTOP window, the top menubar sometimes appears if I go into OS X’ MIssion Control mode and then back to that Space. Sometimes it doesn’t appear but causes a visible performance hitch when my mouse goes to that location.

* When in fullscreen with a FULLSCREEN_DESKTOP window, SDL_SetWindowFullscreen to exit fullscreen doesn’t work properly.

* Weird stuff happens if I destroy and recreate a window while it’s transitioning into a Space - the user might be presented with an empty Space with the actual window in a new different Space.

Personally I’d much prefer the “old” fullscreen-desktop behaviour over the many odd corner-case issues that the “new” behaviour introduces.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Well, the code is like an hour old, so we probably have bugs.

I'm looking at this list today, I think these can all be fixed quickly.

--ryan.



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I would actually suggest creating the SDL 2 window yourself and simply tell OGRE the GL Context to use.. (This is what I did with Ogre 1.6.5 in Torchlight on linux). As doing the reverse just caused issues.. In another game I’m porting right now using Ogre 1.7.x I simply just added native SDL2 support into OGRE so it creates a proper SDL2 window. (and severely reduces dependencies on linux for OGRE). If you want some patches for that shoot me an email off list and I can share patches with you.

On Mar 1, 2014, at 9:34 PM, Andre D wrote:


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Yeah, I ended up just using the child window parameter
(parentWindowHandle). This way OGRE can create and manage the GL
context itself, but SDL can manage and own the parent window. Only
downside is I have to resize the ogre window when the SDL window is
resized..which is exactly one event handler with one line of code.
There is no OSX support for parentWindowHandle, but for that I can
just use externalWindowHandle (deprecated on other platforms) and deal
with any oddities from that.


On Sun, Mar 2, 2014 at 3:05 PM, Edward Rudd wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hey Edward, are the OGRE guys interested in taking your patches upstream? If not, is there any deficiency in SDL that is preventing that?


On Sun, Mar 2, 2014 at 12:05 PM, Edward Rudd wrote:

I understand, I’m just a bit nervous because it’s being introduced so close to 2.0.2’s release and the 10.7+ fullscreen experience introduces so many potential edge case issues.

Here are a few more as of the latest changes (commit 36f8cf82d308):

* Switching from windowed-resizable to fullscreen-desktop with the top-right button on the window still shows the menubar when I mouse over the area - until I command-tab away and back. But after command-tabbing back, the dock icons are now visible and don’t go away… until I enter Mission Control via a hotkey. Then if I go back, the dock and menubar auto-show on mouse over again.

* I have a windowed-resizable window, and my game destroys and recreates the window when the F key is pressed. If I press control-command-F (the hotkey to enter fullscreen as shown in View -> Enter Full Screen in the menubar), two new Spaces are created: one with the window in it, and an empty grey one. The active one is the empty one, unfortunately.

* If I have a windowed window and enter fullscreen-desktop via SDL_SetWindowFullscreen, and then command-tab out and back in, the screen flashes once before the dock and menubar are hidden (this one isn’t such a big deal.)

On Mar 2, 2014, at 3:41 PM, Ryan C. Gordon wrote:


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

It’s addition did seem quite sudden.. Tomorrow I’m going to checkout and build it and run it through it’s courses on my 4 mac computers.. (running between 10.6 and 10.9) and make sure they aren’t any surprises I see.

On Mar 2, 2014, at 8:21 PM, Alex Szpakowski wrote:


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I haven’t gotten it fully finished and rounded out (it’s enough for the game I’m working on the the moment).. My plan was to polish off any remaining bits while finishing the port and contribute it upstream to OGRE.

On Mar 2, 2014, at 3:42 PM, Sam Lantinga wrote:

To be fair, most of the functionality has been in the codebase for a few months (only accessible via a hint until today though) - and even before that as a bugzilla issue: https://bugzilla.libsdl.org/show_bug.cgi?id=2223


Speaking as a user of Mac games which use SDL, I definitely want the functionality in… but only if it doesn’t cause nasty issues.

On Mar 2, 2014, at 10:48 PM, Edward Rudd wrote:

As one who ports many many games to Mac + Linux I want that as well.
On Mar 2, 2014, at 9:52 PM, Alex Szpakowski wrote:

The RC has been updated with the spaces fixes Ryan worked on today.

Known issues:
* Using Command+Tab to switch to an SDL app in spaces mode causes a white flash for one frame
* Destroying an SDL window while in transition causes weird issues.


Neither of these are showstoppers, and will be looked at for 2.0.3 - if you dig in and know of fixes, please let Ryan know.


Please let us know if you find other problems!





On Sun, Mar 2, 2014 at 6:52 PM, Alex Szpakowski wrote:

These changes broke my test code. Using FULLSCREEN_DESKTOP with OpenGL was working fine and I could command-tab in and out with no problems. It was really fast to switch back and forth between programs.

Now on starting my program I get a weird black rectangle that zooms to full screen while a white/gray bottom quarter of the screen fades to black. The screen stays black and nothing I render shows up. If I command-tab out and back in, nothing is displayed at all (I still see program I switched away from). Switching back and forth is slow because of the horizontal scrolling effect.


Maybe I'm not doing something correctly. Everything worked before so I never read much documentation regarding full screen stuff. Does anyone have example code showing how to handle full screen properly?






On Sun, Mar 2, 2014 at 6:48 PM, Edward Rudd wrote:

What version of Mac OS X are you running?

Do the SDL test programs work correctly for you?
testsprite2 --resize --fullscreen-desktop
testgl2 --resize --fullscreen-desktop


Thanks!



On Sun, Mar 2, 2014 at 10:21 PM, Daniel C. Sinclair wrote:

I’ve found more things!

* If I…
- create a windowed window,
- use SDL_SetWindowFullscreen to go into fullscreen-desktop mode,
- command-tab away, command-tab back,
- and then use SDL_SetWindowFullscreen again to go back to windowed mode,
the window will now be “above” a lot of things, including the program list visible when command-tab is held. It seems like the window is still set to the “shielding” window level, even though it’s in windowed mode so it shouldn’t be.

* If I press the fullscreen button on a windowed-resizable window to get to fullscreen-desktop mode, the menubar is still visible (and the dock too, if I click) when I mouse over those areas. In some ways it makes sense for that to happen, since the window going fullscreen is not in the application’s hands - but at the same time it’s inconsistent with SDL_SetWindowFullscreen (and it might not be what I as a game developer want.)

* If a windowed-resizable window is put into a fullscreen Space with the button, its window flags aren’t updated to reflect the fact that it’s now in fullscreen-desktop mode. Like the above point though, this might make sense because fullscreen-desktop mode was never explicitly requested by the SDL program, so it could be argued that the window isn’t “really” in fullscreen-desktop mode.

* When a window is in a fullscreen Space via programmatic means (SDL_SetWindowFullscreen etc.) and the Space is active, the program list shown with command-tab isn’t visible as it should be.
I believe this can be fixed by changing the level set when entering fullscreen from CGShieldingWindowLevel() to something like NSMainMenuWindowLevel+1 instead.
However, I remember experimenting with that a few months ago and I got a minor decrease in performance with that compared to the current CGShieldingWindowLevel() (and compared to exclusive-fullscreen mode.) It might be worth benchmarking any changes to this.

On Mar 3, 2014, at 2:10 AM, Sam Lantinga wrote:


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Yay!!


Your diagnosis is correct, I'll fix this today.


Sam and I talked about this last night, and here's what we decided:

Clicking that icon is a user-activated choice. They can simply not click
it if it causes problems with a specific game, which is really
hand-wavey for me to say, I know, but if we hide the menubar in this
scenario, once they click the button they'll be stuck there, which is
different from when a game creates a fullscreen window (as games are
assumed to provide their own UI to change video modes and/or quit the game).

When a game goes fullscreen, that's an understood contract with the
user. When a user clicks that button, that's a different UI
contract...they still want their Dock and Menu Bar.

I know there are arguments both ways for it, and games always walk this
strange line between UI standards and complete control of the machine,
but for now we came down on the side of keeping this as-is. If this
turns out to be really traumatic for developers, we can add a way to
flag a window as resizable-but-not-fullscreenable, so that button goes
away, but I want that to be a last resort...making a resizable game work
nicely with Spaces, even if it means moving some UI elements around a
little, makes for happier Mac users.


Yeah, it's not meant to be in fullscreen desktop mode, as far as the app
is concerned...it's closer to "maximized" if we're going to overload a
window state, because the app just thinks it got resized, but that's
questionable too. Sam, what do you think is the right approach here?


I intend to leave it at Shielding level, at least for 2.0.2, but we
should definitely revisit this.

(I imagine we used shielding level to avoid UI stuff from interfering
with fullscreen windows, and it's likely faster because the Compositor
doesn't ever have to, uh, composite.)

--ryan.


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

FYI: just added a hint to opt out of the new Spaces code. We'd like
people to try it and report bugs, but still have an exit strategy if it
totally doesn't work for you, or you can't handle a resizable window
having a fullscreen button, etc.

--ryan.


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

There's a couple of serious issues around CreateTexture and CreateTextureFromSurface on 2.01 which I've put into bugzilla. Would be nice to have those fixed.

Will this be fixed before 2.0.2’s release? I noticed 2.0.2 got tagged on Mercurial a few minutes ago...

On Mar 3, 2014, at 1:31 PM, Ryan C. Gordon wrote:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

No, it'll be fixed after the 2.0.2 release.


On Fri, Mar 7, 2014 at 11:37 PM, Alex Szpakowski wrote:

This is a major breaking issue for me, so I’ve made a hacky quick-fix for myself which seems to work OK (after only a couple minutes of testing though.)


If anyone else is interested, it just adds one line - but it might not consider some scenarios.





diff --git a/src/video/cocoa/SDL_cocoawindow.m b/src/video/cocoa/SDL_cocoawindow.m
--- a/src/video/cocoa/SDL_cocoawindow.m
+++ b/src/video/cocoa/SDL_cocoawindow.m
@@ -587,6 +587,8 @@

inFullscreenTransition = NO;

+ [nswindow setLevel:NSNormalWindowLevel];
+
if (pendingWindowOperation == PENDING_OPERATION_ENTER_FULLSCREEN) {
pendingWindowOperation = PENDING_OPERATION_NONE;
[self setFullscreenSpace:YES];



On Mar 8, 2014, at 3:42 AM, Sam Lantinga wrote: