[Bug] Moving mouse pointer to close to border leaves the game about max HOT 5 CLOSED

I should add that I just build the sources. So the problem is not pointed to the last releases but to the most current code base.

from max.

All versions behave like that for now. It is very annoying, I agree.

The new mouse handler implementation did not modernize the related architecture yet - user input is a very complex feature in the game engine (GNW). Instead of a conventional multi threaded SDL event loop, the game still uses its ancient old MS-DOS game loops from the original assembly. The mouse interface to the game still mimics MS-DOS DPMI service calls which expected the delta movement between two consecutive position queries. SDL2 has an interface that works like this, called SDL_GetRelativeMouseState, which is integrated into mouse.c here.

SDL2 has a configuration option to lock or grab the mouse into an SDL2 window via SDL_SetRelativeMouseMode(SDL_TRUE). This you can find here but now the function parameter is set to false to disable locking. On MS Windows the feature works perfectly. Mouse cursor always remains within the window, pressing the Windows button on the keyboard releases the mouse, etc. I test the Linux version using a virtual machine. If SDL_SetRelativeMouseMode is set to true on this Ubuntu 19.xx based virtual machine, the entire OS's mouse cursor becomes inoperative. As long as the M.A.X. executable lives, the OS mouse input is basically broken within the entire OS. I have no clue what causes this and I am not eager to fix the OS or the VM or SDL2 in this regard.

Instead of searching endlessly for quirky workarounds I leave the mouse unlocked so behavior is identical on Windows and Ubuntu. It is planned to replace the old MS-DOS game loop to an SDL event loop in which case relative mouse position based mouse integration could be replaced by absolute screen or desktop position based mouse integration in which case mouse lock or grab will not be necessary to keep game cursor and OS cursor in sync effortlessly. Even more it would become possible to replace the old software mouse cursor rendering with modern hardware rendered cursor.

But all these options to rewrite the architecture are very far away as first the original game loop needs to be reimplemented for which all the GUI handler C++ class hierarchies and hundreds of very complex functions need to be recreated first.

If you are on Windows, just change the SDL_SetRelativeMouseMode parameter to SDL_TRUE. If you are on Linux, you could change the game into full screen mode in which case the mouse cursor cannot leave the window. Just uncomment the respective code lines in svga.c to change to full screen mode. But beware that if SDL2 enters a deadlock or livelock it will be difficult to close the application... That is why full screen mode is not set as default... and actually I have a single screen so for debugging windowed mode is a must for me.

Hope this helps.

from max.

This helped indeed. I'm on Windows and I set SDL_SetRelativeMouseMode(SDL_TRUE).

I'll give the game a go and see what happens. If you wish I can report on some of my findings. I can, if you desire, provide very limited documentation on how to compile your code on Windows using MinGW.

from max.

Build instructions would be highly appreciated, I still did not write any even though that task was part of the v0.1.0 work package. The biggest reason I shift it all the time is that the Jekyll GitHub Pages template I use does not support drop down menus and I want to solve that first before I add any further pages to the Web page. By the way I just recently got rid of the last remnants of 16 bit code from the project so build settings will soon become a bit simpler I hope. The current master can only be built in 32 bit mode with i686 packages. x86_64 libraries will not do for now.

With respect to defects and crashes, they will happen a lot. Although it depends on how you play.

• Crashes will happen a lot especially if you run the game through GDB or a comparable debugger backend as the original MS-DOS GNW memory manager seems to interfere with the special memory allocator that debuggers use. This is just a hunch though, I have no clear evidence yet. I recently fixed some corrupted NULL pointer checks after freeing resources that were corrupted by exactly this strange nature of the debugger memory allocator, but not all.
• In certain cases you might observe broken unit stats during new game creation. This is a long standing memory corruption issue where I suspect SDL2 to be the culprit, but I could not prove it yet. That particular corruption disappears only after an OS restart which is frightening.
• Please note that there are many problems with keyboard input. Key modifiers like CTRL, SHIFT, ALT, etc could stuck. And arrow keys in general just stuck for whatever reason. Use mouse scrolling instead. Input handling will be completely redesigned as soon as SDL event loop is introduced replacing the old DOS game loops.

Save game files are still produced by original game code so you could switch between original M.A.X. and M.A.X. Port at any time by taking the save files with you. What I am most interested in is finding defects in the original M.A.X. and if such defects could be observed via a save game file and could be analyzed further would be the best. In various forums many players complain about defects I could never observe or reproduce. Maybe they did not use the latest official version... There are many segmentation fault related issues in the original M.A.X. which did not crash the game under MS-DOS, but crashes the game immediately on modern operating systems. If you find a button on the GUI or an action that causes this, it could also be interesting, even though without rewrite of the GUI manager classes I can not meaningfully fix those issues yet. A good example for this is defect 16.

from max.

The defect is corrected by d9bc866. Affected source file is mouse.c. The new behavior was tested on a Windows host. In windowed mode it is possible to leave the game window with the mouse by pressing the Windows key or ALT+TAB or similar.

from max.