[RFC,WIP] Initial experimental SDL2 support #234
Conversation
Prepare for before commiting changes needed for SDL2
sjnewbury
force-pushed
the
SDL2-RFC
branch
13 times, most recently
from
3e619d6
to
8f7bb2f
Compare
|
I have not been able to install SDL2 on my dev computer yet, but just from eyeballing the changes in the PR, I can tell you that the Windows build is currently broken. There are still many references to SDL_Window scattered around in MyOpenGLView.m, which are certainly going to trigger a compile error since the SDL_Window definition is gone. All those references will have to be changed to Main_Window. |
sjnewbury
force-pushed
the
SDL2-RFC
branch
4 times, most recently
from
c191a1f
to
77457c1
Compare
|
Strange, I thought I'd done a search and replace. Will fix that! |
sjnewbury
changed the title
By default SDL1.2 is still used, but by chaning the config.make option, SDL2 is used instead as a build-time option. What works, what doesn't? Working fine: Joystick input Mouse input Keyboard input Sound Fullscreen mode-switching - now mostly working Issues: Fullscreen *mostly* (there is often some flickering sometimes, switching back and forth fixes it. Okay, I think this is might be related to the problems with the splash screen. There's a problem with the GL bounds I think. I'm not an OpenGL expert by any means, so I'm not sure what the problem is exactly. A bigger issue is changing fullscreen resolutions from the in game menu only properly resizes going down, going up leaves the "window" at the previous size but like the flickering, switching to windowed and back fixes it. Splash screen - code is there and no longer prevents startup. It works sometimes. I tried writing a test outside the game and it worked fine. Something is strange, under X the window doesn't get painted or contains random video memory, once the game starts rendering it's fine. It always works under wayland (with the Wayland SDL video backend), see below. Windows support is untested. I tried not to break it, or even change it where possible. Wayland - it works, even the splash screen! There were some issues resizing under Weston, possibly fixed now, lack of Server Side Decorations makes it tricky anyway! Worked fine under Enlightenment/Wayland. Android/iPhone, obscure devices ... Probably needs OpenGL ES ... maybe it just works like Wayland. There is a lot of code that could be simplified, in particular it's possible the SDL2 Windows support works...? Testers/reviewers more than welcome! Especially help with the GL issues mentioned above.
|
@AnotherCommander Fixed the spurious references to SDL_Window. Honestly, I am sure I had done that already at some point! |
|
@AnotherCommander As far as I know the only significant outstanding issues/regressions with my Linux X11/Wayland tested build is the strange splash screen bug and fullscreen mode switching from smaller sizes upwards, while switching to windowed and back works. |
|
Would be interesting to know if it works on Android. |
|
Hi. I'm maintaining the environment that produces the Linux distro independent Oolite installation packages. The environment is an Ubuntu 8.04 (2.6.24-28 kernel) with a gcc v4.2.4. Pretty archaic, I know, but it has demonstrated to produce robust binaries with astonishing compatibility in the big ocean of Linux distros, making happy a lot of our followers having an old laptop with an old Linux distro, still managing to play Oolite decently! Compiling libSDL2 on this environment breaks, complaining about missing mutlitouch device definitions.
and
the second one leading to undefined behavior, from a quick search that I did. I am not familiar with Gentoo, but do you get SDL2 source code that gets compiled in this enviroment or a latest binary from Gentoo repo? If it is source that you get, then can you share the |
|
@KonstantinosSykas Everything is compiled from source with Gentoo. Giving you my logs wouldn't be much help though since I'm mostly bleeding-edge, my compiler is one of the few "stable" components gcc-6.3.0, so by your standards, that's almost from the future! ;-) That's a really old kernel! I'm not sure what versions are present with Ubuntu 8, but the Gentoo ebuild might well help you out with minimum versions and configure flags since Gentoo does try to keep supporting fairly "legacy" setups and will build with few dependencies if they aren't needed: |
|
@KonstantinosSykas Regarding the second GCC warning, I wouldn't be surprised if the lack of warning with 4.2.4 doesn't mean the behaviour is any different! |
|
My concern is that, at the end of the day, to be included in a release, the libSDL2 will have to come out from that environment, unless
Hmmm... food for thought for all of us. 😉 |
|
@KonstantinosSykas Since it's a build time option, unless and until use is made of the SDL2 capabilities perhaps having two builds would be the way to go? One for legacy systems and one for modern/alternative systems. I'm tempted to set up an Android build environment to see if I can make a build that works on my phone. |
|
Of course this would mean it wouldn't be feasible to implement features like multiple Oolite screen -> display mapping. |
|
Since I changed from using the "native fullscreen" SDL_WINDOW_FULLSCREEN_DESKTOP to using the classic SDL_WINDOW_FULLSCREEN the size of the window gets changed on return to fullscreen. With "native fullscreen" the old window size gets remembered. I think it is necessary to remember the old dimensions and restore them on return from fullscreen, perhaps doing so also before switching fullscreen mode will help there too? I think, looking at the windows code, it does something like that already. |
|
Another data-point, under wayland, OpenGL ES is being used by default which has some interesting consequences with exhaust rendering (it's stippled) no doubt amongst other things. |
Yes, the way we do it on Windows is that we query the current desktop resolution and if the fullscreen mode we are going to has the same resolution, then we don't do a display mode change at all, we just modify the dimensions and the style of the game window to desktop size borderless. This has the benefit of being extremely smooth and fast, allows us to go fullscreen also on secondary monitors, does not confuse any post-porcessing gfx injectors that might be in use and as a bonus, Windows automatically removes the taskbar without us having to do anything, as it sees an attempt to cover the entire screen with our window. If we detect that our target mode is of different size to our curent desktop, then we have to do a mode change (but the window is still set up as a borderless desktop-size so alt-tabbing etc. is still possible) I still haven't been able to do anything with SDL2. Right now the priority is the message gui handling (told you, I prefer spending time on the game rather than its libraries :-) ). |
|
Looks like I kicked of a something :) |
Heh, might want to add |
HiranChaudhuri
force-pushed
the
master
branch
17 times, most recently
from
4d65277
to
be540a2
Compare
This is an initial (mostly working) port to SDL2.
By default SDL1.2 is still used, but by chaning the config.make
option, SDL2 is used instead as a build-time option.
For current status see commit message and issue #222