New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

-window command-line argument not working #1051

Closed
Goober5000 opened this Issue Oct 17, 2016 · 34 comments

Comments

Projects
None yet
6 participants
@Goober5000
Contributor

Goober5000 commented Oct 17, 2016

I tried launching FSO with -window, both using the MSVC 2015 debugger and specifying -window in the command-line using wxLauncher. In all attempts, FSO launched full-screen.

@Goober5000 Goober5000 added the bug label Oct 17, 2016

@niffiwan

This comment has been minimized.

Show comment
Hide comment
@niffiwan

niffiwan Oct 17, 2016

Member

Interesting, I have been using FSO windowed on Linux just fine. Did you change the resolution in conjunction with setting -window?

Member

niffiwan commented Oct 17, 2016

Interesting, I have been using FSO windowed on Linux just fine. Did you change the resolution in conjunction with setting -window?

@Goober5000

This comment has been minimized.

Show comment
Hide comment
@Goober5000

Goober5000 Oct 17, 2016

Contributor

Nope. I decided to try changing the resolution anyway; no effect.

Contributor

Goober5000 commented Oct 17, 2016

Nope. I decided to try changing the resolution anyway; no effect.

@MageKing17

This comment has been minimized.

Show comment
Hide comment
@MageKing17

MageKing17 Oct 17, 2016

Member

Working fine for me (just compiled current master to double-check); when did it stop working for you?

Member

MageKing17 commented Oct 17, 2016

Working fine for me (just compiled current master to double-check); when did it stop working for you?

@Goober5000

This comment has been minimized.

Show comment
Hide comment
@Goober5000

Goober5000 Oct 17, 2016

Contributor

It's the first time I've compiled FSO in a while. I noticed it as soon as I compiled from latest master.

I'll try on another computer and see if I get the same thing.

Contributor

Goober5000 commented Oct 17, 2016

It's the first time I've compiled FSO in a while. I noticed it as soon as I compiled from latest master.

I'll try on another computer and see if I get the same thing.

@Goober5000

This comment has been minimized.

Show comment
Hide comment
@Goober5000

Goober5000 Oct 17, 2016

Contributor

Same thing. Both Windows 7, but one was MSVC 2013 and one was MSVC 2015. I also traced through the command-line code to be sure that Cmdline_window was getting set (it was) and not getting unset by fullscreen-window (it wasn't).

Contributor

Goober5000 commented Oct 17, 2016

Same thing. Both Windows 7, but one was MSVC 2013 and one was MSVC 2015. I also traced through the command-line code to be sure that Cmdline_window was getting set (it was) and not getting unset by fullscreen-window (it wasn't).

@Goober5000

This comment has been minimized.

Show comment
Hide comment
@Goober5000

Goober5000 Oct 17, 2016

Contributor

Oh, I should have mentioned - on the other computer, a build I compiled on 10/3 shows the erroneous behavior. The 3.7.4 Final build behaves as expected.

Contributor

Goober5000 commented Oct 17, 2016

Oh, I should have mentioned - on the other computer, a build I compiled on 10/3 shows the erroneous behavior. The 3.7.4 Final build behaves as expected.

@Goober5000

This comment has been minimized.

Show comment
Hide comment
@Goober5000

Goober5000 Dec 3, 2016

Contributor

Latest source still exhibits this behavior.

Contributor

Goober5000 commented Dec 3, 2016

Latest source still exhibits this behavior.

@asarium

This comment has been minimized.

Show comment
Hide comment
@asarium

asarium Dec 3, 2016

Member

Which commit introduced the bug?

Member

asarium commented Dec 3, 2016

Which commit introduced the bug?

@Goober5000

This comment has been minimized.

Show comment
Hide comment
@Goober5000

Goober5000 Dec 4, 2016

Contributor

Tried to bisect, immediately ran into a CMake issue. Details here:
http://www.hard-light.net/forums/index.php?topic=92318.msg1835920#msg1835920

Contributor

Goober5000 commented Dec 4, 2016

Tried to bisect, immediately ran into a CMake issue. Details here:
http://www.hard-light.net/forums/index.php?topic=92318.msg1835920#msg1835920

@z64555

This comment has been minimized.

Show comment
Hide comment
@z64555

z64555 Dec 4, 2016

Member

Windowed mode works just fine on my machine. Windows 10, VS 2013, latest source.

Member

z64555 commented Dec 4, 2016

Windowed mode works just fine on my machine. Windows 10, VS 2013, latest source.

@Goober5000

This comment has been minimized.

Show comment
Hide comment
@Goober5000

Goober5000 Dec 4, 2016

Contributor

Never mind, I'm retarded. CMake wasn't added until after 3.7.4. Continuing to bisect.

Contributor

Goober5000 commented Dec 4, 2016

Never mind, I'm retarded. CMake wasn't added until after 3.7.4. Continuing to bisect.

@asarium

This comment has been minimized.

Show comment
Hide comment
@asarium

asarium Dec 4, 2016

Member

If you have issues with the bisect because you keep switching between CMake and pre-CMake you could try starting from the first CMake commit which was a3c674b.

Member

asarium commented Dec 4, 2016

If you have issues with the bisect because you keep switching between CMake and pre-CMake you could try starting from the first CMake commit which was a3c674b.

@Goober5000

This comment has been minimized.

Show comment
Hide comment
@Goober5000

Goober5000 Dec 4, 2016

Contributor

...And the first CMake commit is the one that introduced the -window problem. O.o

1bcd5400d331aa38d6f52a215bea54803879cc62 is the first bad commit
commit 1bcd5400d331aa38d6f52a215bea54803879cc62
Author: asarium <asarium@gmail.com>
Date:   Thu Jul 21 10:04:42 2016 +0200

    Move build system to CMake
Contributor

Goober5000 commented Dec 4, 2016

...And the first CMake commit is the one that introduced the -window problem. O.o

1bcd5400d331aa38d6f52a215bea54803879cc62 is the first bad commit
commit 1bcd5400d331aa38d6f52a215bea54803879cc62
Author: asarium <asarium@gmail.com>
Date:   Thu Jul 21 10:04:42 2016 +0200

    Move build system to CMake
@Goober5000

This comment has been minimized.

Show comment
Hide comment
@Goober5000

Goober5000 Dec 4, 2016

Contributor

And before anyone asks, each time I tested a build I set a breakpoint to confirm that Cmdline_window was being assigned as expected.

Contributor

Goober5000 commented Dec 4, 2016

And before anyone asks, each time I tested a build I set a breakpoint to confirm that Cmdline_window was being assigned as expected.

@z64555

This comment has been minimized.

Show comment
Hide comment
@z64555

z64555 Dec 11, 2016

Member

So Cmdline_window was being set in each test, correct?

Edit: Oh you said that already. derp.

Member

z64555 commented Dec 11, 2016

So Cmdline_window was being set in each test, correct?

Edit: Oh you said that already. derp.

@MageKing17

This comment has been minimized.

Show comment
Hide comment
@MageKing17

MageKing17 Dec 11, 2016

Member

How many different ways did you want him to say it?

I just don't understand why the problem appeared with the CMake merge, but not for anybody else.

Member

MageKing17 commented Dec 11, 2016

How many different ways did you want him to say it?

I just don't understand why the problem appeared with the CMake merge, but not for anybody else.

@z64555

This comment has been minimized.

Show comment
Hide comment
@z64555

z64555 Dec 11, 2016

Member

I did a cursory search through that commit's log and the accompanying merge commit, and didn't find anything to suggest a change that would prevent Cmdline_window from being set, Nor did I find anything that would change the logic that handles it.

Member

z64555 commented Dec 11, 2016

I did a cursory search through that commit's log and the accompanying merge commit, and didn't find anything to suggest a change that would prevent Cmdline_window from being set, Nor did I find anything that would change the logic that handles it.

@z64555

This comment has been minimized.

Show comment
Hide comment
@z64555

z64555 Dec 11, 2016

Member

@Goober5000 Could you do a diff between your local master branch and the source repo? It could be possible that your local got rebased onto a different source or otherwise got corrupted.

Member

z64555 commented Dec 11, 2016

@Goober5000 Could you do a diff between your local master branch and the source repo? It could be possible that your local got rebased onto a different source or otherwise got corrupted.

@niffiwan

This comment has been minimized.

Show comment
Hide comment
@niffiwan

niffiwan Dec 12, 2016

Member

IIRC Goober has a reasonably uncommon video card, maybe there's a SDL2/Driver interaction issue at fault?

Member

niffiwan commented Dec 12, 2016

IIRC Goober has a reasonably uncommon video card, maybe there's a SDL2/Driver interaction issue at fault?

@Goober5000

This comment has been minimized.

Show comment
Hide comment
@Goober5000

Goober5000 Dec 12, 2016

Contributor

@z64555 There are no differences between origin/master and upstream/master.

@niffiwan I tested it on two laptops, one compiling with VS 2013 and one compiling with VS 2015. One uses an NVIDIA NVS 4200M card, and one uses either an Intel Integrated or an NVIDIA Quadro K2100M (I tried it on each). In all cases the identical behavior is observed.

Did CMake roll in any sort of configuration change in addition to its new method of building projects?

Addendum: For S&G, I tried testing the latest Nightly. Both the release and the FASTDEBUG stubbornly went to full-screen. This also rules out a difference between AVX (from my compiled builds) and SSE2 (from the Nightly) which I had wondered about.

Addendum2: I tested the Nightly builds on either side of the CMake merge. Before the merge, No-SSE, SSE, SSE2, and AVX all ran in the window. After the merge, SSE2 (the only type supplied) insisted on full-screen.

Contributor

Goober5000 commented Dec 12, 2016

@z64555 There are no differences between origin/master and upstream/master.

@niffiwan I tested it on two laptops, one compiling with VS 2013 and one compiling with VS 2015. One uses an NVIDIA NVS 4200M card, and one uses either an Intel Integrated or an NVIDIA Quadro K2100M (I tried it on each). In all cases the identical behavior is observed.

Did CMake roll in any sort of configuration change in addition to its new method of building projects?

Addendum: For S&G, I tried testing the latest Nightly. Both the release and the FASTDEBUG stubbornly went to full-screen. This also rules out a difference between AVX (from my compiled builds) and SSE2 (from the Nightly) which I had wondered about.

Addendum2: I tested the Nightly builds on either side of the CMake merge. Before the merge, No-SSE, SSE, SSE2, and AVX all ran in the window. After the merge, SSE2 (the only type supplied) insisted on full-screen.

@chief1983

This comment has been minimized.

Show comment
Hide comment
@chief1983

chief1983 Dec 12, 2016

Member

Comparing upstream master to origin's master isn't technically answering the question, because your local branch could have changed in it. You would need to compare it directly with one of the remote master branches to be sure. But a "git status" will work in that case, as it will tell you if your local branch and the upstream one it tracks have diverged (if your local branch still tracks a remote). "git rev-parse HEAD master origin/master upstream/master" is an easy way to compare all relevant references.

I don't know that testing the nightlies only is sufficient enough to narrow it down to that, might need to do a proper git bisect.

Member

chief1983 commented Dec 12, 2016

Comparing upstream master to origin's master isn't technically answering the question, because your local branch could have changed in it. You would need to compare it directly with one of the remote master branches to be sure. But a "git status" will work in that case, as it will tell you if your local branch and the upstream one it tracks have diverged (if your local branch still tracks a remote). "git rev-parse HEAD master origin/master upstream/master" is an easy way to compare all relevant references.

I don't know that testing the nightlies only is sufficient enough to narrow it down to that, might need to do a proper git bisect.

@MageKing17

This comment has been minimized.

Show comment
Hide comment
@MageKing17

MageKing17 Dec 12, 2016

Member

I don't know that testing the nightlies only is sufficient enough to narrow it down to that, might need to do a proper git bisect.

My understanding was that he tested recent nightlies only to verify the problem wasn't with his compiler.

Member

MageKing17 commented Dec 12, 2016

I don't know that testing the nightlies only is sufficient enough to narrow it down to that, might need to do a proper git bisect.

My understanding was that he tested recent nightlies only to verify the problem wasn't with his compiler.

@chief1983

This comment has been minimized.

Show comment
Hide comment
@chief1983

chief1983 Dec 12, 2016

Member

Ah my bad

Member

chief1983 commented Dec 12, 2016

Ah my bad

@niffiwan

This comment has been minimized.

Show comment
Hide comment
@niffiwan

niffiwan Dec 13, 2016

Member

This is nuts. Maybe post a log from your tests, just in case there's something else that we can spot? (#alloutofgoodideas)

Member

niffiwan commented Dec 13, 2016

This is nuts. Maybe post a log from your tests, just in case there's something else that we can spot? (#alloutofgoodideas)

@Goober5000

This comment has been minimized.

Show comment
Hide comment
@Goober5000

Goober5000 Jan 16, 2017

Contributor

I somehow missed all updates to this issue subsequent to December 11. I did do git status pretty frequently and it didn't complain that local and upstream had diverged.

I'll see about posting a log from a build both before and after the merge.

Contributor

Goober5000 commented Jan 16, 2017

I somehow missed all updates to this issue subsequent to December 11. I did do git status pretty frequently and it didn't complain that local and upstream had diverged.

I'll see about posting a log from a build both before and after the merge.

@Goober5000

This comment has been minimized.

Show comment
Hide comment
@Goober5000

Goober5000 Jan 30, 2017

Contributor

Okay, so there may be some other variables that changed around the time of the CMake merge. This is the first nightly build that demonstrates the error.

Here are logs from "before" (when -window worked) and "after" (when -window had no effect).

before-fs2_open_3_7_5_SSE2_20160725_4b2c2d6-DEBUG.log.txt
after-fs2_open_3_7_5_20160727_6646bf3_SSE2-FASTDBG.log.txt

Contributor

Goober5000 commented Jan 30, 2017

Okay, so there may be some other variables that changed around the time of the CMake merge. This is the first nightly build that demonstrates the error.

Here are logs from "before" (when -window worked) and "after" (when -window had no effect).

before-fs2_open_3_7_5_SSE2_20160725_4b2c2d6-DEBUG.log.txt
after-fs2_open_3_7_5_20160727_6646bf3_SSE2-FASTDBG.log.txt

@MageKing17

This comment has been minimized.

Show comment
Hide comment
@MageKing17

MageKing17 Jan 30, 2017

Member

Initializing OpenGL graphics device at 1440x900 with 32-bit color...

Initializing OpenGL graphics device at 1920x1200 with 32-bit color...

That's the only thing that jumps out at me.

Member

MageKing17 commented Jan 30, 2017

Initializing OpenGL graphics device at 1440x900 with 32-bit color...

Initializing OpenGL graphics device at 1920x1200 with 32-bit color...

That's the only thing that jumps out at me.

@Goober5000

This comment has been minimized.

Show comment
Hide comment
@Goober5000

Goober5000 Jan 30, 2017

Contributor

I didn't change my settings between those two runs. I assume that's different because the window is a smaller area than the full desktop.

Contributor

Goober5000 commented Jan 30, 2017

I didn't change my settings between those two runs. I assume that's different because the window is a smaller area than the full desktop.

@asarium

This comment has been minimized.

Show comment
Hide comment
@asarium

asarium Jan 30, 2017

Member

There was a change in the CMake migration that altered from where FSO read the configuration values so that might explain why the OpenGL resolution is different pre- and post-CMake.

Member

asarium commented Jan 30, 2017

There was a change in the CMake migration that altered from where FSO read the configuration values so that might explain why the OpenGL resolution is different pre- and post-CMake.

@Goober5000

This comment has been minimized.

Show comment
Hide comment
@Goober5000

Goober5000 Feb 11, 2017

Contributor

All right, I'm of a mind to offer an additional bug-hunting bounty for just this bug. Without windowing capability, I can't use the Visual Studio debugger.

Contributor

Goober5000 commented Feb 11, 2017

All right, I'm of a mind to offer an additional bug-hunting bounty for just this bug. Without windowing capability, I can't use the Visual Studio debugger.

@Goober5000

This comment has been minimized.

Show comment
Hide comment
@Goober5000

Goober5000 Feb 11, 2017

Contributor

Problem solved. Bit of a nasty comedy of errors.

a) It turns out that FSO was just creating a window the size of the screen. But historically, it used to be obvious when this happened - you could see the title bar or the window borders impinging on the screen somewhere. This didn't happen on either of the two computers I tested.

b) Although I tested builds on two different computers, the computer where I ran the bisection had wxLauncher 0.9.4, which didn't properly handle the configuration in two different locations. This probably explained the resolution change as suggested by @asarium.

c) The Latest Changes page in the wxLauncher help displays 0.9.0, leading me to believe wxLauncher was the same version on both computers. Someone should add an easily-visible place to display the version number. Someone should also update the help files.

The computer where I didn't run the bisection had 0.10.1, which handled the configuration properly. Once I lowered the resolution, the -window argument indeed launched FSO in a window. When I updated wxLauncher on the other computer from 0.9.4 to 0.10.1, it worked too.

Since I formally posted about a bounty for this bug I'm happy to honor it. Looks like three people deserve credit: @MageKing17 for noticing the resolution change, @asarium for pointing out the configuration, and @z64555 for making the IRC comment that led to the "eureka" moment. Please PM me on HLP, IRC, or Discord and we'll see about making that happen.

As for how to prevent confusion like this in the future, I'm open to suggestions. Two things that should happen I mentioned in c) above. Also, I think there should be a message in the log file that warns if -window is active at the same time that the game resolution is equal to the desktop resolution.

Contributor

Goober5000 commented Feb 11, 2017

Problem solved. Bit of a nasty comedy of errors.

a) It turns out that FSO was just creating a window the size of the screen. But historically, it used to be obvious when this happened - you could see the title bar or the window borders impinging on the screen somewhere. This didn't happen on either of the two computers I tested.

b) Although I tested builds on two different computers, the computer where I ran the bisection had wxLauncher 0.9.4, which didn't properly handle the configuration in two different locations. This probably explained the resolution change as suggested by @asarium.

c) The Latest Changes page in the wxLauncher help displays 0.9.0, leading me to believe wxLauncher was the same version on both computers. Someone should add an easily-visible place to display the version number. Someone should also update the help files.

The computer where I didn't run the bisection had 0.10.1, which handled the configuration properly. Once I lowered the resolution, the -window argument indeed launched FSO in a window. When I updated wxLauncher on the other computer from 0.9.4 to 0.10.1, it worked too.

Since I formally posted about a bounty for this bug I'm happy to honor it. Looks like three people deserve credit: @MageKing17 for noticing the resolution change, @asarium for pointing out the configuration, and @z64555 for making the IRC comment that led to the "eureka" moment. Please PM me on HLP, IRC, or Discord and we'll see about making that happen.

As for how to prevent confusion like this in the future, I'm open to suggestions. Two things that should happen I mentioned in c) above. Also, I think there should be a message in the log file that warns if -window is active at the same time that the game resolution is equal to the desktop resolution.

@asarium

This comment has been minimized.

Show comment
Hide comment
@asarium

asarium Feb 11, 2017

Member

One possible cause for your issues may be that we tell SDL to center the window on the screen. If SDL actually centers the viewable area on the the screen then the window borders will not be visible at all. One possible solution for this would be to tell SDL not to center the window when it has the same size as the desktop. What Windows version are you on? When I use Windows 10 I always see the window borders but that may not be the case in earlier Windows versions.

Since I formally posted about a bounty for this bug I'm happy to honor it. Looks like three people deserve credit: @MageKing17 for noticing the resolution change, @asarium for pointing out the configuration, and @z64555 for making the IRC comment that led to the "eureka" moment. Please PM me on HLP, IRC, or Discord and we'll see about making that happen.

At least for me, that's not necessary since I didn't contribute much to this issue.

Member

asarium commented Feb 11, 2017

One possible cause for your issues may be that we tell SDL to center the window on the screen. If SDL actually centers the viewable area on the the screen then the window borders will not be visible at all. One possible solution for this would be to tell SDL not to center the window when it has the same size as the desktop. What Windows version are you on? When I use Windows 10 I always see the window borders but that may not be the case in earlier Windows versions.

Since I formally posted about a bounty for this bug I'm happy to honor it. Looks like three people deserve credit: @MageKing17 for noticing the resolution change, @asarium for pointing out the configuration, and @z64555 for making the IRC comment that led to the "eureka" moment. Please PM me on HLP, IRC, or Discord and we'll see about making that happen.

At least for me, that's not necessary since I didn't contribute much to this issue.

@chief1983

This comment has been minimized.

Show comment
Hide comment
@chief1983

chief1983 Feb 11, 2017

Member

You should be using wxlauncher 0.12.0 rc2 on Windows probably. I also ran into this issue the other night, thought I had hit the same bug. I had set my windowed res to 1920x1200 instead of 1920x1080 and had the same issue, it covered my screen and looked full-screen to me. Then I realized shortly thereafter that I had picked the wrong windowed res.

Member

chief1983 commented Feb 11, 2017

You should be using wxlauncher 0.12.0 rc2 on Windows probably. I also ran into this issue the other night, thought I had hit the same bug. I had set my windowed res to 1920x1200 instead of 1920x1080 and had the same issue, it covered my screen and looked full-screen to me. Then I realized shortly thereafter that I had picked the wrong windowed res.

@Goober5000

This comment has been minimized.

Show comment
Hide comment
@Goober5000

Goober5000 Feb 11, 2017

Contributor

I'm now using 0.12.0-rc2 on both computers per @MageKing17's advice on IRC.

@asarium Not centering the window when it's the same as the desktop would be valuable, since it would restore the visual clue, but I'd like there to be a log message too. I'm using Windows 7 on both computers.

Contributor

Goober5000 commented Feb 11, 2017

I'm now using 0.12.0-rc2 on both computers per @MageKing17's advice on IRC.

@asarium Not centering the window when it's the same as the desktop would be valuable, since it would restore the visual clue, but I'd like there to be a log message too. I'm using Windows 7 on both computers.

asarium added a commit to asarium/fs2open.github.com that referenced this issue Feb 12, 2017

Create main window at 0,0 if its the same size as the display
This fixes #1051 by explicity telling SDL to create the window in the
display corner instead of centering the window. This has caused some
problems because the window borders aren't visible anymore in this case
which lead to some confusion.

asarium added a commit to asarium/fs2open.github.com that referenced this issue Feb 12, 2017

Create main window at 0,0 if its the same size as the display
This fixes #1051 by explicity telling SDL to create the window in the
display corner instead of centering the window. This has caused some
problems because the window borders aren't visible anymore in this case
which lead to some confusion.

asarium added a commit to asarium/fs2open.github.com that referenced this issue Feb 12, 2017

Create main window at 0,0 if its the same size as the display
This fixes #1051 by explicity telling SDL to create the window in the
display corner instead of centering the window. This has caused some
problems because the window borders aren't visible anymore in this case
which lead to some confusion.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment