Change Details

This was much easier than I thought :P. ---- This is a fix for a crash on Mac OS Catalina. D2019 reported issues with video setup in a separate thread, but it turns out it actually crashes, and D2019 is not enough to fix it (in fact I think it's partly the issue, by virtue that further graphics call must be on the initialiser thread). The simplest solution I find to fixing these issues, which actually date back to #500, is to not put Atlas and the game in separate threads. The reason for this architecture seems to be found [[ https://wildfiregames.com/forum/index.php?/topic/7444-u-turn-wxwidgets-scenario-editor/ | here ]] (staff forum thread). Basically, it was reasoned that it would help the editor not lag even if the game itself lagged. The implementation of messages and such in Atlas makes it rather easy to not actually do threading. With the need for threading removed, a (much?) simpler implementation is likely possible, but this is a working first step (cleanup pending). In my tests, I haven't noticed anything broken or obviously not working. ---- Pros of unthreading: - Code will be slightly easier to maintain and we might actually end up removing some magic form Atlas. - Less concern about the editor burning 100% of CPU if we reduce the frame rate. - Less concern about threading in other parts of the code because Atlas is no longer particularly special. - Any threading-UI error that might pop up in the future is preventively squashed. Cons of unthreading: - Does reduce performance of Atlas tools slightly (though I don't think we had many tools that didn't run in the engine thread anyways). - Might be a slightly worse experience if the game frame really lags. - To an extent, it puts the whole DLL architecture in question too. ---- Makes D2019 and D1922 irrelevant (and ergo fixes #5470) ---- User `wik` has a different fix at https://wildfiregames.com/forum/index.php?/topic/28183-trunk23664-cant-open-atlas-editor-on-osx-catalina-10154/&tab=comments#comment-396649, which involves patching wxWidgets.

This was much easier than I thought :P. ---- This is a fix for a crash on Mac OS Catalina. D2019 reported issues with video setup in a separate thread, but it turns out it actually crashes, and D2019 is not enough to fix it (in fact I think it's partly the issue, by virtue that further graphics call must be on the initialiser thread). The simplest solution I find to fixing these issues, which actually date back to #500, is to not put Atlas and the game in separate threads. The reason for this architecture seems to be found [[ https://wildfiregames.com/forum/index.php?/topic/7444-u-turn-wxwidgets-scenario-editor/ | here ]] (staff forum thread). Basically, it was reasoned that it would help the editor not lag even if the game itself lagged. The implementation of messages and such in Atlas makes it rather easy to not actually do threading. With the need for threading removed, a (much?) simpler implementation is likely possible, but this is a working first step (cleanup pending). In my tests, I haven't noticed anything broken or obviously not working. ---- Pros of unthreading: - Code will be slightly easier to maintain and we might actually end up removing some magic form Atlas. - Less concern about the editor burning 100% of CPU if we reduce the frame rate. - Less concern about threading in other parts of the code because Atlas is no longer particularly special. - Any threading-UI error that might pop up in the future is preventively squashed. Cons of unthreading: - Might be a slightly worse experience if the game frame really lags. - To an extent, it puts the whole DLL architecture in question too. ---- Makes D2019 and D1922 irrelevant (and ergo fixes #5470)

This was much easier than I thought :P. ---- This is a fix for a crash on Mac OS Catalina. D2019 reported issues with video setup in a separate thread, but it turns out it actually crashes, and D2019 is not enough to fix it (in fact I think it's partly the issue, by virtue that further graphics call must be on the initialiser thread). The simplest solution I find to fixing these issues, which actually date back to #500, is to not put Atlas and the game in separate threads. The reason for this architecture seems to be found [[ https://wildfiregames.com/forum/index.php?/topic/7444-u-turn-wxwidgets-scenario-editor/ | here ]] (staff forum thread). Basically, it was reasoned that it would help the editor not lag even if the game itself lagged. The implementation of messages and such in Atlas makes it rather easy to not actually do threading. With the need for threading removed, a (much?) simpler implementation is likely possible, but this is a working first step (cleanup pending). In my tests, I haven't noticed anything broken or obviously not working. ---- Pros of unthreading: - Code will be slightly easier to maintain and we might actually end up removing some magic form Atlas. - Less concern about the editor burning 100% of CPU if we reduce the frame rate. - Less concern about threading in other parts of the code because Atlas is no longer particularly special. - Any threading-UI error that might pop up in the future is preventively squashed. Cons of unthreading: - Does reduce performance of Atlas tools slightly (though I don't think we had many tools that didn't run in the engine thread anyways). - Might be a slightly worse experience if the game frame really lags. - To an extent, it puts the whole DLL architecture in question too. ---- Makes D2019 and D1922 irrelevant (and ergo fixes #5470) ---- User `wik` has a different fix at https://wildfiregames.com/forum/index.php?/topic/28183-trunk23664-cant-open-atlas-editor-on-osx-catalina-10154/&tab=comments#comment-396649, which involves patching wxWidgets.