This small game has an interesting problem: when run with default settings (windowed, 800x600 size at 50,50 position) the blitted image is reduced of the same value of the placement, (50,50 in the attached picture).
If you drag the window on the screen, the blitted area changes according to the current position.
This means that the game is somehow aware of its position, something that DxWnd should accurately hide!
What makes this fact really interesting is that some Quicktime games show similar problems, and I never got to understand where the position data comes from and how to fix the problem.
The game is not too complex, so my hope is that being small it could be easier to find where the hiding of the position fails.
The game is on internet archive: https://archive.org/details/libarmy
Thank you, your profile is clarifying the situation. The shift disappears thank to the NOWINPOSCHANGES flag that suppresses the WM_WINPOSCHANGING/CHANGED Windows messages. So, evidently the game intercepts this message to know where the window is positioned. Now I should try to apply the same trick to some other situation and see if it works. In case, maybe it could also be possible to apply the trick automatically when the game is set in fullscreen mode and the window handle corresponds to the main window ...
I also understood a little better how the game works, and it seems interesting. On my keyboard the commands seem mapped to the keys 'S' and "D' (possibly others?) plus the arrow keys. Selecting "PHASE SHIFT" and pressing 'S' you enter the battle mode with your troops. Then, if you arranged your troops wisely, you can win (or lose) some territory.
This small game has an interesting problem: when run with default settings (windowed, 800x600 size at 50,50 position) the blitted image is reduced of the same value of the placement, (50,50 in the attached picture).
If you drag the window on the screen, the blitted area changes according to the current position.
This means that the game is somehow aware of its position, something that DxWnd should accurately hide!
What makes this fact really interesting is that some Quicktime games show similar problems, and I never got to understand where the position data comes from and how to fix the problem.
The game is not too complex, so my hope is that being small it could be easier to find where the hiding of the position fails.
The game is on internet archive: https://archive.org/details/libarmy
Well, I don't know how the game finds its position, but try this ;-)
Thank you, your profile is clarifying the situation. The shift disappears thank to the NOWINPOSCHANGES flag that suppresses the WM_WINPOSCHANGING/CHANGED Windows messages. So, evidently the game intercepts this message to know where the window is positioned. Now I should try to apply the same trick to some other situation and see if it works. In case, maybe it could also be possible to apply the trick automatically when the game is set in fullscreen mode and the window handle corresponds to the main window ...
I also understood a little better how the game works, and it seems interesting. On my keyboard the commands seem mapped to the keys 'S' and "D' (possibly others?) plus the arrow keys. Selecting "PHASE SHIFT" and pressing 'S' you enter the battle mode with your troops. Then, if you arranged your troops wisely, you can win (or lose) some territory.