[Bug] fade to black when pressing the files button to save about max

[klei1984]

Hello @goofyseeker311 ,

your main github.io page does not link to the actual download repo (this)

I will add a dedicated download menu item and related page to the homepage as soon as I attempt to make a "stable" release build. As of today master branch builds are still unstable unfortunately and phase out way too fast. I follow the home page design of Jagged Alliance 2 - Stracciatella. See here: https://ja2-stracciatella.github.io/download/ . Please note that there will be no nightly builds for M.A.X. Port until the first release is made. Nightly builds will be provided for regression testing purposes only.

also the build process does not install automatically (mingw32), and if you use the protected program files/max directory then the program cannot save settings or games

As of today M.A.X. Port is a patch that is supposed to be installed into the original M.A.X. game folder as suggested by the readme.md. Installing the patch into the steam, gog.com, egs, and similar M.A.X. game folders guarantees you write access.

• I agree with you that it is not fortunate that the NSIS installer uses the install prefix and package name as default path as that is useless.
• I agree with you that the configured install prefix is basically useless as the install path should point to the M.A.X. install folder.
• I agree with you that not using the NSIS installer generated by cpack on demand, instead calling makefile install target to copy stuff into the program files folder is useless as MS Windows does not work like that and this is why the NSIS installer is provided in the first place.

It is not planned to develop OS specific scripts to hunt down the existing installation locations of M.A.X. copies. I will extend the build instructions article, https://klei1984.github.io/max/build/ , on the home page to inform users that they are supposed to run cpack after build to generate the deb or NSIS installers and that users are supposed to install the patch into their previous M.A.X. installation locations.

arrow keys to pan the display and mouse wheel to zoom would be nice, simple ui enhancement.

M.A.X. Port simulates the original M.A.X. architecture. W.r.t. keyboard and mouse input this means that only MS-DOS DPMI server services are simulated currently. In case of mouse input this means 3 buttons and x,y position. In case of keyboard this means US standard keyboard layout which is simulated by SDL USB key and scan code 1:1 translation look up tables.

All this means that adding mouse wheel to UI controls and to the in-game tactical map is not a simple matter.

Arrow keys do work as per USB key and scan code rules. See evidence here: https://youtu.be/EwZb10FiTdc?t=37 . I agree with you that the game should be able to recognize multiple variants of USB scan and key codes representing arrow keys combined with modifiers like Num Lock. This is not the case unfortunately. There is a 1:1 mapping between DPMI server scan codes to USB ones. On my laptop I have to disable the num lock modifier to get working arrow keys.

Work package 7, https://klei1984.github.io/max/roadmap/ , is planned to add support for DPI aware Unicode true type fonts rendering, proper support for keyboard locales and customization of key bindings. Prerequisite for all of these is the complete refactoring of GNW library modules. Step by step work break down looks something like this:

• develop unicode true type fonts (outlines, bitmaps, vectors, minimum 3 em sizes, etc).
• develop new GNW font manager, compliant with the GNW Font Manager API, that supports true type fonts and UTF8/UCS32 conversions and rendering with various outline, underline, etc. effects.
• externalize all text and store them in utf8 encoded configuration files.
• replace GNW's MS-DOS human machine interface modules to support modern mouse and keyboard features and OS and language dependent locales.
• modify the game specific UI control classes to manage locale aware hot keys based on control expressions populated via language files and generic mouse inputs including of course the mouse wheel.
• modify the game specific UI control classes to fill text labels, boxes and edit boxes based on available space and DPI / em size constraints.
• rewrite all c++ game specific GUI modules to integrate with all the above feature changes.

Design alternative to all of these: replace GNW with imgui + sdl2 or imgui + glfw + openal.

I hope that the above summary of WP 7 and the planned release procedures answer all your concerns. If so, please feel free to close the defect report.

[goofyseeker311]

also the build process does not install automatically (mingw32), and if you use the protected program files/max directory then the program cannot save settings or games (write assert error). also arrow keys to pan the display and mouse wheel to zoom would be nice, simple ui enhancement.

[goofyseeker311]

yes great.

one/two more issues:

1. I had to manually copy all the dlls from the msys64 (msys32) to get the windows .exe running in the writable folder
2. when recording with OBS, the start menu image when clicked only changes to the cursor pixel, not full image, even if the image shows on the screen to be fully changed to the next image. the image is fully updates only when mouse is moved after clicking the image.
3. If making a source port, why not then do a 16:9 adaptation of the engine, at the same time, now its the usual 4:3 aspect ratio

[goofyseeker311]

and one more: at turn 32, when clicking the files button, to save, the screen faded to black, then was bugged, then came back in like several seconds. yes it has happened twice now, fade to black for several seconds, some error lines on the right bottom of the screen, then it shows the files/save menu properly.

also the movie animation in the files menu (brain bouncing) is super fast, too fast fps.

quitting the current game from the files button menu has the same slow black down error, and the main menu will black out too. restarting the game fixes the slow black transition, when loading the same game, and pressing the files button to save.

another major bug: if you group select/move awacs/fighter then only the fighter has its movement deducted and awacs gains infinite movement, even when moving alone, full 18/18 movement all the time. nice.

edit: the movement bug seems to be related/appear with the menu button fade to black bug. seems that the fade to black is related to saving many times, like 10+. if the fade to black bug is active, then when trying to go back to menu, it will fade to a demo fight, cant do anything.

(edit: is the engineer supposed to move at the cost of 3 when in water.)

[klei1984]

Too many issues, difficult to track them this way :)

1. The SDL2 DLLs and any other runnables are normally registered by msys2 on install so that they are found in the system path. At least on my computer where I have msys2 I never had problems with locating the DLLs. If you run the cpack command from the build folder it creates an NSIS installer for Window that also installs all dependencies (10 DLLs). I will try to figure out whether cmake itself could configure the gnu make install command to copy the same dependencies. I never use the install command on Windows, never tried.

2. This is a defect in the original game. It is documented as defect 146 on this page: https://klei1984.github.io/max/defects/ . The problem is that the game's internal draw back buffer is not double buffered... to fix this a more sophisticated architectural change would be required. This defect is not in focus for now.

3. 16:9 and any aspect ratio where width > height is already supported. Higher resolutions are also supported (except text rendering due to complexity which is planned to be handled in WP 7). This blog entry describes how to configure the game to run in 16:9 Full HD mode and there is a demonstration video as well: https://klei1984.github.io/max/2023/03/13/Full-hd-game-play.html .

The original tactical map or tile map renderer of M.A.X. was written in pure assembler and was using a heavily optimized integer logic algorithm that is insanely efficient, but has severe design constraints at the same time. E.g. maps can only take the shape of squares, rectangles are no go. Map tiles can only be 64x64 or 32x32 pixels and the tile buffer must build a metadata database in the right format to be able to reference the correct data and copy it to the right screen back buffer offsets. The algorithm basically can translate the tile map buffer to screen back buffer positions and at the very same step perform nearest neighbor rescaling of tiles.
I was able to rewrite the original assembler algorithm using pure ISO C, but that does not mean that I fully understand what it does... quite the opposite, I do not understand most of it and as long as I cannot figure it out completely it will not be possible to zoom out the tactical map to such levels where the tactical map is not fully occupying the available square space on the screen.
In M.A.X. 2 the renderer was improved that the tactical map can be rendered in such a way that it does not fully occupy the aforementioned square area... similarly to the way Supreme Commander renders the map in zoomed out state. This feature should be surely back ported from M.A.X. 2 at some point.
To be honest, best would be to ditch the software renderer and move to OpenGL 3.x or Vulkan.

4. I also experienced the extreme slowdowns. It does not only happen when you go to the save/load menu which fades out and in the screen. I am unable to consistently reproduce the issue. When the issue is present, call / function trace does not change. Profiler data from gpof did not help to figure out what is slowing down to a crawl either. At some point I was sure that the issue occurs within SDL2 itself. That would explain why I do not see any slowdown in use code via gnu profiler or call trace. At some point I even went and wrote two screen blitter implementations. You can switch between the two implementations in svga.c by setting SVGA_NO_TEXTURE_UPDATE to true or false. It is realized as a compilation time switch which cannot be toggled at run-time. If the issue is not related to SDL2 or the way I am using the SDL2 APIs, than it could happen that the video card driver clashes or enters into temporary soft lock... we will not know until the root cause is found. As of now, I am at a pickle... The first step is definitely a way to reliable trigger the error. But I did not find a reliable method so far.

5. There is another hard to reproduce issue which causes the simulated MS-DOS system timer to go haywire. This manifests e.g. in the super fast floating brain anomaly or the always immediately restarting main menu attract demo (the demo fight you referred to) regardless that you want to exit from it once and for all. The original game and its game engine did not support PC low power modes. The game creates a lot of so called software timers. E.g. a feature saves a time stamp and starts to poll for the time to see how much time has elapsed. The time stamp is taken from the system timer. In case the PC is put to sleep the timer will jump and the software timer based timings will all go haywire. In multiplayer this is instant guaranteed desyc. In other cases simply the AI will skip some turns forward as its time allowance for "thinking" elapses... I could not figure out so far what could cause the timer to skip and time stamp references not to update... finding a reliable way to reproduce the issue is again the first step which is still pending.

6. airplanes have a very simple go straight from X to Y movement. Positions of the unit sprites to render are based on x,y pixel coordinates instead of 64x64 tactical map grid cell coordinates. Group movement limits the group velocity. Velocity of a unit is related to the game tick periods not to the actual system timer elapsed time directly. I cannot fathom what could cause one unit in the group to count down speed points based on velocity while the other does nothing. There is a way actually to make infinite movement. It is documented on the defects page as defect 136. Maybe you observed this issue. Although... I was only able to induce this for the entire group of units, not just one alone. Maybe it has to do something with the frame ticker and the system timer even though I said that those should not be related.

Maybe 4,5 and 6 are all caused by the exact same root cause. But i Have no clue what could be this cause :/

[goofyseeker311]

2. but the screen (in OBS) updates only after moving a mouse? what? :)
3. well its not immediately obvious by only running the game that even if it runs in 4K, it will not automatically go to the best display game ui logic mode (I dont assume original 4:3 mode is the best for a modernized update fix even if having original experience would be valued, I assume the most modern adaptation is the automatic default best, no matter what, and 4:3 is optional non-default, think quake source port is best 16:9 not 4:3 on modern machines and operating systems).
4. you dont have to change any of the map code, just fetch the map sectors that need to be rendered, no matter what display
   mode, the maps/game logic can be left original, ie, just the ui is modernized.
5. insanely efficient might not be suitable for modern adaptation, no matter the seemingly had benefits from the code optimization from old days
6. saving multiple times during a game always produces the slow down for me, after some time, on win11. most bugs are reliably found by trying to actually continuously play the game as is (no settings modification like a new non-technical player). maybe the game code would have to be actually modernized/updated to fit all use cases, ie, depart from original code compatibility, ie, true update fix, whatever that would mean.

I think all problems that I found should be in one place, no matter if they are handled (by you/someone) internally as separate issues. win some lose some, huh :) well if github is the issue tracker, then a separate (github) curated issue list should be there, no matter what the user input is, like this.

[klei1984]

2. M.A.X. only renders anything to the screen when the screen contents actually change. Color animations based on palette color rotation logic runs at 2 to 10 FPS. If you move the mouse the small portion of the screen where the mouse went through is rendered, nothing else. So in general FPS is 0 when nothing moves on the screen and this 0 FPS is increased to minimum 2, maximum 60 FPS due to color animations.
3. I agree with you. On a 4:3 screen automatically go for 4:3. On a 16:9 automatically go for 16:9 and if user wants something different, they should be able to override the auto aspect radio setting which should be introduced. I will try to look into how to detect physical, DPI aware displays via SDL2.
4. True. The drawmap module could render to a dedicated surface instead of the main window surface and that surface could be blitted into the new GUI backend's tactical map texture or surface area. It is a complex architectural change and would add one more huge texture blit each frame, but the benefits could easily overweight the drawbacks. I will keep this design alternative in mind.
5. I fully agree. Those insane optimizations were useful back then, but they became 100% drawbacks now. The game needs a flexible generic render pipeline that fits well to concepts from OpenGL and Vulkan so that hardware accelerations and parallel execution could be harnessed to their full potential.
6. Thanks for the hints, I will try to stress test rapid saving via the menus, maybe I can locate the root cause. Yes I agree with you, the original M.A.X. MS-DOS game loop is not fit at all to modern OSes and end user behaviors (send OS to sleep just to wake it up 2 minutes later). But to be able to redesign the core game logic, the frame ticker, someone has to fully understand the code base that has any direct side effects on this feature set. I am learning the architecture step by step, but we are very far from being able to replace the old fashioned architecture with a modern event loop based alternative.

Now focus will remain on fixing reimplementation issues so that the game becomes par with the original M.A.X. single player mode at least for which player feedback like yours are helpful.

[klei1984]

Hello @goofyseeker311 , did you minimize the game window by chance? I found an issue related to WIN+D or similar commands that minimizes the game window. ALT+TAB does not count.

[goofyseeker311]

well I streamed that on twitch using OBS, so I did WIN-key (not ALT-TAB) defocus the window, so "yes", but it did not go minimized, just out of focus, and yes multi-monitor mode (secondary screen for the OBS/browser)

[klei1984]

Hmm... then I am not sure, but lets hope that the texture locking issue was the root cause for point 6. which is corrected in commit c21b38b.

[goofyseeker311]

i'll try it soon (having a downloadable release candidate windows build would be fine, assuming you have full steam m.a.x. install to copy in the same folder with the files)

[klei1984]

github actions creates a windows nsis installer for every build. if you download it, just point the installer to your max installation folder and done. It will overwrite max.ini and maxrun.exe and will copy all DLL dependencies to the same folder. E.g. latest build artifacts (windows nsis installer, linux deb file): https://github.com/klei1984/max/suites/11638844465/artifacts/604201521

[klei1984]

drats... this was not the root cause for the extreme slowdown. It happened again... I left on 3 computers to fight each other in a computer only game and changed focus to another window as you noted. 20 minutes later the game is in slow motion...

[goofyseeker311]

well, the whole (c21b38b) game crashed when starting a 4-cpu turn based fight, after a successful real-time 4-cpu run with no slow downs. and my fade to black issue appeared when I was gaming in no-turn-time limit turn based mode. wonder what that is.

after full game restart the turn based 4-cpu battle started just fine. but game hard crashed mid-fight after like 5mins. there is some kind of time based kill switch that activates.

[klei1984]

Unfortunately there is no built in crash reporter. If you bump into a recurring crash, please drag and drop attach your SAVE10.DTA file to a new comment. It helps a lot in root cause analysis.

There are two timers. The turn timer represents the time available for the player to take a turn. When the timer reaches 0, the player's turn ends. The end turn timer is the time that computer players have to take their turn. In simultaneous turns based games as soon as one player ends the turn the others have to finish within the end turn timer time.

[goofyseeker311]

I meant some other internal timer, btw, not game play logic timer, more like graphics/ui timer.
seems like the game cant keep at fully functional state, but wanders off doing something it shouldn't do.

edit; meh attachment does not support .dta, so its now a .zip. right after the latest crash.
SAVE10.dta.zip

[klei1984]

Hello @goofyseeker311 ,

game crashed when starting a 4-cpu turn based fight, after a successful real-time 4-cpu run with no slow downs.

This is fixed in the latest GitHub Actions build. The root causes are documented on the defects page as defect 162 and 163.

[goofyseeker311]

well the game does not seem to crash (version 031987f), or even slow down fade to black slowly, it only did that after I saved once, so saving might be the slow down trigger. I could not produce the slow down without saving. still when triggered the game does not even let you quit, it loops (fades to black) in the demo fight, after fading to black to get to save menu.

edit: ok, definitely its not about the saving action, just time based somehow trigger, no sure if its win-key trigger at all, either.

[klei1984]

For point 6 this is the root cause analysis result:

When the issue occurs, the GPU load increases from 10-15% to ~40%.
The CPU and other I/O usage does not change at all.

The fading algorithm that is active when the file menu is opened or closed calls SDL_SetPaletteColors() 256 times for the full palette and renders the screen at 60 FPS. The FPS limit is calculated from system time received from SDL_GetTicks().

On the file menu screen the GPU goes to throttling 99% load. The FLIC animation, our floating brain in the jar, is supposed to be rendered at 15 FPS according to the FLIC file parameters, but it is rendered at insane FPS instead even though the system time received from SDL_GetTicks() should limit the frame rate to 80 milliseconds between frames minimum or 12.5 FPS maximum.

The SDL_GetTicks() interface returns unsigned int (32 bits resolution). The timer starts ticking from 0 at the start of the game executable and normally would roll over after like 49 days. After the issue was identified, the ticker value got sampled at a value of 651'321'397 which is far away from the overflow limit. The particular value corresponds to 9-10 minutes.

The above two observations could indicate a timer issue. In a followup test session a performance timer was installed within the FLIC animation FPS limiter which measured 79.9 milliseconds between two entries into the block body of the FLIC animation handler. After the issue occurred, the performance timer measured 5-600 microseconds between two entries into the same block body which confirms the assumption that the timer is wrong. The tick timer sampled shortly after detection of the issue had a value that corresponds to < 1 minute. This indicates that the tick timer overflows and its value is truncated and compared against a reference value that is not affected by the truncation.

The game simulates the MS-DOS DPMI server's timer interrupt which runs on the system configurable hardware PIT timer. The DOS timer is configured to run at a frequency of 1.19318 MHz or at a rate of 105/88 microseconds. On Windows SDL uses a performance query timer which has better than kHz resolution. That timer resource is used by SDL_GetTicks() to provide a millisecond resolution "accurate" time source for applications. The game converts the SDL millisecond timer back to MS-DOS ticks and the simulated GNW Timer API function returns the result as a 32 bit unsigned value. Formula: sdl_ticks * 1000 * 105 / 88. This means that the 49 days that could be represented by the 32 bit unsigned SDL timer is boundary limited to 2^32 / (1000 * 105 / 88) = ~1 hour.

The GNW API functions timer_get_stamp32() and timer_elapsed_time_ms() are affected in typical use cases.

Example:

// call site with elapsed application time > 1 hour.

// time stamp overflows and the value is truncated.
uint32 time_stamp = timer_get_stamp32();
// truncated reference value is passed to GNW API
timer_elapsed_time_ms(time_stamp);

// implementation of timer_elapsed_time_ms()
unsigned int timer_elapsed_time_ms(unsigned int time_stamp) {
    unsigned int result;
    // truncated time_stamp input argument is converted to milliseconds
    unsigned int time_stamp_ms = TIMER_TICKS_TO_MS(time_stamp);
    // non truncated, proper time is fetched in milliseconds
    unsigned int time_ms = SDL_GetTicks();

    // time_ms is guaranteed to be bigger, waaay bigger than truncated time_stamp_ms.
    if (time_ms > time_stamp_ms) {
        result = time_ms - time_stamp_ms;
    } else {
        result = 0uL;
    }

    // result is a huge number after 1 hour of game play.
    return result;
}

Remaining open questions:

• So far it was assumed that the occurrence rate of this issue is much faster than 1 hour. If that is true, the above finding is not the root cause.
• How to fix the issue without breaking API compatibility which would need throughout regression testing of 136 call sites.

[goofyseeker311]

well it takes a lot of time to get the effect, like at least 10min to 30mins, ie, a long full game (turn based 100 turns etc or 4-cpu fight for 30mins or so), sometimes the 4-cpu fight is so fast that the effect does not activate, at all. some timer value is randomly initialized to a variable milliseconds value (not always ms from 1-1-1970 or so), so that the effect take place on different time every time, Y2K bug I guess, 32-bit timer value bug.

well the timer service should work properly, before even thinking of any testing, ie foundation first then something that is assumed to be working on a working system, otherwise the code would be "working" while being broken and foundation services are broken. meh it would be double broken and only working as result of glue.

[goofyseeker311]

hard crash with the new version (ea5ac85) after 10-15min game play, no fade to black slow down bug before crash. I think I ran a full successful to the end game before the game that it crashed on. so the timer is from the starting of the game program, not only timer from the beginning of a game.

so far no fade to black bugs, after several games, only the one hard crash mentioned above, once.

edit: the weird click image OBS capture skew of the game application window is still there.
also the game crashed in the main menu, assuming it was trying to go into the demo fight.
seems somewhat unstable still.

both crash types attached below.

SAVE10.dta.zip
SAVE10a.dta.zip

[klei1984]

so the timer is from the starting of the game program, not only timer from the beginning of a game.

Yes, very good observation. You are right, actually the SDL timer starts ticking from 0 on program start and not on game start. And this gives an explanation for the last open question. If you start the program, finish a game in 55 minutes, the next game will break after just 5 minutes. I will do further stress tests, but I am convinced that the fading issue is resolved. Thanks for the help finding and confirming it.

I ran two instances of the game for 90+ minutes. No slow downs. I consider that issue fixed.

edit: the weird click image OBS capture skew of the game application window is still there.

Can you explain this in more detail? Or make a picture or video. I never used OBS and do not really understand what is the problem.

both crash types attached below.

Unfortunately the crashes you observed are not reproducible. The game does not save the computer players' task manager state. This means that reloading a game effectively resets the minds of computer players. If the AI ran for many turns it builds a complicated thought process with several hundred tasks. This is lost after each reload. If the issue of a crash is related to a task list that is not rebuilt by the AI the next time, then the issue is not reproducible. On each startup the game initializes a pseudo random number generator with a seed value based on local time. This value is saved into the save game files, but the game does not load them. I do not know why the original authors designed it like this. Why do they save the value in the first place if they do not reload it later. The only use I found for the saved seed value is to trace back when the original authors made their last change to their scenario, training and campaign missions. In short, if we are lucky the reloaded AI will bump into the same issue as before and the game will semi-reliably crash. This is the best case as then the save game file helps a lot.

[goofyseeker311]

well seems like OBS captures some other draw buffer that you are showing on the screen, do you by accident draw to multiple draw buffers differently, OBS shows different image that is on the screen. this might be an SDL draw implementation thing. the point is that OBS application/screen capture shows something different than what is shown on the screen. double draw in different layers, maybe? find attached the image file, on the right side is the embedded partial capture of the obs capture window. find also attached the video recording of the main menu image, the image only updates up to the mouse cursor, and fully only after mouse is moved.

and having two hard crashes quite often is still very non-stable, unfortunately.

max-master-64e329b-obs-capture.mp4

[goofyseeker311]

one additional error/assert with the newest version (64e329b), as image attached. some task manager assert error (IsSafeSite).
edit: this was during a simultaneous mode 4-cpu fight.

[klei1984]

the video recording of the main menu image, the image only updates up to the mouse cursor, and fully only after mouse is moved.

Thanks for the hints. This seems to be an SDL2 multi monitor setup related behavior. I was able to reproduce it. So far the game was configured to run centered which may have assumed that it should be centered not on the primary monitor only... I do not know.

The latest build adds a max.ini option to select the monitor and the game window is created centered on that display. The game will also do auto aspect ratio matching to the selected display while another new option called disable_ar_correction is set to 0.

These first option eliminated the anomaly of partial re-rendering based on mouse vertical position on my setup, the second fulfills point 3. Hope this resolves the anomalies on your system too.

[klei1984]

Do you have the saved game file for the assertion error case? Maybe that is reproducible.

[goofyseeker311]

well I'm still playing the game, do you want the file that is currently there, I pressed "ignore"

[klei1984]

if multiple turns elapsed since then, than it would not be useful for analysis. I will try to set up a game on the same map.

[goofyseeker311]

yes now its turn 31, and it happened at like turn 5 (13 lol), very early

[goofyseeker311]

no the new version (00b2f15) did not fix the main menu image problem (main screen still works as normal, the obs capture of the same application window is bugged). be advised that I have 4K as main monitor and 1080p as the secondary monitor, where the OBS window is. the game default wide screen mode seems to work nice! :)

is the main menu meant to be 4:3 even in 16:9 aspect ratio? also is the main game play view port side bars meant to be so thick (gray bars in the view port). image attached from the game play.

[klei1984]

the obs capture of the same application window is bugged

Please paste in your [GRAPHICS_SETTINGS] max.ini section.

is the main menu meant to be 4:3

Yes. No wide screen assets are available. The in-game wide screen GUI elements are dynamically created by the game on the fly. The added value of doing the same for menus compared to required effort to program them is too small. The limited development time and resources are better spent elsewhere.

main game play view port side bars meant to be so thick (gray bars in the view port)

Tactical map dimensions mast be multiples of 64x64 pixels. Architectural design constraint of drawmap module at minimum zoom level. At maximum zoom level 112 tiles must fit on vertical axis. The gray bars are the reminder between rescaled GUI panels on left and right and the number of 64x64 tiles that fit inbetween. This is basically point 4 from previous discussions.

[goofyseeker311]

I have default settings. from wherever they came. did not touch them. as none should have to.
and the display is in 4K mode, no matter the max.ini graphics settings, tho. doesnt the sdl get
the desktop resolution automatically? seems so. maybe your logic does not use the detected
desktop resolution but the max.ini graphics settings. maybe the numbers needs to be same,
not different.

[GRAPHICS_SETTINGS]
display_index=0
screen_mode=2
disable_ar_correction=0
scale_quality=1
window_width=640
window_height=480
dialog_center_mode=0

about those map dimensions, you could always load more than you display, from the game engine,
then clip what is extra. also you could even minimize the interface, to maximize the tactical max display.
depending if you want to preserve the original look or modernize the interface, like supcom:fa forever has done.

[klei1984]

as none should have to.

There is no possibility to configure 11 new settings from in-game.

I have default settings.
You settings mean that the game:

• creates a borderless window covering your entire primary monitor display using the original display resolution, pixel format and refresh rate.
• the logical screen rendering size is 640x480 pixels only, overridden to 853x480 by disable_ar_correction=0. That 853x480 pixel surface is rescaled to your primary display resolution by SDL2's preferred renderer engine. The renderer engine is auto selected by SDL2.

Options you could try to change and check whether OBS behavior differs:

• change display_index to your other display. E.g. if you have 3 displays, they will have indices: 0,1,2.
• change screen_mode to 1. That creates a fullscreen application instead of a borderless one. The display on which the window is created is exclusive to the game.
• scale quality: it may or may not have any connection. Try out all 3 options, maybe OBS likes one of them: 0,1,2.

General recommendation for screen_mode=2: In this mode your screen remains 4K. The window_width and window_height defines the logical or virtual resolution of the game. Now the game is rendered on 853x480 resolution and you see just a small part of the tactical map at maximum zoom level (closest). Change the logical resolution to 1920x1080. You will see much more of the map.

Recommendation for screen_mode=1: This mode changes your display's resolution and pixel format. Still it worth to try it out as this might make OBS work with SDL2 as expected.

[klei1984]

about those map dimensions, you could always load more than you display, from the game engine, then clip what is extra.

See point 4.

[goofyseeker311]

um most games work just fine with borderless, so I prefer that to exclusive full screen. in any case. OBS works fine with borderless, so its not an OBS thing, but its the SDL implementation thing. in this case. I recommend automatic default best settings. I'm not into linux style of manual settings. I recommend works-for-all default settings. also primary first screen should be the default screen.

oh my god, mode 0 in 4K forced width/height is working, but fonts are very small :) and there is a slow fade to black transition in loading/main/menu (very much slowed then in the default 640x480 width/height mode). the same OBS main menu image shenanigans happens for me in mode=0 4K forced.

4K loading splash screen is super slow lighting up (opposite of fade to black). there is an extra super slow face to black right after starting a new game/fight.

[klei1984]

You can read about the slowness in #24.

Hmm... mode 0 is normal Windowed mode. I will try to check whether windowed mode uses a different SDL2 renderer engine than the others.

If you have a discord user we can also continue there klei1984#2663 .

[goofyseeker311]

this is mostly fine :) for now, and I'm throwing anything/trying what sticks, so far I have tried mode 0, ar=1, in 4K, going to mode 1, same thing. alt-tabbing (win-key) makes cursor flash outside game and not let go of the app focus, to even use a browser/obs, cant even change focus to a box to write this reply, have to turn of the mode=1 m.a.x. I suspect forced focus to the game window logic, not only exclusive gpu mode full screen. mode=1 will not work for me in current state, must be able to alt-tab/win-key perfectly. and the reloading of the game when alt-tabbing/selecting/clicking back to game is very slow, 10 seconds or a bit less. mode=2, 4K, AR=1, same OBS issue in the main menu image mouse thingy.

dialog_center=1 and scale_quality=1/2/3 did not do anything for OBS shenanigans, I think SDL renders to a second output buffer that is not screen but application, which OBS records, not screen/window directly.

also if you quit a game before it finishes, through the quit button/exit, then it will not save the last used settings, to begin a new game, like turn-based vs simultaneous mode toggle.

[klei1984]

In mode 0 the display mode is not changed. Alt+tab and similar are fast. The mouse pointer is grabbed by the game window as soon as it is the active or top most window or the mouse hovers over any small part of it. If the window size is proportional to the full display or desktop the mouse is semi guaranteed to be locked in most use case. If mouse grab is disabled in windowed mode the in-game mouse pointer gets desynchronized to the physical mouse position due to relative mouse mode which is required for the game engine for now. This mouse pointer desynch is very annoying according to various user feedback.

In mode 1 the game changes OS display modes at every alt tab or similar loss of focus. SDL2 seems to handle this very slow.

In mode 2 there is no display mode switch and mouse grab seems to work a bit differently, relaxed. SDL2 mouse handling mode is not different though.

what happens if you set display_index=1 ?

On my Windows PC SDL2 supports 6 render drivers: Direct3D, Direct3D11, Direct3D12, OpenGL, OpenGL-ES2, GLES Software. The "best" selected by SDL2 automatically is Direct3D. Interesting...

Maybe OBS would work better with other renderers... problem is that there is no way to tell which renderers are available on a computer and configuring by index will give back different results on different computers. A sophisticated implementation may try to compare renderer names with ini settings but that is implementation defined and SDL can change the names or supported drivers at any time :(

[goofyseeker311]

doesnt SDL provide the API interfaces to switch whatever, and the window grabs the mouse even if its not selected/clicked, thats why the mouse flashes, in mode 1. OBS works will all renderers. It's more about SDL rendering/general settings or usage for each renderer. yes windowed mode=0 alt-tabbing is fast, with the grab. I'm certain that you can fix the SDL mode=1 alt-tabbing and other slow-downs, with some settings/usage, SDL definitely was not designed to work slowly on those operations.

display_index=1 just swaps the screens, OBS fails to work correctly in the same way as the other way around.

[klei1984]

and the window grabs the mouse even if its not selected/clicked

It is enough if the window becomes topmost or when the mouse pointer hovers over the game window (click, select not needed).

display_index=1

Ah, of course... I did not think that through.

SDL definitely was not designed to work slowly on those operations

The game itself does not handle any window related events. What we observe is 100% SDL2.

I will try to install this OBS thingy and try to reproduce the issue.

[goofyseeker311]

well in multimonitor setup, the mode=1 seems to be topmost all the time, no matter if you try to click to other screen windows, results in the window being grabby all the time, and mouse cursor flashing like there is no tomorrow, there might be something to be done with the SDL related code to get it working (configured properly).

I would recommend to remove the topmost mouse grab and only when you specifically click the window it will grab. now its unusable because of the auto-grab in mode=1, it should work exactly the same way as in mode=0 and mode=2, instead.

It's about the 4K, because in 640x480 internal mode in mode=1 the window alt-tabbing is fast. yes 4K is broken for mode=1. not even mouse flashing in the 640x480 mode=1. oops spoke too soon, after some time alt-tabbing out of mode=1 in 640x480 it will go into grabby flash mode, you cant even end task in windows task manager. mode=1 is unusable, totally.

mode=2, in 4K width/height mode it is, from now on.

[klei1984]

It could be done for sure. DOSBox uses SDL2 as well.

[goofyseeker311]

added you in discord for later use.

[klei1984]

The fade to black issue with system timer is resolved on latest master.

[goofyseeker311]

sorry to see you to be work pride ridden. here is some more defects to solve.

SAVE10c-dta.zip

[goofyseeker311]

https://hex-rays.com/ida-free/ or any similar ASM86-to-ANSIC converter, if you dont mind

[goofyseeker311]

well another crash midgame with 4-cpu. attached is the save file. hope it helps (version a54f058).

SAVE10d.dta.zip

[goofyseeker311]

hope things are going well.

anyways, tried the latest version (e91c4a6) with default 4K graphics settings, it will crash-flat if you win-key/alt-tab during the slowed down loading start screen.

edit: btw, there is some secondary settings.ini file that seems to be primary settings file, not the max.ini file, tried to alter that after first start, but nothing happened, settings.ini file changes did work tho.

edit2: some 4-cpu crash during first run fight, attached save file. the crash seems to be occurring very often repeatably. closes the whole app window, no assert.
SAVE10-e91c4a6.dta.zip

edit3: after 3 runs, have not been able to run a full game, it has always crashed to desktop directly. additional save file attached from the latest crash.
SAVE10-e91c4a6-2.dta.zip

[segatrade]

anyways, tried the latest version (e91c4a6) with default 4K graphics settings, it will crash-flat if you win-key/alt-tab during the slowed down loading start screen.

4k issue: #24

[goofyseeker311]

generally 4K refresh rate is slow, for no apparent reason. in normal game too.
current version (bc72fe2) crashes similarly to the previously mentioned version (after some short time in 4-cpu skirmish scenario). some successful full game runs were made in the previous version, after a ton of failed crashes. attached is an example of the current version straight crash to desktop.

SAVE10-bc72fe2.dta.zip

I would recommend to detach any game logic from the gpu drawing, ie keep what you have on the gpu, and only update from cpu game processing side whenever actually needed, like texture sprites, location, viewpoint, dont try to upload graphics definition fully each frame.

[goofyseeker311]

still crashing very frequently 4-cpu versus fight (version 02256d1). attached is the save file.

SAVE10-02256d1.dta.zip

[goofyseeker311]

newest version still crashing very often in same way straight to desktop (45e1154). attached the log data save file.

SAVE10-45e1154.dta.zip

[goofyseeker311]

here is a similar crash in the latest version (638f21c)

SAVE10-638f21c.dta.zip

[goofyseeker311]

0.4.1 seems stable so far, but one issue, when the window is not selected/foreground, ie alt-tab/win-key out, then it will slow to a very low fps, even if not wanted, 1st game finish no crash btw, so far so good.

anyways, the default settings should be full-screen window at desktop resolution (mode 2), now its 640x480 or some other low resolution.

[goofyseeker311]

in v0.4.1 this error message appeared, after several full fights, and after pressing ignore a couple times everything ai stopped.

[goofyseeker311]

well, 4K does not launch at all now. just a black screen. default screen resolution seems to work fine, at least to start with.

instant crash when entering a game with 4-cpu. first game start trial. yep 3 times in a row. shows units and starting location, freezes. halts. crashes. did not output a new timestamp save10.dta or even a save10.bak.

[goofyseeker311]

newest version, 1080p, after first full complete 4-cpu game, pressing files during first turn, turn does not end, pressing quit, starting a new 4-cpu game, results in this error, pressing ignore results in hard crash. 4K game does not start at all, black window.

[goofyseeker311]

turn lock at turn 8, 4-cpu skirmish, default install settings. older c1bef0e version.

edit: zoom in&out -/+ in numpad is nice addition.

SAVE10-c1bef0e.zip

[goofyseeker311]

same turn end lockup, latest version 1ae878f, default install settings.

SAVE10-1ae878f.DTA.zip

[goofyseeker311]

version 17dac93: turn time lockup (did not generate save10.dta on crash or exit).

[goofyseeker311]

still the same turn time at 00:00 lockup issue.

SAVE10-d0fc104.dta.zip

[goofyseeker311]

nope, still 00:00 turn jam (and some random crash to desktop, dont know why).

SAVE10-eda329e.dta.zip

[goofyseeker311]

still 00:00 turn jam. I think the save10.dta log stops also when the jam happens.

SAVE10-e775450.dta.zip

[goofyseeker311]

nope:
SAVE10-5fca1e9.dta.zip

[goofyseeker311]

SAVE10-1f6fd36.dta.zip

[goofyseeker311]

seems not to crash/jam in the 00:00 turn timer anymore. but seems like if you sit in a game completion score screen for long time, and then press the ok button. it will crash out of the game directly. the game save10.dta file might will not contain the crash reason, it only recorded up to the end of the game to the score screen and stopped there.

SAVE10-28d547b.dta.zip

[goofyseeker311]

surveyors on auto will get stuck in map pouches.

[goofyseeker311]

failed compile tho.

[goofyseeker311]

sometimes new game crashes, idk if it has something to do with timings/waiting on the score screen desync or something.

SAVE10-b9b45b6.dta.zip

yes repeatable, if you sit in the score screen enough, then start a 4-cpu skirmish random, it will crash to desktop right before the match would begin. crashes before it even starts logging into the save10.dta file.

[goofyseeker311]

ok caught the after score in game crash (the after full complete game crash after delay is very consistent, replicable):
SAVE10-b9b45b6-2.dta.zip

[goofyseeker311]

well it still crashes right after a new game after a successfully ended game, sometimes.

idk if this captured any of the crash reasons:
SAVE10-f1c9322.dta.zip

[goofyseeker311]

this kind of crash to desktop: SAVE10-458661c.dta.zip

[goofyseeker311]

this kind of crash to desktop after 2-3 successful skirmish game runs.
SAVE10-8f2ba6a.dta.zip

[goofyseeker311]

this time it took many games like 10 to crash, and it crashed right after pressing the start game button (the one after all the game settings, 4-cpu mode).

SAVE10-96af8c4.DTA.zip

[goofyseeker311]

this kind of long game error:
SAVE10-96af8c4.zip

[goofyseeker311]

at turn 333, the small power plant image keeps popping up in its place, no matter if the turn ends, like its being constructed all the time.

[goofyseeker311]

this kind of crash to desktop after a long game, about turn 350, 4-cpu:
SAVE10-96af8c4-2.DTA.zip

[goofyseeker311]

this kind of direct game start crash to desktop, a second after a few seconds of a start, same crash the third try:
SAVE10-86ef552.DTA.zip
SAVE10-86ef552-2.DTA.zip

[goofyseeker311]

direct crash at the beginning of a game.
SAVE10-54099ac.DTA.zip

[goofyseeker311]

now it will not crash right at the start, but the usual 00:00 turn time jam is still there.
SAVE10-7306e62.DTA.zip