11/8/2023 0 Comments Dolphin emulator lagging![]() After troubleshooting about 19 different api methods for having my script read the mouse position and having all of them either report no info back, or trigger this odd DeSmuME-only issue, I think the next goal is to try the RetroArch DeSmuME core, but the whole point of using DeSmuME in the first place was due to the internal resolution increase function, and I don't know if that's available in the retroarch core yet (but even with the resolution increase disabled, the issue persists). I reckon this has something to do with how DeSmuME requests info on whether the mouse is hovering over the window, as this occurs even if the mouse is merely hovering over the titlebar of the window - it's not exclusive to hovering over the rendered game area. I have also tried no$gba and melonDS but the issue does not exist in them. I have tried two versions of the scripting tool, the issue exists regardless of which version I use. I have tried two versions of DeSmuME, the issue exists regardless of which version I use. I have 3 metroid prime carts and have dumped the roms from two of them, the issue exists regardless of which rom I use. ![]() Similarly, if I comment out the parts only relevant to writing a new mouse position OR the parts only relevant to reading the mouse position, the issue still persists. I thought perhaps it was just the scripting software in general, but if I comment out all lines related to the mouse position, the issue resolves. I assumed my script was just eating up way too much processing, but no matter how much I slow it down (even down to 0.2Hz) the issue persists at the exact moment that the mouse position is read or accessed. This seems to be particularly bad when I'm using DirectInput api calls to access the mouse, as even just rotating it in slow circles causes the emulator to immediately seize up, whereas when using things other than dinput seem to require a lot more rapid mouse movement to trigger stutters/slowdowns. I have re-run my script at a lower framerate (1Hz) and every time there's a mouse check, there's a tiny bit of lag in DeSmuME if the mouse is hovering over DeSmuME, regardless of if the window is in focus. ![]() I was trying out the new version of DeSmuME that lets you increase your internal render resolution for 3D scenes because and I thought, ah, perhaps this is just an issue with this unstable build, so I went back to the 6-year-old stable build (0.9.11) and lo and behold, it has the same issue. (Or at least that's what the console says.) This wouldn't be such a big deal, except it seems to do this every time the mouse is accessed, so if I turn on the script and start moving the mouse in rapid circles (so that it's moving significantly/rapidly on every frame) DeSmuME can lag SO MUCH that it gives up and emergency dumps the audio buffer, presumably because it's hanging too hard. While the script is checking the mouse position, or writing a new mouse position, DeSmuME seems to throw a tantrum that it isn't allowed to access the mouse at the same time as a different program, and will simply hang on whatever frame it's on and the audio currently in the buffer until the mouse is free. So, the TL DR: I'm using a GlovePIE script to check when the mouse is over the DeSmuME window for. Ok, so this is a spicy one for y'all devs, and as a beginner programmer who knows enough to know how wildly complex some of this stuff can be, I'll do my best to explain the issue I've noticed as well as the various troubleshooting I've done to eliminate potential problem sources. ![]() and while a secondary program is also reading/writing the mouse location. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |