added System.mainLoop() #55
Conversation
|
aptMainLoop is already used in the Interpreter main loop: https://github.com/Rinnegatamante/lpp-3ds/blob/master/source/main.cpp#L142 . I suppose 3DS is not expecting this to be called twice. Have you already tried replacing it with a for (;;) loop? |
|
@Rinnegatamante aptMainLoop only performs a series of checks and reacts to them if necessary (whether the console wants to enter sleep mode, whether the power button or home button have been pressed, whether the application has been ordered to close by the HOME Menu); therefore, it can be run as many times as you wish, though obviously calling it more than once every X is redundant. |
|
Yep, that's why i'm suggesting to replace the loop in main.cpp with a standard for (;;) and performing some tests. Don't have a 3DS till 20th of April so can't test personally if the solution works as intended. |
|
@Rinnegatamante On first glance, that will work fine as aptMainLoop() is not called anyway during interpreter execution, though you might want to call it manually in the "while (restore==0){" loop where it doesn't seem to be called? Doing this and adding a System.mainLoop() function should work fine. |
|
@asiekierka You're right, while restore==0 needs an extra flag to check for main loop but it's not that important for hbs support to sleep mode. the restore part is meant to be executed only when an interpreter error gets on the lua stack (so a critical error in the code or a error() call in the script). |
|
@Rinnegatamante True, but: (a) I feel supporting sleep mode in every possible part of the application is a good idea, because after all it's a handheld, |
|
On an unreleted note: This would require extra tests, probably the best solution is to look into multithread applications that already 100% support sleeping mode (FBI (?)). |
|
@Rinnegatamante It did cause strange behaviours for me when I tried to move rendering into a separate thread on the application core in my own homebrew, yes. I haven't looked into them further yet, however. Sadly, I'm not able to look into this for LPP-3DS - I already have enough homebrew (mostly ports for the time being) on my own plate. |
|
If rendering code was using GPU (citro3D or similars), it could be related to not properly resetting GPU state. (At least sf2dlib performed such checks by itself iirc, dunno for citro3d). About audio code, resuming EasyRPG caused audio file handles to become invalid (like if any opened file handle is automatically closed when a sleep is invoked). Since audio code uses a file handle similarly to EasyRPG, probably a solution is to keep track of when a sleep is invoked, keep track of filepath of currently streamed files, add a state on audio threads so that they enter in a infinite loop till a resume is called, when the resume is called, reopen the file handles and properly reset old state for the streams (so libogg pointer, wav pointer, etc...). |
|
I admittedly hadn't considered multithreading when creating |
|
doesFileExist won't be changed in syntax due to retrocompatibility with original Lua Player, Lua Player HM, lpp-vita, lpp-c++, lpp-plugin. |
|
Sorry about that; still getting acquainted to GitHub, didn't think future commits would be added to the Pull Request. I'll revert the syntax when I get the time and add the |
|
You should commit to a different branch everytime you push something to not automatically push it into the pull request too. |
|
There. Thanks for the suggestion; I'll be developing these things in branches from now on. |
This adds
System.mainLoop()to the System module, thereby adding support for sleep mode in LPP-3DS.