Opened 11 years ago

Closed 9 years ago

Last modified 4 years ago

#2041 closed enhancement (fixed)

SDL2 Support

Reported by: historic_bruno Owned by:
Priority: Release Blocker Milestone: Alpha 17
Component: Core engine Keywords: patch
Cc: againsttcpa84@…, Josh Patch:

Description (last modified by elexis)

This ticket is now closed, please report SDL2 issues in new tickets and see the references below.

This ticket is for working on SDL2 support (first stable release on 2013-08-13). Doc for 1.2 -> 2.0 migration here.

Known problems:

  • SDL1 regressions
    • None?!
  • SDL2 issues
    • All platforms:
      • [MEDIUM] Can't set resolution in fullscreen mode, as a workaround to fix buggy fullscreen to windowed transition #2845
      • [MEDIUM] Hotkey behavior differences with non-QWERTY keyboard layouts #2850
      • [LOW] Atlas text input broken #2846
      • [LOW] Text input testing and verification, especially CJK languages w/ IMEs
    • Windows:
      • [HIGH] System beep sound in windowed mode, when pressing Alt hotkeys, patch submitted upstream
      • [MEDIUM] Issues switching to windowed mode after starting fullscreen - window appears not resizable and doesn't have menu bar (similar to OS X issues)
      • [MEDIUM] Crash with IME using some input modes and backspace
      • [LOW] Difficulty debugging in VS #2849
      • [LOW] IME input mostly broken (should handle SDL_TEXTEDITING events and use SDL_SetTextInputRect)
    • Linux:
      • [BLOCKING] Atlas is broken with failing GL init #2847
      • [MEDIUM] Mouse cursor corruption: #2823
      • [LOW] Mouse tilt broken / not rotating map #2848
    • OSX:
      • [HIGH] Cursor offset on Mavericks (VM) #2851
      • [MEDIUM] Fullscreen buggy #2852
      • [MEDIUM] Needs testing on Retina displays, I've seen reports that recent SDL2 is buggy on them

Attachments (1)

0001-First-pass-at-SDL2-support.patch (8.2 KB ) - added by julian37 10 years ago.
Patch against r14495 to build with SDL2 (2.0.1)

Download all attachments as: .zip

Change History (109)

comment:1 by ben, 11 years ago

In 13572:

Fixes a build error with SDL2, refs #2041

in reply to:  description comment:2 by historic_bruno, 11 years ago

Replying to historic_bruno:

  • Text input has changed in SDL2 to better support CJK, see TextInput tutorial and this forum topic. Basically Unicode characters may take multiple key presses to generate and we're now expected to use the text input API. In particular, SDL_Keysym.unicode is used by all text input in the game, but that was deprecated and has now been removed in the latest RC.

Looked into this a bit more, and it's not as significant a change as I was expecting. Text input events will typically contain only single characters in UTF-8 encoding, roughly the same as the old SDL_Keysym.unicode, so it needs a conversion from UTF-8 to wide chars, but also a loop in case of multiple characters per event (or we can assert that there is only one).

I added some text input event handling to CConsole and CInput, and got basic input working (with the nice bonus of supporting Alt codes in Windows, allowing entry of special Unicode characters not available on the keyboard). Now there is an issue with backquote (`) and tilde (~) opening the console when an input box has focus, this is probably due to the old keydown event being handled in addition to the new text input event. And it remains to be tested on Linux and OS X.

comment:3 by fabio, 11 years ago

Description: modified (diff)

comment:4 by fabio, 11 years ago

Description: modified (diff)

comment:5 by Michael, 10 years ago

Cc: againsttcpa84@… added

comment:6 by historic_bruno, 10 years ago

Should test if SDL2 fixes #2146 as well as #1733.

comment:7 by julian37, 10 years ago

Using SDL2 fixes #1593 in my tests.

@historic_bruno: where are your text input event handling additions?

I've made a rough first patch to build with SDL2 against r14495, it sounds like it overlaps what you've been doing but perhaps you find it useful.

by julian37, 10 years ago

Patch against r14495 to build with SDL2 (2.0.1)

comment:8 by Niek, 10 years ago

It seems to me that OpenGL 2.1 is no longer supported with SDL2 / gives a lot of trouble? (See the featurelist in the migration doc)

Upgrading to OpenGL 3.0 could solve OpenGL-related issues.

in reply to:  8 comment:9 by historic_bruno, 10 years ago

Replying to niektb:

It seems to me that OpenGL 2.1 is no longer supported with SDL2 / gives a lot of trouble? (See the featurelist in the migration doc)

Upgrading to OpenGL 3.0 could solve OpenGL-related issues.

Which OpenGL issues? Do you mean issues we have or issues in SDL? We don't use SDL for its graphics API, it only creates the GL context, as far as I know we can specify the version we want (and in fact our current SDL2 code path does so, with SDL_GL_SetAttribute). Any documentation that says we can't do what we're doing would be good to see :)

Last edited 10 years ago by historic_bruno (previous) (diff)

in reply to:  7 comment:10 by historic_bruno, 10 years ago

Replying to julian37:

Using SDL2 fixes #1593 in my tests.

@historic_bruno: where are your text input event handling additions?

I've made a rough first patch to build with SDL2 against r14495, it sounds like it overlaps what you've been doing but perhaps you find it useful.

Rather than attaching a patch, I made a git branch: https://github.com/historicbruno/0ad/commits/sdl2-support

You can see there is indeed some overlap, some of the fixes are trivial to get it compiling. The biggest effort IMO will be getting text input and hotkeys (and places where both are needed) working the same as it does with SDL 1.2 - or at least to a point we can agree is correct and consistent.

Last edited 10 years ago by historic_bruno (previous) (diff)

comment:11 by historic_bruno, 10 years ago

Milestone: BacklogAlpha 17

I would like this to get into A17, it fixes a number of bugs on Windows and makes the OS X experience nicer as well. I'm not sure if we want to require everyone to use SDL2 yet, so maybe it should be a premake/build option (like --with-sdl2) until we get more feedback. I can build and test the Windows libs, if others can test more thoroughly on Linux and OS X.

comment:12 by historic_bruno, 10 years ago

Important things to note are behavior of cursors, hotkeys, text input, and multiple displays, in addition to basic compile and run testing.

comment:13 by Philip Taylor, 10 years ago

I'm not sure if we want to require everyone to use SDL2 yet

I think we should continue to support Ubuntu 12.04 for the foreseeable future (since it's still supported by Ubuntu, and ~10% of our players since the start of this year were using it). The libsdl2-dev package wasn't added until 13.10, and bundling or backporting libraries is nasty, so maintaining SDL1 support in our code for the next couple of years is probably the less painful approach.

in reply to:  11 comment:14 by fabio, 10 years ago

Replying to historic_bruno:

I can build and test the Windows libs, if others can test more thoroughly on Linux and OS X.

Is the github branch ready to be tested? That one is very old (2013).

comment:15 by wraitii, 10 years ago

Moving to SDL2 fixes the OSX crash with Atlas entirely (see #2650).

comment:16 by fabio, 10 years ago

BTW libsdl2 can be easily backported (from debian sid) to Ubuntu 12.04, I did it here. Also, there are already 5 backported packages for 12.04 in the PPA, see here, we could add another one.

Last edited 10 years ago by fabio (previous) (diff)

comment:17 by leper, 10 years ago

Priority: Should HaveMust Have

in reply to:  15 comment:18 by historic_bruno, 10 years ago

Replying to wraitii:

Moving to SDL2 fixes the OSX crash with Atlas entirely (see #2650).

Annoyingly, it broke Atlas on Linux, I just remembered that, but I didn't test with wxWidgets 3.0, and it's possible the latest SDL2 magically fixes that too.

comment:19 by Stan, 10 years ago

Any update on this ? If we could fix atlas on all platforms, that would probably bring more interest, since we have triggers now

comment:20 by historic_bruno, 10 years ago

sdl2-support branch is now rebased and updated for latest SVN, with SDL 2.0.3 binaries for Windows testing. Pass the --sdl2 option to update-workspaces, this is untested on *nix so the paths may not be correct there.

I noticed a bug on Windows XP, I had the game open full screen and pressed Ctrl+Alt+Del a few times to open the task manager, then I couldn't get back into the game. There was also a crash (seems a GL init issue) when starting mods from the new mod selection screen - I don't know if that bug also affects SVN.

comment:21 by yashi, 10 years ago

just tried sdl2-support branch and It Works for Me(tm). Still, a few small fixes need to be applied.

  • build/premake/extern_libs4.lua still needs if _OPTIONS["sdl2"] block for the compile_settings in addition to the link_settings you fixed.
  • source/ps/GameSetup/HWDetect.cpp::ReportGLLimits() needs to aware of SDL2, like:
    • source/ps/GameSetup/HWDetect.cpp

      a b  
      4444
      4545#ifdef SDL_VIDEO_DRIVER_X11
      4646#include <GL/glx.h>
      47 #include <SDL/SDL_syswm.h>
       47#include <SDL_syswm.h>
      4848
      4949// Define the GLX_MESA_query_renderer macros if built with
      5050// an old Mesa (<10.0) that doesn't provide them
      static void ReportGLLimits(ScriptInterface& scriptInterface, JS::HandleValue set  
      707707
      708708    SDL_SysWMinfo wminfo;
      709709    SDL_VERSION(&wminfo.version);
      710     if (SDL_GetWMInfo(&wminfo) && wminfo.subsystem == SDL_SYSWM_X11)
       710#if SDL_VERSION_ATLEAST(2, 0, 0)
       711    const int ret = SDL_GetWindowWMInfo(g_VideoMode.GetWindow(), &wminfo);
       712#else
       713    const int ret = SDL_GetWMInfo(&wminfo);
       714#endif
       715    if (ret && wminfo.subsystem == SDL_SYSWM_X11)
      711716    {
       717#if SDL_VERSION_ATLEAST(2, 0, 0)
       718        Display* dpy = wminfo.info.x11.display;
       719#else
      712720        Display* dpy = wminfo.info.x11.gfxdisplay;
       721#endif
      713722        int scrnum = DefaultScreen(dpy);
      714723
      715724        const char* glxexts = glXQueryExtensionsString(dpy, scrnum);

Even with the above fixes, it still crash when switching from mod selector to the game. enabling the following config and by-passing mod selction let me play the game even with my multi-monitor settings! yes!

mod.enabledmods = "mod public"

comment:22 by fabio, 10 years ago

Hey, I was trying it also and sent a pull request for the compile issue.

The crash issue if not sdl2 specific and is tracked at #2753.

in reply to:  21 comment:23 by historic_bruno, 10 years ago

Replying to yashi:

Hi, thanks for testing on Linux! I notice you change the SDL include path, but I think it will currently work with SDL 1.2. Does your change break the SDL 1.2 build, is it necessary for SDL2 on Linux?

comment:24 by fabio, 10 years ago

I can confirm that without the include change sdl2 fails to build. But with the change sdl1 fails, so it should also be ifdeffed only for sdl2.

in reply to:  22 comment:25 by yashi, 10 years ago

Replying to fabio:

Hey, I was trying it also and sent a pull request for the compile issue.

Great. Sorry that I didn't notice your pull request on github.

The crash issue if not sdl2 specific and is tracked at #2753.

Thanks. Will comment on that ticket. It seems to me that the issue is related to SDL, though. window->magic does not match _this->window_magic after restart.

in reply to:  24 ; comment:26 by historic_bruno, 10 years ago

Replying to fabio:

I can confirm that without the include change sdl2 fails to build. But with the change sdl1 fails, so it should also be ifdeffed only for sdl2.

It seems in other source files, we include SDL headers directly with no path, like #include "SDL_syswm.h" in x.cpp. I don't see why it wouldn't work there, can you try that? I'm stuck on Windows for the moment.

comment:27 by yashi, 10 years ago

Replying to historic_bruno:

It seems in other source files, we include SDL headers directly with no path, like #include "SDL_syswm.h" in x.cpp. I don't see why it wouldn't work there, can you try that? I'm stuck on Windows for the moment.

It turns out that most Linux system has SDL's include directory under the system default /usr/include and gcc search there anyhow. Thus, regardless of the value returned from sdl-config --cflags, we find SDL/.... on ordinary systems.

I've installed SDL1 under some other directory, and it did fail without fix. So, it is a bug no one triggered yet.

BTW, is there any reason why we use "..." instead of <...>? Is it because it's not a system library under Windows?

in reply to:  26 ; comment:28 by fabio, 10 years ago

Replying to historic_bruno:

Replying to fabio:

I can confirm that without the include change sdl2 fails to build. But with the change sdl1 fails, so it should also be ifdeffed only for sdl2.

It seems in other source files, we include SDL headers directly with no path, like #include "SDL_syswm.h" in x.cpp. I don't see why it wouldn't work there, can you try that? I'm stuck on Windows for the moment.

This is the error I am getting with yashi patch and SDL1 on debian testing:

../../../source/lib/res/graphics/cursor.cpp: In member function ‘Status SDLCursor::create(const PIVFS&, const VfsPath&, int, int)’:
../../../source/lib/res/graphics/cursor.cpp:104:63: error: ‘SDL_CreateColorCursor’ was not declared in this scope
   cursor = SDL_CreateColorCursor(surface, hotspotx_, hotspoty_);
                                                               ^
Last edited 10 years ago by fabio (previous) (diff)

comment:29 by fabio, 10 years ago

And I get the same error with "SDL_..." rather than <SDL_...>.

in reply to:  28 comment:30 by historic_bruno, 10 years ago

Replying to fabio:

This is the error I am getting with yashi patch and SDL1 on debian testing:

../../../source/lib/res/graphics/cursor.cpp: In member function ‘Status SDLCursor::create(const PIVFS&, const VfsPath&, int, int)’:
../../../source/lib/res/graphics/cursor.cpp:104:63: error: ‘SDL_CreateColorCursor’ was not declared in this scope
   cursor = SDL_CreateColorCursor(surface, hotspotx_, hotspoty_);
                                                               ^

That isn't related to the includes - I thought I had tested the cursor code with SDL 1.2, but obviously not...

in reply to:  27 comment:31 by historic_bruno, 10 years ago

Replying to yashi:

BTW, is there any reason why we use "..." instead of <...>? Is it because it's not a system library under Windows?

r10895 explains that briefly, in fact it addressed the very issue we're discussing :)

I've rebased sdl2-support to fix the SDL 1.2 build failures.

Last edited 10 years ago by historic_bruno (previous) (diff)

comment:32 by fabio, 10 years ago

I can confirm current sdl2 branch compiles OK with both sdl1 and sdl2 on debian.

comment:33 by historic_bruno, 10 years ago

Keywords: patch review added

Thanks!

in reply to:  33 comment:34 by Niek, 10 years ago

Replying to historic_bruno:

Thanks!

But what about the error you posted?

comment:35 by yashi, 10 years ago

The current sdl2-support branch seems to be working with both SDL1 and SDL2 on my system, however, I see two problems with SDL2.

First, with SDL2, mouse tilt does not work. This seems to be an API change on SDL. My mouse reports that button 6 and 7 when I tilt left and right, respectively.

Second, I see the map rotating clockwise when I zooming-out fast with my mouse wheel. Has anyone seen this?

in reply to:  35 ; comment:36 by historic_bruno, 10 years ago

Description: modified (diff)

Replying to niektb:

But what about the error you posted?

The error restarting the engine after mod selection is fixed by yashi's patch (cec49f5). Then the following are still issues:

  • Text input interacts differently with hotkeys, this is most noticeable with the backquote !` key in a text input field. It is also a console.toggle hotkey, it will both add the backquote and open the console.
    • In SDL1, it ignores the hotkey as a special case and inputs a backquote.
    • SDL2 sends three events for this single key press (actually one is a custom event sent by the hotkey handler): key down, hotkey down, and text input. The events aren't connected in the API, and I don't know that I can count on their order.
    • I think similar problems would occur with other hotkeys that have visible input characters.
  • In Windows, debugging the game in fullscreen is impossible, the window seems to maintain focus over VS. There may be other fullscreen focus-related issues.
  • Atlas errors on Linux?

Replying to yashi:

First, with SDL2, mouse tilt does not work. This seems to be an API change on SDL. My mouse reports that button 6 and 7 when I tilt left and right, respectively.

What functionality is mouse tilt in the game?

in reply to:  36 ; comment:37 by yashi, 10 years ago

Replying to historic_bruno:

What functionality is mouse tilt in the game?

it rotates the map.

comment:38 by fabio, 10 years ago

If there are no regression in the default sdl1 path it would be nice to push the branch in svn to ease testing.

in reply to:  36 comment:39 by yashi, 10 years ago

Replying to historic_bruno:

  • Atlas errors on Linux?

yup. it dies.

https://gist.github.com/yashi/cf9d691e4917b705fd1e

#7  0x0000000000a7ddc7 in ogl_Init () at ../../../source/lib/ogl.cpp:479
#8  0x00000000009b3e31 in AtlasMessage::fInitGraphics (msg=0x168ade0)
    at ../../../source/tools/atlas/GameInterface/Handlers/GraphicsSetupHandlers.cpp:84
#9  0x00000000009b3de7 in AtlasMessage::fInitGraphics_wrapper (msg=0x168ade0)
    at ../../../source/tools/atlas/GameInterface/Handlers/GraphicsSetupHandlers.cpp:64
#10 0x0000000000979714 in RunEngine (data=0x7fffffffe100)
    at ../../../source/tools/atlas/GameInterface/GameLoop.cpp:174
#11 0x00007ffff3c7f0a4 in start_thread (arg=0x7fffe077f700) at pthread_create.c:309
#12 0x00007ffff39b4c2d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb) f 7
#7  0x0000000000a7ddc7 in ogl_Init () at ../../../source/lib/ogl.cpp:479
479		ENSURE(exts);	// else: called before OpenGL is ready for use
(gdb) p exts
$1 = 0x0
(gdb) 

in reply to:  37 comment:40 by historic_bruno, 10 years ago

Replying to yashi:

Replying to historic_bruno:

What functionality is mouse tilt in the game?

it rotates the map.

That must be horizontal scrolling/mousewheel, which was previously handled as mouse buttons, but is now part of an SDL_MOUSEWHEEL event. I will just simulate the old mouse button presses when there is horizontal (x != 0) movement.

comment:41 by historic_bruno, 10 years ago

Priority: Must HaveRelease Blocker

Too many things depend on this and it's very close to being done, so I am making it a release blocker.

comment:42 by yashi, 10 years ago

I've tried the tip of the sdl2-support branch (47d9134) as of this morning, but my mouse tilting does not seem to work. BTW, tilting works like Q and E but not A and D.

I didn't have time this weekend but might be able to work on it in a few days. Hoping someone to beat me to it.

comment:43 by yashi, 10 years ago

uga... The definition of SDL_BUTTON_X1 and SDL_BUTTON_X2 differ in SDL1 and SDL2 from day 1.

At least under X11 (linux), mouse button seems to be defined as follows:

1, left 2, middle 3, right 4, wheel up 5, wheel down 6, wheel tilt left 7, wheel tilt right

if you follow this convention, which SDL1 is using, you can patch the code as:

  • source/ps/KeyName.h

    iff --git a/source/ps/KeyName.h b/source/ps/KeyName.h
    index 813a4ab..5b0ee86 100644
    a b enum {  
    5757       MOUSE_RIGHT = MOUSE_BASE + SDL_BUTTON_RIGHT,
    5858       MOUSE_MIDDLE = MOUSE_BASE + SDL_BUTTON_MIDDLE,
    5959#if SDL_VERSION_ATLEAST(2, 0, 0)
    60        MOUSE_X1 = MOUSE_BASE + SDL_BUTTON_X1,
    61        MOUSE_X2 = MOUSE_BASE + SDL_BUTTON_X2,
     60       MOUSE_X1 = MOUSE_BASE + SDL_BUTTON_X1 + 2,
     61       MOUSE_X2 = MOUSE_BASE + SDL_BUTTON_X2 + 2,
    6262#elif SDL_VERSION_ATLEAST(1, 2, 13)
    6363       // SDL 1.2 defines wheel buttons before X1/X2 buttons
    6464       MOUSE_WHEELUP = MOUSE_BASE + SDL_BUTTON_WHEELUP,

or just MOUSE_X1 = MOUSE_BASE + 6, with a comment would be clearer.

Does anyone have a mouse with tilts under non-linux? What do they mapped to?

comment:44 by yashi, 10 years ago

Found mouse button issue on libsdl's bugzilla:

https://bugzilla.libsdl.org/show_bug.cgi?id=2472

in reply to:  43 ; comment:45 by historic_bruno, 10 years ago

Rebased sdl2-support and committed a bunch of OS X stuff. Of course there are new problems :D

  • The mouse coordinates seem to be offset slightly horizontally and vertically from the rendered cursor, most noticeable on buttons. Affects both windowed and fullscreen modes.
  • Fullscreen toggling works, but if the window starts fullscreen, it can't be resized or expanded with standard window controls. The Alt+Enter hotkey still works though. If it starts windowed, the resize and expand controls are enabled.
  • Atlas is still broken for me, but the errors are somewhat different.

Replying to yashi:

Does anyone have a mouse with tilts under non-linux? What do they mapped to?

I haven't heard of anyone else with such a mouse playing 0 A.D., so we might be relying on you to fix this :) Thanks for looking into it, but it won't prevent merging sdl2-support into SVN, I will just open a new ticket for that if it's not fixed by then.

comment:46 by Stan, 10 years ago

I have a rat5 do I have the mouse tilt ?

comment:47 by Niek, 10 years ago

If tilting is just rotating the camera, I have a mouse with thumb buttons with which I can rotate the camera (and windows installed)

comment:48 by yashi, 10 years ago

If it's working under windows, and/or OS X, let's just leave it as is.

As I commented on the sdl bugzilla, SDL_MOUSE_X1 and SDL_MOUSE_X2 are defined differently by the back-ends. So, it might be that Linux (or X11 in SDL's view) is the only platform affected. And it's not a blocker at all.

We better get Atlas working under SDL2.

in reply to:  48 comment:49 by Niek, 10 years ago

Replying to yashi:

If it's working under windows, and/or OS X, let's just leave it as is.

As I commented on the sdl bugzilla, SDL_MOUSE_X1 and SDL_MOUSE_X2 are defined differently by the back-ends. So, it might be that Linux (or X11 in SDL's view) is the only platform affected. And it's not a blocker at all.

We better get Atlas working under SDL2.

I haven't checked it with the SDL2 branch if mouse tilting works... (But I wondered what you meant with tilting.)

comment:50 by Stan, 10 years ago

Atlas on all platforms is a must have. Mostly because that would bring a bigger dimension to the contest.

comment:51 by leper, 10 years ago

Using the patch and building against SDL1, hotkeys in-game are broken as every key press seems to fire two events. (Pressing z while having the CC selected adds two females to the production queue, but pressing z while having the chat open just adds one char).

Atlas works for me on Linux with wx3 and SDL1. SDL2 and Atlas is broken as explained above.

EDIT: Getting the same hotkey behaviour with SDL2.

Last edited 10 years ago by leper (previous) (diff)

in reply to:  45 comment:52 by historic_bruno, 10 years ago

Hmm, I'm not sure what I might have changed that would affect SDL1 hotkeys... almost all the changes should have added SDL2-only code and not changed the existing stuff. I don't get the multiple key presses on Windows, but I do on OS X w/ SDL2.

Replying to historic_bruno:

  • The mouse coordinates seem to be offset slightly horizontally and vertically from the rendered cursor, most noticeable on buttons. Affects both windowed and fullscreen modes.

I don't notice this on Lion, but on Mavericks.

  • Fullscreen toggling works, but if the window starts fullscreen, it can't be resized or expanded with standard window controls. The Alt+Enter hotkey still works though. If it starts windowed, the resize and expand controls are enabled.

Fullscreen seems kinda broken in Lion as well, the video mode changes in a very ugly way, and sometimes the resolution change doesn't seem complete. It might become fullscreen but the game window only fills the original part of the screen.

comment:53 by leper, 10 years ago

Hotkey issue was unrelated to SDL and might have been the cause of double keypresses on OSX. Fixed in r15755.

comment:54 by Itms, 10 years ago

Hey, I tested sdl2-support on Windows and I had some trouble with keys. I fetched the r15755 changes when testing, so I didn't experience the double-key thing.

  • Some hotkeys don't work, for example the , . to find idle units.
  • Some random features, like Shift+click on my CC rotating the map...
  • When I enter the chat, the keys still behave as hotkeys. For example, if I type a 't' the log window is closed, if I type 'e' the view rotates, etc.
  • I ear a Windows sound every time I toggle functionalities. For instance when I toggle fullscreen with Alt+Enter, when I open the dev overlay, when I switch to wireframe rendering or whatever. I hope this can be deactivated because it's rather unpleasant. :P

Building sdl1 seems to work without problems.

in reply to:  54 ; comment:55 by historic_bruno, 10 years ago

Thanks for testing! And please keep trying to break it :D

Replying to Itms:

  • Some hotkeys don't work, for example the , . to find idle units.

Strange, they work for me, what's your keyboard layout?

  • Some random features, like Shift+click on my CC rotating the map...

Confirmed. That's the hotkey.camera.rotate.wheel.cw hotkey, it's not clear to me how that hotkey can be triggered with a left click though...

  • When I enter the chat, the keys still behave as hotkeys. For example, if I type a 't' the log window is closed, if I type 'e' the view rotates, etc.

Yeah, this is the same bug mentioned above, I just didn't realize how serious it was. I might have a fix for this. Basically the text input code is currently passing SDL_KEYDOWN events to the next handler if they don't match one of its hard coded functions (backspace, delete, enter, etc.), this is something added for SDL2 because it no longer uses key presses for text input. If instead the SDL_KEYDOWN event is "handled", it won't be passed on, meaning the hotkeys you mention won't be triggered.

  • I ear a Windows sound every time I toggle functionalities. For instance when I toggle fullscreen with Alt+Enter, when I open the dev overlay, when I switch to wireframe rendering or whatever. I hope this can be deactivated because it's rather unpleasant. :P

Confirmed. Looks like an SDL bug related to the Alt key, but I usually have Windows system sounds muted, so I never noticed :/ https://bugzilla.libsdl.org/show_bug.cgi?id=2669

in reply to:  55 comment:56 by Itms, 10 years ago

Replying to historic_bruno:

Replying to Itms:

  • Some hotkeys don't work, for example the , . to find idle units.

Strange, they work for me, what's your keyboard layout?

Ah, yes, I have an AZERTY keyboard. However, on SDL1, the keys that are mapped to '. ,' in a QWERTY keyboard (for me, '; :') work. On SDL2 no key seems to trigger the "Find Idle Unit" command.

comment:57 by historic_bruno, 10 years ago

Even Shift+; doesn't work? I think you should reconfigure your hotkeys for an AZERTY keyboard (we could also completely redesign how hotkeys work, to use the position of the key on the keyboard, like a "101 button joystick" as SDL's wiki claims, but to me that is even less intuitive or useful than using the printed symbol - players don't change kb layout very often, I expect).

I'm afraid the unsatisfying answer may be that SDL1's keyboard layout handling was broken and it just happened to work better for you.

Last edited 10 years ago by historic_bruno (previous) (diff)

comment:58 by historic_bruno, 10 years ago

Pushed a fix for the hotkeys-in-CInput bugs.

in reply to:  58 comment:59 by Itms, 10 years ago

Replying to historic_bruno:

Pushed a fix for the hotkeys-in-CInput bugs.

I confirm this is fixed. :)

About my keyboard layout, I agree the layout handling under SDL1 was broken. What I'm afraid of is the possibility of players who will see this as a regression, to whom we'll have to explain how to setup hotkeys.

comment:60 by historic_bruno, 10 years ago

We already have to some extent, see Manual_Settings :) What will be weird for a while is that not everyone will be using SDL2, but I hope the worst bugs can be fixed and the transition will occur ASAP on Linux. (Actually, I think there are already OS-specific hotkey issues in SDL1, so even that is not a big change)

We could always temporarily add ?:; to the default.cfg hotkeys, if there are no conflicts, but it only takes care of that one layout difference.

comment:61 by Niek, 10 years ago

On windows 7, setting a custom resolution doesn't work as should. Although I set in local.cfg the resolution at 1280x720, the game starts in native resolution (1920x1080 in my case). When I enter windowed mode however it appends to the set resolution.

comment:62 by leper, 10 years ago

That is the same behaviour as with SDL1 (or rather without the patch).

in reply to:  61 comment:63 by historic_bruno, 10 years ago

Replying to niektb:

On windows 7, setting a custom resolution doesn't work as should. Although I set in local.cfg the resolution at 1280x720, the game starts in native resolution (1920x1080 in my case). When I enter windowed mode however it appends to the set resolution.

This is because the window is created with the SDL_WINDOW_FULLSCREEN_DESKTOP flag. With only SDL_WINDOW_FULLSCREEN, it works as you want, but toggling from fullscreen to windowed mode is broken on Windows and possibly other platforms (the window ends up at a strange resolution of 1916x1054 in my testing, an extra resize event is being sent).

I haven't looked through all of SDL's bugtracker, but so far I haven't seen a report for this and it's still broken in their code repo.

Last edited 10 years ago by historic_bruno (previous) (diff)

in reply to:  62 comment:64 by Niek, 10 years ago

Replying to leper:

That is the same behaviour as with SDL1 (or rather without the patch).

No, with SDL1 (or SVN) it worked correctly. Setting the resolution to a non-native size just scales the game to the screen.

Last edited 10 years ago by Niek (previous) (diff)

in reply to:  54 ; comment:65 by historic_bruno, 10 years ago

Replying to Itms:

  • Some random features, like Shift+click on my CC rotating the map...

I've found the cause of this, there is a global mouse button state g_mouse_buttons that I didn't know about, which stores a bool (true = down, false = up) for up to 5 mouse buttons: left, right, middle, wheelup and wheeldown. This is used by the hotkey handler to determine if mouse buttons are pressed to activate a hotkey. The problem is the order of these buttons was broken for SDL2, left and middle buttons ended up being treated like wheelup and wheeldown. Shift+WheelUp/WheelDown rotates the map.

I've changed the order to be consistent with SDL1 and hopefully this won't break anything else with mouse buttons. There's a chance this fixes the mouse tilt problems too.

comment:66 by historic_bruno, 10 years ago

Another possible issue is that with the new SDL_MOUSEWHEEL event, there is no "up", there won't be an event when the mouse wheel stops moving. We don't seem to have any code that relies on that distinction, but it would certainly be broken and we would have to generate a fake "up" event or change how mouse wheel input is handled.

comment:67 by historic_bruno, 10 years ago

Summary for sdl2-support:

  • SDL1 regressions:
    • None?!
  • SDL2 issues:
    • All platforms:
      • [MEDIUM] Can't set resolution in fullscreen mode, as a workaround to fix buggy fullscreen to windowed transition
      • [MEDIUM] Hotkey behavior differences with non-QWERTY keyboard layouts
      • [LOW] Text input testing and verification, especially CJK languages w/ IMEs
    • Windows:
      • [HIGH] System beep sound in windowed mode, when pressing Alt key, certainly an SDL2 bug, WSDL doesn't have this problem so perhaps we can derive a patch from it
      • [LOW] Difficulty debugging in VS
      • [LOW] IME input mostly broken (should handle SDL_TEXTEDITING events and use SDL_SetTextInputRect)
    • Linux:
      • [BLOCKING] Atlas broken
      • [LOW] Mouse tilt broken / not rotating map
    • OSX:
      • [HIGH] Cursor offset on Mavericks (VM)
      • [MEDIUM] Fullscreen/windowed toggling buggy
      • [MEDIUM] Needs testing on Retina displays, I've seen reports that recent SDL2 is buggy on them

So, given that there are no regressions affecting SDL1 that I know about, I am going to merge sdl2-support into SVN. SDL1 will remain the default and SDL2 will be enabled for each OS as appropriate.

comment:68 by ben, 10 years ago

In 15767:

Improves SDL2 support, includes patch by yashi and fabio, refs #2041:

  • Adds SDL color cursor implementation
  • Adds config option for choosing preferred display in multimonitor setup
  • Uses text input API to better handle CJK input
  • Fixes various hotkey and input bugs

SDL 1.2 is still the default and recommended, to test experimental SDL2 support, pass the --sdl2 flag to update-workspaces

comment:69 by Niek, 10 years ago

Is r15767 a merge of your sdl2-support branch?

comment:70 by Itms, 10 years ago

r15767 seems to lack all the SDL2 files (for windows), I don't know whether other files are missing...

comment:71 by ben, 10 years ago

In 15772:

Adds precompiled win32 binaries for SDL 2.0.3 from libsdl.org, refs #2041

comment:72 by ben, 10 years ago

In 15774:

Adds SDL2 to build-osx-libs.sh, but leave SDL1 as the default while we test, refs #2041.
Note: SDL2_CONFIG is now the variable to override the path to sdl2-config, SDL_CONFIG remains to override the path to sdl-config

comment:73 by historic_bruno, 10 years ago

That's most of sdl2-support merged into SVN, but note that SDL1 remains the default, it is necessary on all OSes to pass --sdl2 to update-workspaces, to force the game to use SDL2.

comment:74 by historic_bruno, 10 years ago

Description: modified (diff)

Submitted patch for SDL2 to fix the Windows beeping problems, I will patch SDL 2.0.3 and rebuild the libs. Then I think SDL2 can be made the default on Windows :)

comment:75 by ben, 10 years ago

In 15783:

Updates precompiled win32 SDL 2.0.3 libs to fix the system beep sound whenever an Alt hotkey is used, patch applied from https://bugzilla.libsdl.org/show_bug.cgi?id=2669
Refs #2041

comment:76 by historic_bruno, 10 years ago

Description: modified (diff)

r15785 cleaned up SDL2 text input handling and implemented text editing events, so now we basically have this, except that the candidate list rendering isn't working on Windows, it seems to not be fully implemented in SDL2.

comment:77 by ben, 10 years ago

In 15786:

Adds --sdl2 flag to update-workspaces.bat, making SDL2 the default on Windows, refs #2041

comment:78 by historic_bruno, 10 years ago

Unresolved tickets related to SDL2 upgrade: #2272, #1917, #1916, #1873, #1606, #965, #945

in reply to:  description comment:79 by historic_bruno, 10 years ago

Replying to historic_bruno:

  • [HIGH] Cursor offset on Mavericks (VM)

Possibly related: https://bugzilla.libsdl.org/show_bug.cgi?id=2655 - not had time to investigate in any detail.

in reply to:  67 ; comment:80 by yashi, 10 years ago

Replying to historic_bruno:

  • Linux:
    • [BLOCKING] Atlas broken

Trying to figure out what has broken Atlas on Linux with SDL2 a while. But I'm a bit lost. Hope someone enlighten me with 0ad insight, especially the relationship of wxWidget, SDL and OpenGL in Atlas.

First, does anyone know the last commit which Atlas worked on Linux with SDL 1.2? It seems to me that Atlas has been broken in a while. Both the current tip [15790] and an old Atlas from [15462] and [15174] gives me a stack trace once in about 10 invocations if I build with SDL1. I might be doing something wrong but...

Another thing is that it seem to initialize OpenGL form wxWidget and SDL independently. If both framework uses GLX backend, glXMakeCurrent() is called at the framework init time. The last call of glXMakeCurrent() wins and sets its GL context as the current. Are we allowed to call any GL functions while the other GL context is current?

Now onto the SDL2 breakage, it seems that GL context creation has been changed to explicit call in SDL2. This might be the case why we see 100 % breakage with SDL2. Assume my understanding is correct, should SDL uses wx's GL context, or the other way around? IOW, do we load SDL in one of wx's widget or using SDL as wx's backend? I'm assumin former.

in reply to:  65 comment:81 by yashi, 10 years ago

Replying to historic_bruno:

There's a chance this fixes the mouse tilt problems too.

Unfortunately not. I guess I have to work on libsdl to fix the tilt problem, IIUC.

in reply to:  35 ; comment:82 by yashi, 10 years ago

Replying to yashi:

Second, I see the map rotating clockwise when I zooming-out fast with my mouse wheel. Has anyone seen this?

It seems that this problem is still there in the current tip.

With the current tip, zoom-in rotates in clockwise and zoom-out rotates in the other direction, counterclockwise.

comment:83 by Niek, 10 years ago

This weekend building and running Atlas with SDL1 worked for me on Ubuntu 14.04...

I just installed the dependencies, checked out svn, ran update-workspaces.sh and built the game. It all worked at once. WXWidgets 3.0.0 in case that is important, but 2.8.12 is also known to work

Last edited 10 years ago by Niek (previous) (diff)

comment:84 by ben, 10 years ago

In 15799:

Sets OS X build to use SDL2 by default, refs #2041

comment:85 by fabio, 10 years ago

Description: modified (diff)

in reply to:  82 comment:86 by historic_bruno, 10 years ago

Replying to yashi:

Replying to yashi:

Second, I see the map rotating clockwise when I zooming-out fast with my mouse wheel. Has anyone seen this?

It seems that this problem is still there in the current tip.

With the current tip, zoom-in rotates in clockwise and zoom-out rotates in the other direction, counterclockwise.

I haven't encountered that, are you sure that it's not activating a button press? X1 and X2 would rotate the map.

in reply to:  80 ; comment:87 by yashi, 10 years ago

Spent a bit more time on Atlas & SDL, and it turns out that SDL2 resets the current GL context twice while initializing; once from SDL_InitSubSystem() and the other from SDL_GL_LoadLibrary(). So, make long story short, move both function from MESSAGEHANDLER(InitGraphics) to MESSAGEHANDLER(SetCanvas) make Atlas work with both SDL1 and SD2.

Well, sort of. The SDL1 problem I described on the comment:80 seems to be a real. I had to add Raise(); right after Show(true); in ScenarioEditor::ScenarioEditor() to make both SDL1 and SDL2 work under my setup.

  • gnome-shell: 3.14.0-1
  • libgtk-3-0: 3.14.0-1
  • libsdl1.2debian: 1.2.15-10
  • libsdl2-2.0-0: 2.0.2+dfsg1-4
  • libwxgtk3.0-0: 3.0.1-3

I'll submit a tentative patch later, but here is a test patch if you are interested in. BTW, Change the glXGetCurrentContext() for your platform, ie wglGetCurrentContext() for windows, and let me know how SDL2 behave without moving the SDL init functions. Does SDL2 clear the current context? I'm very interested in.

Any comments are welcome.

  • initializing SDL in SetCanvas isn't clean
    • should create new message? one for GL and new one for SDL?
  • SDL can only share the current GL context after SDL_VideoInit()
    • ok to call in order of 1) SDL init, 2) canvas init

  • source/tools/atlas/AtlasUI/ScenarioEditor/ScenarioEditor.cpp

    diff --git a/source/tools/atlas/AtlasUI/ScenarioEditor/ScenarioEditor.cpp b/source/tools/atlas/AtlasUI/ScenarioEditor/ScenarioEditor.cpp
    index 24046e3..8e2ed74 100644
    a b ScenarioEditor::ScenarioEditor(wxWindow* parent)  
    503503    // Need to make sure the canvas is realised, so that its context is valid
    504504    // this solves the "invalid drawable" error
    505505    Show(true);
     506    Raise();
    506507#endif
    507508#ifdef __WXGTK__
    508509    // TODO: wxSafeYield causes issues on wxOSX 2.9, is it necessary?
  • source/tools/atlas/GameInterface/Handlers/GraphicsSetupHandlers.cpp

    diff --git a/source/tools/atlas/GameInterface/Handlers/GraphicsSetupHandlers.cpp b/source/tools/atlas/GameInterface/Handlers/GraphicsSetupHandlers.cpp
    index 8932a20..15633e4 100644
    a b  
    3535#include "ps/GameSetup/GameSetup.h"
    3636#include "renderer/Renderer.h"
    3737
     38#include <GL/glx.h>
     39
    3840namespace AtlasMessage {
    3941
    4042// see comment in GameLoop.cpp about ah_display_error before using INIT_HAVE_DISPLAY_ERROR
    MESSAGEHANDLER(InitGraphics)  
    7678    // GL stuff instead of from the wxWidgets-initialised GL stuff, but that
    7779    // should be checked.)
    7880    // So, make sure it's loaded:
    79     SDL_InitSubSystem(SDL_INIT_VIDEO);
    80     SDL_GL_LoadLibrary(NULL); // NULL = use default
    8181    // (it shouldn't hurt if this is called multiple times, I think)
    8282#endif
    8383
    MESSAGEHANDLER(SetActorViewer)  
    168168
    169169MESSAGEHANDLER(SetCanvas)
    170170{
     171    printf("!!!! %lx:%s:%p\n", pthread_self(), __func__, glXGetCurrentContext());
     172    SDL_InitSubSystem(SDL_INIT_VIDEO);
     173    printf("!!!! %lx:%s:%p\n", pthread_self(), __func__, glXGetCurrentContext());
     174    SDL_GL_LoadLibrary(NULL); // NULL = use default
     175    printf("!!!! %lx:%s:%p\n", pthread_self(), __func__, glXGetCurrentContext());
     176
    171177    // Need to set the canvas size before possibly doing any rendering,
    172178    // else we'll get GL errors when trying to render to 0x0
    173179    CVideoMode::UpdateRenderer(msg->width, msg->height);
    174180
     181    printf("!!!! %lx:%s:%p\n", pthread_self(), __func__, glXGetCurrentContext());
    175182    g_AtlasGameLoop->glCanvas = msg->canvas;
    176183    Atlas_GLSetCurrent(const_cast<void*>(g_AtlasGameLoop->glCanvas));
     184    printf("!!!! %lx:%s:%p\n", pthread_self(), __func__, glXGetCurrentContext());
    177185}
    178186
    179187

comment:88 by historic_bruno, 10 years ago

Description: modified (diff)

in reply to:  description comment:89 by historic_bruno, 10 years ago

Replying to historic_bruno:

  • Windows:
    • [MEDIUM] Issues switching to windowed mode after starting fullscreen - window appears not resizable and doesn't have menu bar (similar to OS X issues)
  • OSX:
    • [MEDIUM] Fullscreen/windowed toggling buggy

I wanted to test with SDL_WINDOW_FULLSCREEN but ran into all these bugs. They should be fixed in SDL 2.0.4, but I don't really want to apply so many patches for A17.

I encounter similar bugs on Windows using SDL_WINDOW_FULLSCREEN. However, I did find a hacky solution to some of those, I tried setting the window size and position before switching from fullscreen to windowed mode, then do the same afterward. It's the only way I can get the window to have the correct resolution. A related bonus is that I store the previous window position, since SDL2 seems to discard that data, so switching fullscreen to windowed mode will bring the window back to its last position and hopefully even the same display (in case of multiple displays).

Last edited 10 years ago by historic_bruno (previous) (diff)

comment:90 by Niek, 10 years ago

I always start the game in full screen but going into windowed mode and back to full screen goes without any issues. Tested on Windows 7 and 8.1. Window is indeed not resizeable but it does have a menu bar

Last edited 10 years ago by Niek (previous) (diff)

comment:91 by ben, 10 years ago

In 15827:

Fixes some issues when toggling fullscreen mode with SDL2, refs #2041:

  • SDL_WINDOW_RESIZABLE must be set when creating the window, apparently only fullscreen flags take effect in SDL_SetWindowFullscreen
  • Stores window position, so a window can be restored to both its original position and size, rather than defaults
  • Changes initial window position from undefined to centered, it caused some problems with window positioning returning from fullscreen mode

comment:92 by historic_bruno, 10 years ago

Description: modified (diff)

in reply to:  description comment:93 by historic_bruno, 10 years ago

Replying to historic_bruno:

  • OSX:
    • [HIGH] Cursor offset on Mavericks (VM)

The offset is 3 pixels in x and y direction, adding 3 to the hotspot values in SDLCursor::create is a possible workaround. Tested with SDL 2.0.4-9134, this bug is still there, but the SDL_WINDOW_FULLSCREEN bugs are fixed.

in reply to:  87 ; comment:94 by historic_bruno, 10 years ago

Replying to yashi:

I'll submit a tentative patch later, but here is a test patch if you are interested in. BTW, Change the glXGetCurrentContext() for your platform, ie wglGetCurrentContext() for windows, and let me know how SDL2 behave without moving the SDL init functions. Does SDL2 clear the current context? I'm very interested in.

Thanks for working on that! I tried using wglGetCurrentContext but ended up with linker errors.

comment:95 by historic_bruno, 10 years ago

Description: modified (diff)

in reply to:  94 comment:96 by yashi, 9 years ago

Replying to historic_bruno:

Thanks for working on that! I tried using wglGetCurrentContext but ended up with linker errors.

I don't have a slightest clue about windows but MSDN tells me that you need Opengl32.dll or Opengl32.lib. That's already specified, right?

comment:97 by ben, 9 years ago

In 15830:

Fixes some bugs related to IME text input in SDL2, including a possible crash, refs #2041. Behavior seems reasonably consistent now on Windows and OS X

comment:98 by historic_bruno, 9 years ago

Description: modified (diff)

comment:99 by ben, 9 years ago

In 15832:

Fixes blank window after maximizing, minimizing, then restoring the game on Windows. In SDL2, this is an SDL_WINDOWEVENT_EXPOSED event, which we must handle to reset the game's minimized state. Refs #2041

comment:100 by historic_bruno, 9 years ago

Description: modified (diff)

comment:101 by Josh, 9 years ago

Cc: Josh added

comment:102 by historic_bruno, 9 years ago

Description: modified (diff)
Keywords: review removed
Resolution: fixed
Status: newclosed

At 100 comments, this ticket is too big, and it's mostly done :) So I'm closing as fixed and have opened new tickets for the remaining issues.

comment:103 by ben, 9 years ago

In 16357:

Sets SDL2 as default and only build option on Windows.
Removes remnants of WSDL. Refs #2041

in reply to:  description comment:104 by historic_bruno, 9 years ago

Replying to historic_bruno:

  • Windows:
    • [HIGH] System beep sound in windowed mode, when pressing Alt hotkeys, patch submitted upstream

Patch was committed upstream and will be included in SDL 2.0.4.

comment:105 by fabio, 8 years ago

In 17470:

Remove disabled by default SDL1 support.
Refs #2041.

in reply to:  105 ; comment:106 by historic_bruno, 8 years ago

Replying to fabio:

In 17470:

Remove disabled by default SDL1 support.
Refs #2041.

You should also remove the "sdl1" option from premake4.lua.

in reply to:  106 comment:107 by fabio, 8 years ago

Replying to historic_bruno:

You should also remove the "sdl1" option from premake4.lua.

Thanks, done in r17479.

comment:108 by elexis, 4 years ago

Description: modified (diff)

In r23364 by linkmauve, committed by Vladislav:

Removes obsolete sys_cursor. Refs Phab:D2557.

sys_cursor was introduced in rP986 and partially in r2588. Usage of sys_cursor was completely removed in r17470. At the moment we use SDL and GL cursors.

Patch By: linkmauve
Comments By: Stan

Note: See TracTickets for help on using tickets.