upgrade to sfml 2.5 and add win32 cross-compilation script

[amir-arad]

@gmyuval did the bulk of the work on this one
closes #566

[czenker]

Hey Amir.

Thanks to you and @gmyuval for the update.

I gave this patch a try on Debian. During compilation some deprecation warnings from SFML came up, but those should be easy to fix afterwards. I saw some for sf::Text::setColor, sf::RenderTexture::create and sf::Shader::setParameter. So nothing too serious – the rest went without complication.

After a few looks at the game it does look fine (checked the keyboard events also).

The only issue I found seems to be with fonts. They render as blocks in the 3D-View

Surprisingly this does not happen in Top-Down View. Also my personal impression is that rendering of the fonts got a little worse for the big fonts, but this might also be related to rescaling windows which has caused issues before.

[amir-arad]

The only clue i've got for the fonts render as blocks in 3-d view is that I can reproduce it when rendering text on top of a 3d model (like a 'GuiLabel' over GuiRotatingModelView). if the text is under the 3-d model it renders fine.
help /hints appreciated (@daid ?)

[daid]

Sounds like something with the alpha or depth buffer, or blending configuration.

EE uses both SFML and OpenGL rendering. SFML uses OpenGL under the hood as well, and expects the OpenGL state to be in a certain state. The 3D part is render with OpenGL, but the labels on top are rendered with SFML.

This line should restore the OpenGL state:
https://github.com/daid/EmptyEpsilon/blob/master/src/screenComponents/viewport3d.cpp#L303
But it's known to not always restore everything.
First thing to look at is the blending function (glBlendFunc) as that's a possible suspect for this cause.

[amir-arad]

after reading SFML 2.5 documentation on Using OpenGL together with the graphics module it seems that the way they reccomend to manage GL state is the opposite of what EE's viewport and GuiRotatingModelView are doing - the state needs to be pushed after GL operations and poped before. I've added a fix and tested on my linux machine. it's so basic that i suspect i missed something... would appreciate more eyes on this.

[czenker]

I can confirm that the change also fixes the font issue in 3D view for me (on Linux).

Thanks @amir-arad.

[gwaland]

The changes to the build setup break the vagrant scripts I use to build EE but the actual push/pop changes do fix the font rendering on windows for me.

[amir-arad]

The changes to the build setup break the vagrant scripts I use to build EE

@gwaland vagrant build automation? please share!

[gwaland]

https://github.com/gwaland/EmptyEpsilon-build-scripts is what I'm currently using. Most of my testing is done with the 18.04 version.

I forked it from https://github.com/oznogon/EmptyEpsilon-build-scripts
I'm pretty sure it was based on Kwadroke's old scripts.

[amir-arad]

@gwaland oh wow. these scripts would have saved me days of work.

anyways, what specifically in the build setup breaks the vagrant scripts?
if you manage to build EE with SFML >= 2.5 for windows with these scripts, i would be happy to use your scripts as well

[gwaland]

So I tested and my build script relies on the following files:

cmake/FindSFML.cmake
cmake/mingw.toolchain

and line 382 in CMakeLists.txt had to be reverted. At that point it was able to build successfully using your patches with SFM 2.5.

[amir-arad]

@gwaland just to clarify : a working win32 exe?

[gwaland]

Yes this results in a functional windows executable. Here is the output zip file that the script I use generates after the changes I mentioned above. The exe works on two of my test systems.

https://www.dropbox.com/s/felpzm2yteapqi7/EmptyEpsilon_20181104_909c4cdeca7a801df9a50bc772445ca918faa93e.zip?dl=0

[amir-arad]

most of the code changes in this PR was aimed to fix a non-problem of recreating the windows build for new SFML version. closing this in favor of new and lean #591