New 'Ship Window' problems in Version 2019.01.19

[PlanetariumWSD]

These effects were not present until new version 2019.01.19
NOTE: These same tests were performed on the same hardware with version 2018.09.06 with no negative effects.
PERSONAL NOTE: This is my first bug report so apologies if I am reporting in the wrong place or am not following Git protocols. I'd like to help with this but not sure where to even begin in the source code.

Description:
Ship window alternate view:

1. Screen background turns all white during warp and jump.

2. Black "frames" at certain heading changes producing either total black (at station keeping) or flickering black during rotation (as black 'frames' are inserted at 'black screen headings').

System settings during problem:
version 2019.01.19 on Empty Space scenario with Atlantis (or Flavia) player ship.
(Windows 7 PCs (3)) Server, Client-Helm, Client-"Ship Window "0".

Test 1
Jump -> (Ship Window "0") background turns white during jump.
Warp -> (Ship Window "0") background turns white during any warp speed. ( added warp to each ship for test )

Test 2
Start a heading change and watch (Ship Window "0")
Some result headings for others to test to repeat bug:

Heading's screens are black on (Ship Window "0")
178.2, 178.6, 178.7, 179.9, 180.4, 180.6, 180.8, 180.9, 181.3, 229.2, 229.3, 230

Heading's screens are normal on (Ship Window "0")
178.1, 178.3, 178.5, 181, 181.1

Additional note: We added 3 PC Clients set to Ship Window "288", "0" and "72" for a pan effect of three projectors and the negative effects are present in all ship windows but not in the old version.

[daid]

Screen background turns all white during warp and jump.

This sounds like an issue with the OpenGL shaders, not that they where changed between releases... what kind of GPU are you using, and are the drivers of the GPU up to date?

[PlanetariumWSD]

Thanks daid for responding.
As always, we here have a tremendous amount of gratitude to you, other contributors and this project.
Monday night we did a second alpha test of our sim and students were literally cheering as they worked together. I can't emphasize enough the educational value of this project!

I did some more digging and found..

• Problem exists on other PCs, Win10/Nvidia card and Win7/ATI card.
• Same hardware PCs runs older versions flawlessly so the hardware isn't the main problem.

I've complied with CodeBlocks and libraries downloaded last year.. ( drmingw-0.8.2-win32) , ( SFML-2.5.1. ) and tried running our own compiled version here on both PC platforms with no negative effects.
It's only the new version.
I tried using OUR compiled exe in the NEW program folder..
exe wont run with error:
_"The procedure entry point ZN2sf11SoundStream6onLoopEv could not be located in the dynamic link library sfml-audio-2.dll"
.. So therefore, if the EE source code hasn't changed dramatically, then something else has!
Perhaps in SFML since last year?
Something that's being done at compile time is my main suspect as the root cause of this current graphics problem.

My next step is to update my compile process here with the latest libraries and try those new compiled versions to verify this claim. (ie if the screen problem persists.)
The game's afoot!

[daid]

Yes, SFML version was my next guess, I've upgraded to SFML 2.4.2 (which is most likely also why you are getting that error on the dll, it's a mismatch in DLL/compilers) and I think I was using SFML 2.3.1 before that. So that could also be triggering this. However, then we have an SFML bug on our hand...

[PlanetariumWSD]

To verify that that I can reproduce the screen bug in the new version.
I did a compile test of the newest source code/libraries here using Code Blocks. (following instructions)
The bad: newest source version fails to even compile. (10 errors) txt attached.
buildErrors.txt

So now there's a screen bug & a compile problem.. I'm such a jerk!

I did verify that the same screen problems exists in downloaded 2018-11-16 with the following error messages in cmd window:
Uniform "inputSize" not found in shader
Uniform "camera_position" not found in shader

The good: older v2018-09-06 with those old libraries continue to compile fine and with no screen bugs.
conclusion: Some upgrades in/beyond v2018-11-16 are causing challenges. (Was this when you migrated to SFML 2.4.2 ?)

Is this a "Windows" only problem?
Can the "ship window" shader bug be verified on your normal platform?(Probably not windows)

I don't like being the whiner and normally try to offer solutions instead of errors and will dig into this but must admit... for me, this is a lofty problem.
I thought that, you as the project master, should at least know about the screen bug and compile errors in Code Blocks.
We here can continue working/compiling with old code on our fork for the time being.
It works really well!

[aBlueShadow]

Did you make sure the seriousproton source is the current version too? Had that problem myself a while ago
It seems that shader problem only appears on some plattform. BTW I assume it is not a "ship window" bug, but rather a first person view bug, right? So the problem also occurs on first person mode (pressing F) on the main screen, correct? I guess I saw that error once, but on most machines I could test on(mostly linux), it did not occur to me.
However while testing (rarely used warp so far) I saw problem that seem to be present with warp on all versions: In first person, you can see parts of your own ship when in warp. it seems like this like the slower the computer and/or the connection, the more visible is this issue.
@daid: as this is only vaguely related, should I file a new issue about that?

@PlanetariumWSD As you used ship window as an extended viewscreen, I hope my change on ship window in #621 won't be a problem for you?

[NinjaSpectre]

I made pull request #638 to address the missing updates in the Code::Blocks project file. Hopefully that will resolve at least some of the problems @PlanetariumWSD has encountered.

[PlanetariumWSD]

Thanks everyone, this is good stuff!
_0) Bummer that this appears to be a platform specific problem...
_1) Started over again on the compile process. Re-downloaded all current libraries. Seriousproton source is current. Same 10 compile errors. :-(
_2) I tried again on main screen "F" first person...different characteristics!
No jump/warp white screen but more pronounced black screen problem. i.e No flickering BUT whenever Skybox(Front) is visible, background goes black on the First person (main screen).
Meanwhile on same view/angle (ship window) it flickers, and sometimes black.
Warp/Jump white screen only appears in Ship Window.
Note: 'on screen' heading # values appear unaffected.
_3) Regarding #621 Having a futuristic HUD overlay, instead of simple "glass" windows is beneficial to game play. Since it's already built anyway.. if this proceeds, any chance there could be a switch in a settings.ini file somewhere to have a choice.. (#Headings/Callsigns On/Off in ship window)?
_4) Regarding seeing part of your own ship in warp? I've seen this too, we attributed this to a model scaled too large and the camera was falling back inside the model's surface during warp. Models that have small scale value don't seem to have this problem. However, I've been wrong before.
_5) I'm still new how GIThub pulls/requests/merges work (hope to change that soon), so #638 is a mystery but I sure do appreciate someone who does know and has an idea on this issue!
I'm ready to continue testing things as they develop.

[daid]

Note, I see the code::blocks project as depricated, I should remove it. Rather maintain a single build system, and CMake can build on windows as well.

I'm running windows, but I'm not seeing the graphical bugs that you see. Can you see if setting "disable_shaders=1" in the options.ini removes some or all of the issues.

The reported warning about the missing uniforms is fine/expected.

[PlanetariumWSD]

Sounds like CodeBlocks support is on the way out. The only reason we used it was because the wiki had solid instructions, I see now the CMake instructions here and will invest some time migrating to CMake.

Set "disable_shaders=1" here on version 2019.01.19-win32 downloaded copy.
Result: can't test issue as 'Main Screen' and all other alternate views are no longer options. (Except Alternate View-Game Master on Server)
Since you are not seeing this issue on your Windows rig daid , I feel bad to bother people. Sorry everyone! In due diligence, I tested this with the vanilla downloaded package (no home compiles) here on 2 separate Win machines with both (Win7 & 10) and both (ATI & Nvidia GPUs) that ran previous versions flawlessly and got the same negative results on both.
Intermittent problems have always bothered me the most!

[PlanetariumWSD]

Are there particular features that > SFML 2.3 was needed?
I noticed this thread about upgrading SFML, a resulting merge and a new release posted 4 days later. Since this build (2018.11.16) and newer, issue #636 exists on our diverse Windows test machines. This shader issue basically renders new versions unplayable on all of our various Windows PCs.
I understand that the project is bigger than one site. As the students and I are so appreciative of this project, we did not want to complain or cause any problems and had resigned ourselves to simply modding and building from an old Empty Epsilon 2018.09.06 (SFML 2.3) fork.
Daid's instruction for CodeBlocks worked except for heading font issue and the EXE binary size is way off. (4 MB instead of Daid's normal 21MB)... but it works.
After learning that CodeBlock support was depreciated we decided to comply by using CMake.
We found this great cmake guide by @amir-arad.
However, there are problems with this process that I'll post in that thread.

So we are at a brick wall, with Windows. hah! ;-) Building off of a depreciated fork with a depreciated process. Our dreams would be for the old fully functional days of SFML 2.3 and updated cmake files or build guide to bring us 100% back into project compliance with hopes of becoming contributors and I believe that other Windows based sites could be/are/will have similar issues.

[amir-arad]

I am maintaining a fork of my own as well as you. All that I know about CMake and the CPP echosystem that comes into play in this project (and the tutorial) I've learned while trying to fix or improve this game. I gained a lot thanks to it, but did not enjoy the ride : ) IMO such is the cost of freedom in this open source software world.

can't speak for @daid , but my reason for upgrading SFML is the general principle that integration libraries tend to not age well. SFML 3 already had several minor issues (multi screen in linux, shaders in OSX etc.) that were addressed in later versions. IMO it's just a matter of time untill it became a major issue. As I spent time and efforts upgrading my fork I suggested the change to the main version.

[amir-arad]

also: the downloadable game runs well in linux and OSX under wine. I haven't tried running Ship Window like that, but main screen seemed fine. maybe it's worth checking?

[NinjaSpectre]

If you revert the changes made in 6593121, I believe SFML 2.3 would be able to work for you.
However I wonder if your problems are related to e0b7114 instead.

[PlanetariumWSD]

This is good stuff, Thank you!
@amir-arad's comments made me smile about "not enjoying the ride" for such amazing software freedom [recognize!] I fully can come to grips with his encouragement to do more "wine" to make things better. ;-)
Linux IS a possibility and I've experimented with it over the years, but other needed apps and driver issues usually thwart my efforts.
@NinjaSpectre , these are great ideas indeed. I would LOVE to try these changes in my builds as they look very promising, but the Windows build pipeline is currently dead.
CodeBlocks is depreciated (but maybe I can resuscitate it) and CMake has a crippling "Find SFML" error.
My shop here is Windows and I have student coders on numerous boxes but... maybe I need to acquire a single Linux box JUST for building source? It would drastically limit local student access...
I see that @daid has some Linux build guides. This would be a steep learning curve... but do you have suggestions of Linux flavors or other good software/guides that are similar to your benches? (i.e. What do YOU guys use to make the doughnuts?)

Regrettably, as with all bug squashing code loving people, I suppose I won't be able to resist and will be back banging my head against the iron door of making Cmake build on Windows again soon enough so all of us (students and I) can code together here.

[NinjaSpectre]

True about Code::Blocks support, but since #638 was merged you should be able to build current master (62a0fac) with that project file as a short term solution. (Making path adjustments as necessary for your setup of course.)

[amir-arad]

@PlanetariumWSD did you try the vagrant build?
Although it runs on linux It builds a release-like windows package of the game. it works for me (this is how I build my fork for windows).
just remember to change EE_BUILD_SFML_VERSION

I'm developing on xubuntu and windows (work / home machines). both can build for development, and in the xubuntu I have the vagrant scripts as well, for releases.

[PlanetariumWSD]

Great news thanks to all of these ideas.
Following @NinjaSpectre's advice, I was able to make a Win32 exe with CodeBlocks using (SFML 2.5.1) and it's matching (GCC 7.3.0 MinGW (DW2) - 32-bit)! Elation!
Many of the shader issues in this issue #636 are gone.

• Black screen flicker on rotation
• White background on Warp and Jump.

There remains only 1 new issue, warp and jump black screen and aspect ratio shift.
It's bad, but the fact that it changed is good as it's much less likely related to any EE source code (that didn't change).
I now believe that shader problem #636 is the Warp/Jump Center 'pucker' distort effect on the main screen 3D camera view. (as crew station screen distort with no issues). I'm guessing that the distort on the main screen is handled differently than the crew screens. (SFML and/or OpenGL) and that 2.5.1's method of doing this effect changed internally from 2.3. My next test is to turn this off and report back.

@NinjaSpectre, I can confirm that the main screen 'text to white blocks' are fixed with e0b7114
However, no joy on this main screen problem as described above. The problems appear to be unrelated.

Thanks to all of you!
-Chris

[PlanetariumWSD]

Confirming that issue #636 is caused by warpPostProcessor (lines 89 -94).
When disabled, issue is gone.
I think that the setUniform call is a newer SFML one.
As to why it's happening.. (how warpPost Processor actually works), not sure yet.

EmptyEpsilon/src/screenComponents/indicatorOverlays.cpp

Lines 89 to 94 in 62a0fac

	warpPostProcessor->enabled = true;
	warpPostProcessor->setUniform("amount", my_spaceship->current_warp * 0.01);
	}else if (my_spaceship->jump_delay > 0.0 && my_spaceship->jump_delay < 2.0)
	{
	warpPostProcessor->enabled = true;
	warpPostProcessor->setUniform("amount", (2.0 - my_spaceship->jump_delay) * 0.1);

[daid]

aspect ratio shift.

That's most likely an issue with the RenderTexture that is created, it's created with the same size as the window. However, some 3D drivers only allow you to create textures with power-of-2 sizes, which the code most likely doesn't account properly for.

Simple workaround would always be to disable the post-processors in the code outlined above.

[PlanetariumWSD]

While this works for me because I can now compile from source, I'd like to help other Windows/Power-of-2 size hardware users who might come across this and can't compile from source. It would not be a game killer for them. I could put effort into making an addition to the options.ini like this:
warp_post_processor_enabled=1
.. to allow a simple work around (set to 0) in official releases.
If however, @daid, you do not wish to see this in a pull request, I will not pursue it.

[daid]

I would happily accept a flag to disable the post processor. We have 1 machine where the GL driver fails to properly execute that shader as well (screen turns black). I've always blamed it on the crappy intel GPU in that specific laptop.

[PlanetariumWSD]

Workaround #645 happily submitted thanks to everyone's help. This community is awesome!
This is my first time doing pull requests, so (while my code changes have been heavily tested) apologies if errors or procedural wrong-doings were committed. I'm always open to feedback on ways to improve.

and... I had to edit the pull request as I forgot to #include a header file line.. sorry for the trouble, won't happen again.

[oznogon]

#734 seems to be another manifestation of this issue, with the same workaround

[gcask]

I believe this is fixed by a combination of daid/SeriousProton#77 and #1376 .

[oznogon]

This does appear to be fixed, I'm no longer able to reproduce.