obsproject
win-capture: Add WAKFU compatibility notice
Description
Add compatibility notice about recording WAKFU on Windows with game_capture since game_capture may lead to abnormal RAM usage in WAKFU instance
Motivation and Context
We (WAKFU development team) submit this PR to avoid crash of WAKFU due of capture mode selectionned, since we don't see on our side why this memory leak occurs :/
How Has This Been Tested?
We have reproduced the issue with latest OBS version and with local build with following revision : b46e5bb1c08fb385d19f024199557c792a4e6126
We have tested our compatibility notice with local build with following revision : c3ddff31fcb64bbb2dedf41d21228dbde2497652
Build has been performed with following version of cmake : 3.31.7, with following version of windows sdk : 10.0.22621.0, and with following version of msvc : 19.43.34809.0 on Windows 10 22H2 19045.5487
Types of changes
- Documentation (a change to documentation pages)
Checklist:
- [x] My code has been run through clang-format.
- [x] I have read the contributing document.
- [x] My code is not on the master branch.
- [x] The code has been tested.
- [x] All commit messages are properly formatted and commits squashed where appropriate.
- [x] I have included updates to all appropriate documentation.
Please only provide en-US language strings. Other languages are provided via translations on Crowdin, so any changes made directly here will be overwritten when we updated translations.
Sorry my bad :x, i didn't suppose new translation must be added only with en-US
While I appreciate the direct involvement here, I would prefer that we figure out the root cause here rather than paper over it with a compatibility warning. What exactly is "abnormal RAM usage"?
To explicit the issue, when you capture WAKFU with game_capture on Windows, the ram used by the jvm of the game increase over and over until Windows kill the game. At the moment we don't know more about the issue but i suppose the game_capture read buffers of WAKFU and doesn't free them and our jre (and/or our OpenGL library jogl) doesn't free the buffers since they are readed by another program, so this case lead to this memory leak.
For the moment i have check jogl code without success and despite i have already compile some JVM for testing i didn't do for this specific case at the moment (And since my main workstation is a linux is not the easier setup to test this windows issue :x)