Should SDL be used as the GUI instead of Ogre?

[Mitten.O]

Yes. It is SDL2 only, now.
The old SDL does not support switching between fullscreen and windowed without losing the opengl context.
And it is getting dated anyway. SDL2 is a major update, API incompatible with the old.
For us the transition is relatively easy, since we only really use it to create and manage the window.
Most of the trouble will actually be implementing stuff that was only available in the ogre gui to begin with.

[vincele]

The SDL2 version of the patch is looking good, better than the previous...

* still double mouse pointer
* window is titled, but icon still missing
* the circles around systems are rendered properly
* prodwnd visual glitch fixed
* no segf at quit (for now)

appart from the missing icon, no bug seen in a 3 minutes test...

[vincele]

I'm reading the patch (without knowing anything wrt SDL) and here are my 2 cents:

* Some things are now done differently but still there (f.e. mouse wheel handling) whereas others are just removed (f.e. that unicode thing), you'll have to explain if this is temporary while developing the patch or not needed any more, or whatever. Without context I can't understand why you do this.

* please refrain from mixing in the patch some gratuitous code churn (f.e. SDL_keysym -> SDL_Keysym), I'm not against the cleaning up, but put it in another patch that does only cleanups, it'll be easier reviewing those things separately.

* in UI/GraphicsSystem.cpp you're mixing "if (thing)" & "if ( thing )" styles

* in UI/GraphicsSystem.h typos in comment :GrphicsSystem is a thin wrapper around the library used for creating the window and managind video modes, etc.

* in GG/src/SDL/CMakeLists.txt would it be possible to keep "SDL_" variable names, to keep them consistent with client/human/CMakeLists.txt usage ?

* in client/human/HumanClientApp.cpp I don't understand the comment "Note that this call leaves the depth of the viewing volume is only 1"

Appart from that nitpicking the patch looks promising

[Mitten.O]

* Some things are now done differently but still there (f.e. mouse wheel handling) whereas others are just removed (f.e. that unicode thing), you'll have to explain if this is temporary while developing the patch or not needed any more, or whatever. Without context I can't understand why you do this.

The unicode thing: not needed anymore. SDL2 has a robust text input system, it does not need that anymore.
Unfortunately it is so robust that it does not map directly to GG events, which led to the capital letter quirk.
See the SDL migration guide, which is my main source of information on the SDL => SDL2 part of this patch.
wiki.libsdl.org/MigrationGuide

Much of the other stuff is just temporarily away until I get around to SDL implementations.

* please refrain from mixing in the patch some gratuitous code churn (f.e. SDL_keysym -> SDL_Keysym), I'm not against the cleaning up, but put it in another patch that does only cleanups, it'll be easier reviewing those things separately.

C++ is case sensitive. That change is semantic, I think they changed the type name.
There may of course be other, nonsemantic changes, especially since this patch begun as "let's see if this works".
It still is that, I suppose, but since SDL seems to avoid some issues, the probability that we go this path is on the increase,
so I'll try to be careful. The option of just replacing the input system may still be worth some study, though.

UI/GraphicsSystem.cpp

I'll try to pay attentintion to the details. The thing is, I am not entirely sure where I am going with this, yet.
The OgreGUI adds a bunch of feature on top of GUI, which is already fairly large, and HumanClientApp
uses the ogre internals directly in many ways. I think this stuff needs to be abstracted somewhere.
Structurally, just moving all this to GUI would make sense, initially, but as I said, it is already a fairly large interface,
and the stuff already there is actually more about all the GG windows and events and their rendering,
not this lower level stuff.

That is the reasoning behind the GraphicsSystem: we need an interface for the gritty screen handling things.
But determining what to move there and what to keep, and the best relationship between a GUI implementation
and the corresponding GraphicsSystem are still a bit in the open. I'm not even quite sure about the name of the interface.

* in GG/src/SDL/CMakeLists.txt would it be possible to keep "SDL_" variable names, to keep them consistent with client/human/CMakeLists.txt usage ?

No. In fact, the error is having the old names in client/human/CMakeLists.txt. I'll fix it.

* in client/human/HumanClientApp.cpp I don't understand the comment "Note that this call leaves the depth of the viewing volume is only 1"

That comment is part of the copy paste from the minimal GG app example, I think. OpenGL does not draw things that are too close to or too far from
the camera. That comment just notifies the user that the distance between those two cut-offs is rather small with the settings,
which is ok for 2d, since we only draw on a single plane.

I have made some more progress, but am having huge trouble with fullscreen.
There are in fact two issues I am struggling with:
* Changing to a lower resolution switches me to panning mode: eg: 800x600 resolution, 1920x1080 FreeOrion, which the display pans around.
I have had this issue with other games, especially with wine.
* Shutting down FreeOrion does not always restore the desktop to its original resolution, but it stays at the freeorion resolution.
I have also run to this issue with other games in linux. Apparently calling SDL_Quit properly in all cases should address this, but we'll see.

I'll see if I can iron these issues out and post more code. Based on some discussion around the web, the issues may not be truly fixable,
but should be work-aroundable. And mileage will vary greatly between windows and linux.

Resizing a windowed FreeOrion is working, perhaps I'll separate that and post just it if fullscreen keeps giving me trouble.
Desktop resolution fullscreen has no problems, either.

[Mitten.O]

Well here is the current version.
It is in pretty much the state I described yesterday:
Resizing the window works, native resolution fullscreen works,
other resolutions for fullscreen don't.

SDL2 has a special SDL_WINDOW_FULLSCREEN_DESKTOP mode specifically to
allow you to live like you have a lower resolution, while actually avoiding mode changes.
Unfortunately that does not really help us, since it does not apply when using native OpenGL calls like we do.

It may be necessary to use the work-around described here
https://forums.libsdl.org/viewtopic.php ... 8a7a944738.
Basically render the game on the lower resolution off-screen and then
render the generated image on a single quad on the main screen,
letting the GPU scale it to the native resolution, avoiding any mode changes.

What interests me now is how the current resolution switching code works on windows and mac.

I think I'll leave wrangling the fullscreen for now and move on to other annoyances, like the cursor.

[Geoff the Medio]

I think I'll leave wrangling the fullscreen for now and move on to other annoyances, like the cursor.

My recollection is that prior to the Ogre transition, there was no in-game rendered cursor, and just the Windows cursor was shown. I don't recall there being any issues with delays between where the game thought the mouse was and where the OS displayed it. Taking a look at what was done back then might be useful... Although the ideal would be for the game to have a non-delayed cursor that uses OS-derived position information, but in-game rendering of the cursor while hiding the OS cursor only while the mouse position is within the game window.

[Mitten.O]

Progress.

I now just hide the software cursor.
I like the responsiveness of the hardware cursor,
so here's hoping there is no trouble with it.

Also, capital letters are back!
In fact, I wired in the entire SDL2 TEXTINPUT logic to GiGi.
It separates key pressing from text input.
According to the SDL2 propaganda, it should allow for all sorts
of fancy unicode input methods.

And at least for me, the combination keys for the umlaut and such seems to be working now,
whereas they didn't before. The screenshots show the current and previous results of pressing
the " key, then then u. The same thing with ^ + a = â and so on. Fancy. õlé.

[Geoff the Medio]

I now just hide the software cursor.
I like the responsiveness of the hardware cursor,
so here's hoping there is no trouble with it.

Does it actually click in freeorion where you click with the OS mouse cursor? When rendering the GG cursor and there was noticeable delay between the two, clicks only seemed to be recognized where the GG cursor was showing...

[Mitten.O]

My experience (ubuntu linux) with the SDL software cursor was that it was invisible most of the time,
since it was almost always precisely below the hardware one.
And when, after a quick long movement, it wasn't,
it caught up in less time than it would take me to make even a reflexive,
I am on the button, time to click - decision.

Now that it is hidden, I can't detect any inaccuracy even when I try,
although since the cursor did reveal itself as a double at times,
there must be some. YMMV, but if the variance is tolerable, this ought to work.
Have you tested the patch? I updated the translator script to change tabs into spaces,
so it might apply. I no longer dare say ought to apply, that would be too optimistic.

[Geoff the Medio]

YMMV, but if the variance is tolerable, this ought to work.

If you're barely ever able to see the delay between the cursors, it's probably not a fair test

Have you tested the patch?

No. Presumably I'd need to build SDL2 and hook it into the build system first...?

[vincele]

YMMV, but if the variance is tolerable, this ought to work.

If you're barely ever able to see the delay between the cursors, it's probably not a fair test

I think you have too much CPU power, I almost always can see the lag between cursors on mine...
I'll test the new patch

[Mitten.O]

Here is the same patch created with a hopefully better version of the svn-ification script.

No. Presumably I'd need to build SDL2 and hook it into the build system first...?

Ah, yes. I forget the hardships of programming on windows.
You shouldn't need to compile it yourself, the library and the necessary headers are
available separately here: https://www.libsdl.org/download-2.0.php.

I almost always can see the lag between cursors on mine...

Oh. Still, eyes have a much higher FPS than fingers.
But if problems do arise, hiding the hardware one shouldn't be too challenging.

[Geoff the Medio]

But if problems do arise, hiding the hardware one shouldn't be too challenging.

Ideally there would be separate options to independently toggle showing the OS and in-game cursors.

[vincele]

I quickly test the .3 patch, and it's good wrt cursor, I'll do more testing under heavy cpu load later.
Only problem spotted (it may be as currently designed) is when toggling fullscreen. Cannot tell exactly with words, but resolution was not what I expected...

Edit: when toggling FS, the resolution changes properly (it looks like), but the screen is not re-rendered, so it looks scaled down/up...

I have to leave now, but will be following on this.

[Mitten.O]

Whoops, silly me. On more detailed reading of the SDL documentation and GiGi code,
the cursor that is currently being hidden is in fact the hardware one.
The one being shown is the GiGi one.
So ... all is well, I suppose.