#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 )
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 handleSDL_TEXTEDITING
events and useSDL_SetTextInputRect
)
- Linux:
- OSX:
- All platforms:
Attachments (1)
Change History (109)
comment:1 by , 11 years ago
comment:2 by , 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 , 11 years ago
Description: | modified (diff) |
---|
comment:4 by , 11 years ago
Description: | modified (diff) |
---|
comment:5 by , 11 years ago
Cc: | added |
---|
follow-up: 10 comment:7 by , 10 years ago
by , 10 years ago
Attachment: | 0001-First-pass-at-SDL2-support.patch added |
---|
Patch against r14495 to build with SDL2 (2.0.1)
follow-up: 9 comment:8 by , 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.
comment:9 by , 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 :)
comment:10 by , 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.
follow-up: 14 comment:11 by , 10 years ago
Milestone: | Backlog → Alpha 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 , 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 , 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.
comment:14 by , 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).
follow-up: 18 comment:15 by , 10 years ago
Moving to SDL2 fixes the OSX crash with Atlas entirely (see #2650).
comment:16 by , 10 years ago
comment:17 by , 10 years ago
Priority: | Should Have → Must Have |
---|
comment:18 by , 10 years ago
comment:19 by , 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 , 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.
follow-up: 23 comment:21 by , 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 needsif _OPTIONS["sdl2"]
block for thecompile_settings
in addition to thelink_settings
you fixed.
source/ps/GameSetup/HWDetect.cpp::ReportGLLimits()
needs to aware of SDL2, like:-
source/ps/GameSetup/HWDetect.cpp
a b 44 44 45 45 #ifdef SDL_VIDEO_DRIVER_X11 46 46 #include <GL/glx.h> 47 #include <SDL /SDL_syswm.h>47 #include <SDL_syswm.h> 48 48 49 49 // Define the GLX_MESA_query_renderer macros if built with 50 50 // an old Mesa (<10.0) that doesn't provide them … … static void ReportGLLimits(ScriptInterface& scriptInterface, JS::HandleValue set 707 707 708 708 SDL_SysWMinfo wminfo; 709 709 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) 711 716 { 717 #if SDL_VERSION_ATLEAST(2, 0, 0) 718 Display* dpy = wminfo.info.x11.display; 719 #else 712 720 Display* dpy = wminfo.info.x11.gfxdisplay; 721 #endif 713 722 int scrnum = DefaultScreen(dpy); 714 723 715 724 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"
follow-up: 25 comment:22 by , 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.
comment:23 by , 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?
follow-up: 26 comment:24 by , 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.
comment:25 by , 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.
follow-up: 28 comment:26 by , 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.
follow-up: 31 comment:27 by , 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?
follow-up: 30 comment:28 by , 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_); ^
comment:30 by , 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...
comment:31 by , 10 years ago
comment:32 by , 10 years ago
I can confirm current sdl2 branch compiles OK with both sdl1 and sdl2 on debian.
comment:34 by , 10 years ago
follow-ups: 36 82 comment:35 by , 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?
follow-ups: 37 39 comment:36 by , 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
and7
when I tilt left and right, respectively.
What functionality is mouse tilt in the game?
follow-up: 40 comment:37 by , 10 years ago
comment:38 by , 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.
comment:39 by , 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)
comment:40 by , 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 , 10 years ago
Priority: | Must Have → Release 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 , 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.
follow-up: 45 comment:43 by , 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 { 57 57 MOUSE_RIGHT = MOUSE_BASE + SDL_BUTTON_RIGHT, 58 58 MOUSE_MIDDLE = MOUSE_BASE + SDL_BUTTON_MIDDLE, 59 59 #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, 62 62 #elif SDL_VERSION_ATLEAST(1, 2, 13) 63 63 // SDL 1.2 defines wheel buttons before X1/X2 buttons 64 64 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?
follow-up: 52 comment:45 by , 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:47 by , 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)
follow-up: 49 comment:48 by , 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.
comment:49 by , 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
andSDL_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 , 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 , 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.
comment:52 by , 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 , 10 years ago
Hotkey issue was unrelated to SDL and might have been the cause of double keypresses on OSX. Fixed in r15755.
follow-ups: 55 65 comment:54 by , 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.
follow-up: 56 comment:55 by , 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
comment:56 by , 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 , 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.
comment:59 by , 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 , 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.
follow-up: 63 comment:61 by , 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.
follow-up: 64 comment:62 by , 10 years ago
That is the same behaviour as with SDL1 (or rather without the patch).
comment:63 by , 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.
comment:64 by , 10 years ago
Replying to leper:
That is the same behaviour as with SDL1 (or rather without the patch).
No, with SDL1 it worked correctly. Setting the resolution to a non-native size just scales the game.
follow-up: 81 comment:65 by , 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 , 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.
follow-up: 80 comment:67 by , 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 useSDL_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
- All platforms:
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:70 by , 10 years ago
r15767 seems to lack all the SDL2 files (for windows), I don't know whether other files are missing...
comment:73 by , 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 , 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:76 by , 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:78 by , 10 years ago
comment:79 by , 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.
follow-up: 87 comment:80 by , 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.
comment:81 by , 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.
follow-up: 86 comment:82 by , 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 , 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
comment:85 by , 10 years ago
Description: | modified (diff) |
---|
comment:86 by , 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.
follow-up: 94 comment:87 by , 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) 503 503 // Need to make sure the canvas is realised, so that its context is valid 504 504 // this solves the "invalid drawable" error 505 505 Show(true); 506 Raise(); 506 507 #endif 507 508 #ifdef __WXGTK__ 508 509 // 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 35 35 #include "ps/GameSetup/GameSetup.h" 36 36 #include "renderer/Renderer.h" 37 37 38 #include <GL/glx.h> 39 38 40 namespace AtlasMessage { 39 41 40 42 // see comment in GameLoop.cpp about ah_display_error before using INIT_HAVE_DISPLAY_ERROR … … MESSAGEHANDLER(InitGraphics) 76 78 // GL stuff instead of from the wxWidgets-initialised GL stuff, but that 77 79 // should be checked.) 78 80 // So, make sure it's loaded: 79 SDL_InitSubSystem(SDL_INIT_VIDEO);80 SDL_GL_LoadLibrary(NULL); // NULL = use default81 81 // (it shouldn't hurt if this is called multiple times, I think) 82 82 #endif 83 83 … … MESSAGEHANDLER(SetActorViewer) 168 168 169 169 MESSAGEHANDLER(SetCanvas) 170 170 { 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 171 177 // Need to set the canvas size before possibly doing any rendering, 172 178 // else we'll get GL errors when trying to render to 0x0 173 179 CVideoMode::UpdateRenderer(msg->width, msg->height); 174 180 181 printf("!!!! %lx:%s:%p\n", pthread_self(), __func__, glXGetCurrentContext()); 175 182 g_AtlasGameLoop->glCanvas = msg->canvas; 176 183 Atlas_GLSetCurrent(const_cast<void*>(g_AtlasGameLoop->glCanvas)); 184 printf("!!!! %lx:%s:%p\n", pthread_self(), __func__, glXGetCurrentContext()); 177 185 } 178 186 179 187
comment:88 by , 10 years ago
Description: | modified (diff) |
---|
comment:89 by , 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).
comment:90 by , 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
comment:92 by , 10 years ago
Description: | modified (diff) |
---|
comment:93 by , 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.
follow-up: 96 comment:94 by , 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, iewglGetCurrentContext()
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 , 10 years ago
Description: | modified (diff) |
---|
comment:96 by , 10 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:98 by , 10 years ago
Description: | modified (diff) |
---|
comment:100 by , 10 years ago
Description: | modified (diff) |
---|
comment:101 by , 10 years ago
Cc: | added |
---|
comment:102 by , 10 years ago
Description: | modified (diff) |
---|---|
Keywords: | review removed |
Resolution: | → fixed |
Status: | new → closed |
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:104 by , 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.
follow-up: 107 comment:106 by , 8 years ago
comment:107 by , 8 years ago
Replying to historic_bruno:
You should also remove the "sdl1" option from
premake4.lua
.
Thanks, done in r17479.
comment:108 by , 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
In 13572: