Unable to transfer when full screen

[jsno8192]

Eric reported this bug 24SEP20:

"I can't transfer when the application is in fullscreen mode. No idea why, that's the mode with the game window taking up the left hand side of the viewport."

[jsno8192]

I'm not able to fault this action. It works for me.

• Set window to full screen.
• Transfer to another droid.

I need more details.

[brickviking]

Environment here is a tiling Window Manager called xmonad on 64-bit Fedora Core 28, as I can't get the problem to show up under either Plasma or Gnome Shell. I suspect that other tiling window managers might have some of the same issues (i3, etc). I'll do a bit of testing.

[brickviking]

I have a feeling it's got something to do with the "monocle" mode of xmonad, which creates a very-nearly-full-screen window to run the game in, but the game window rendering portion renders in the left hand side of the window. The weird thing is: in that mode, it seems to think that the "middle" of the screen is the middle of the whole rendered fullscreen window, when it isn't actually, it's only the left hand side. So there's a misregistration of where the game thinks the pointer is vs where the OS thinks the mouse pointer is. We used to have a function as part of mouse_lock that centred the pointer on the centre of the window, I'll have to go look that up again.

Turning it back to fullscreen seems to correct the problem.

[brickviking]

More details, this time for Gnome Shell. I have a screen resolution of 1600x900. Yep, weird, but I got it to work.

When I start the game, it's in window mode and is presumably the right size. When I make the game fullscreen (Alt-Enter) the game shows the same behaviour as before, i.e. I shoot in a different direction than my mouse pointer appears to be and the game is offset to the left hand side (left hand of game is left hand of window, right hand side of game is about 50% of window width). I get roughly the same behaviour if I maximize the window instead.

The other thing is, the top of the game is not at the top of the window. It's a bit down (perhaps 100px, maybe 200px) from the top.

I surmise that the game thinks the window's drawing to the centre, but the OS is feeding the mouse events through as it finds them and displaying the game on the bottom left corner.

[jsno8192]

Yeah, I agree with your conclusion. The problem is GLUT is dumb outside it's scope. It doesn't know about desktop environments or hardware. It reacts to the world via a bunch of call back functions. They are not completely fool proof.

A later version of the game might be ported to GLFW (OpenGL for windows). This might fix the above problem. Another is to put desktop specific code into the game so that it has a better idea of what the desktop is doing to it.

If you run the game in a floating 3:4 aspect window (ie: 800x600), there is no issue. This might have to be the work around for 4.0.

[brickviking]

I did think of another possible way around this. What's your coordinate system based around? Could you set the centre of the viewport, and have the size of the viewport inset from the left hand side of the window by half the remaining gap from the window to the edge of the viewport? The other thing is, the problem also appears under Gnome Classic and Plasma. 9wm seems to be the only place it doesn't seem to panic, but then there's no way to maximize under 9wm. Tiling window managers I don't know enough about to say with certainty, as they seem to apply their own logic to how windows appear.

[jsno8192]

The virtual coordinate system (ie: what the game thinks it's running on) is a 320x200 screen with the 0,0 being the top left hand of the screen.

Yep, possible. You could translate everything to centre of screen in OpenGL. This centre pixel becomes 0,0.

The problem with mucking around with the existing 320x200 virtual coordinate system is the game has the above ingrained into it. The code is currently tuned for this. Changing this may add bugs. You have to be very careful.

[jsno8192]

I figured if we polish up 4.0 and get that out the door "as is" (pending a few very small bug fixes from the alpha testers), then a playable game is available to users (minus some things that they would like).

Then 4.1dev comes to life and we experiment with that: adding the wide angle aspect, adding those new droid types, enhanced ned etc. if 4.1dev develops hidden bugs due to new enhancements, that's ok, we have the stable 4.0 available to users who just want to play it.

How is your new fleet come along ?. Will it be ready for 4.0 ?. Or do you want to wait for the new droid types ?

[brickviking]

A couple of points to think about. If you implement the wide-angle by stretching the 320x200 from 4:3 to 16:9 and making it wider that way (giving you roughly 360x200), then you'll end up with non-square tiles. If you put in more pixels to get your 16:9 and retain square tiles then most of the gameplay will be affected as the levels were presumably tuned for a 4:3 display. I don't know a good solution for either scenario.

I must say though, having used the ned editor in fullscreen (well, mostly) is way better than the cropped-to-4:3 version. I know exactly what I did to get it to work, but the change also affects nighthawk itself. The first section changes the number of pixels—and hence tiles—on screen, the second gives me a larger palette of tiles to select tiles from, given that I've now got more room to display them.

diff -u nighthawk-4.0/src/defs.h~ nighthawk-4.0/src/defs.h
--- nighthawk-4.0/src/defs.h~   2020-10-20 16:00:59.999414571 +1300
+++ nighthawk-4.0/src/defs.h    2020-10-23 22:20:11.944266834 +1300
@@ -73,12 +73,12 @@
  */
 #define SCR_ASPECT_43  (4.0 / 3.0)  /*JN, 04SEP20*/
 #define SCR_ASPECT_43_TOLERANCE 0.01
-#define WINDOW_SIZE_X 800  /*For screen size discovery. JN, 05SEP20*/
-#define WINDOW_SIZE_Y 600
-#define SCREEN_SIZE_X  320
-#define SCREEN_SIZE_Y  200
+#define WINDOW_SIZE_X 1600  /*For screen size discovery. JN, 05SEP20*/
+#define WINDOW_SIZE_Y 900
+#define SCREEN_SIZE_X  640
+#define SCREEN_SIZE_Y  400
 #define SCREEN_HSIZE_X (SCREEN_SIZE_X >> 1)
 #define SCREEN_HSIZE_Y (SCREEN_SIZE_Y >> 1)
 #define SPRITE_SIZE_X  32
diff -u nighthawk-4.0/src/edit_floor.cc~ nighthawk-4.0/src/edit_floor.cc
--- nighthawk-4.0/src/edit_floor.cc~    2020-10-20 16:00:59.999414571 +1300
+++ nighthawk-4.0/src/edit_floor.cc 2020-10-23 22:34:13.568267594 +1300
@@ -195,8 +195,8 @@
        SPRITE_SIZE_X + 6,
        (4 * (SPRITE_SIZE_Y + 10)));

-   ssp_block = sprite_sel_ptr & ~0x3;
-   for (ipy = 0; ipy < 4; ipy++) {
+   ssp_block = sprite_sel_ptr & ~0x7;
+   for (ipy = 0; ipy < 8; ipy++) {
        if ((ipy + ssp_block) >= flr_bm_size)
            continue;

@@ -205,7 +205,7 @@
            SCREEN_SIZE_X - 34,
            (ipy * (SPRITE_SIZE_Y + 10)) + 10);

-       if ((sprite_sel_ptr & 0x3) == ipy)
+       if ((sprite_sel_ptr & 0x7) == ipy)
            glColor4f(1.0, 1.0, 1.0, alpha_pulse);
        else
            glColor3fv(black_pixel[0]);

I also found something out, though I suspected it all along. I'm actually pretty crap at this game, I haven't survived past the second ship yet, so I guess you'll be the one to know how best this matches up with a decent challenge.

[jsno8192]

Hmm, interesting. I've never tried this :)

When you did the above change (virtual screen size to 640x400), did this make the sprites smaller on the screen ?

[jsno8192]

To make the game wide screen, we could make the virtual screen 320x240. This will set the screen aspect to 16:9.

[brickviking]

I'll transfer this all over into a new issue, as it's not exactly relevant to this current issue.

[jsno8192]

ok

[jsno8192]

Regarding your last point about Seafarer, yes, this ship is challenging. You either have to clear the ship using a fast 606 with poor shielding, or a slow 810 or the 899 with good shields. This ship is a bit of a patience game, and requires a bit of luck too. If you really get stuck, I'll upload a movie of how I complete it.