Inactive Window + Mouse Move = Render
Monkey Forums/Monkey Programming/Inactive Window + Mouse Move = Render
| ||
| See Here For Slightly More Information (Maybe): http://www.monkey-x.com/Community/posts.php?topic=8609 I put some update code in OnRender for the red bullets. While the window is inactive and the mouse moves over it, the milliseconds counter keeps going up. This completely messes up all of my timing code which otherwise worked fine when I originally wrote it. |
| ||
| Confirmed here on my Win8.1 machine (only happens with GLFW): |
| ||
| It would be very nice to have an "inactive OnRender" to handle mouse resizing glitches. |
| ||
confirmed it's the "render to display pause screen" addition here in targets/modules/native/glfwgame.cpp
if( !_updateRate || _suspended ){
if( !_iconified ) RenderGame();
glfwWaitEvents();
continue;
}
a tri-state variable would work. |
| ||
| > I put some update code in OnRender for the red bullets. Update code goes in OnUpdate! OnRender may potentially be called at pretty much anytime, eg: window is inactive, but is covered/revealed by another window, or another app enters/leaves fullscreen etc. Ditto android/ios etc - OnRender may be called when gamecenter or some dialog is 'blocking' your app if the display needs refreshing. Millisecs returns 'real' millisecs, not app active millisecs or anything like that, so it'll always be ticking away - if you want 'app active' millisecs, you'll need to update a 'virtual millisecs' inside OnUpdate, or subtract a snapshot of millisecs at OnResume from Millisecs() or use some other scheme. In the case of glfw, calling OnRender when mouse moves could be considered excessive/inefficient and I'll have a look at it eventually, but it's not strictly speaking a bug. |
| ||
| Millisecs returns 'real' millisecs, not app active millisecs or anything like that Since when? For as long as I've used Monkey that's exactly what Millisecs has returned, is the number of seconds the program has been running while active. If that wasn't how it was supposed to be, then several of your targets are buggy with regards to Millisecs. |
| ||
| > If that wasn't how it was supposed to be, then several of your targets are buggy with regards to Millisecs. Which ones? Millisecs has always been a relatively low level, 'realtime' function. |
| ||
| http://www.monkey-x.com/docs/html/Modules_mojo.app.html#Millisecs Function Millisecs : Int () Returns the number milliseconds (thousandths of a second) the application has been running. Divide this by 1000.0 to get the number of seconds the applications has been running. |
| ||
| Just for the record (Not sure if this is Windows, or my drivers) that demo therevills posted renders at 2FPS for me when it's suspended. Also, the 'Millisecs' command is just offset based on when you started the application. Basically, it's just: MS = (Uptime - Starttime). The 'Millisecs' command has nothing to do with OnUpdate, OnRender, or anything like that. The only thing the 'App' class has to do with it is the offset when starting (To my knowledge). Just for the sake of target safety, I don't rely on 'Millisecs' for anything but timers. And as I stated on the other thread, no updating should be done in 'OnRender'. |
| ||
| Also, since we're on the topic of 'OnRender'.. Though I'm sure this isn't actually Monkey's fault; for the longest time, if you close something like Fraps, any Monkey game built with GLFW will crash. That's a bit odd if you ask me, but it might just be an old Fraps bug. |
| ||
| Which ones? At least the PlayStation Vita target (only can confirm this one at the moment, very busy with moving). If you click out to the menu, the application timer does not keep rising. Just like I would think the GLFW would not. Also what therevills quoted in the docs say what I wrote and thought. "application has been running" does not sound like "including when application is inactive." Plus, why do the milliseconds keep rising if the game is inactive? Does that make sense to you? What reason do they need to keep going up? It just seems like extra unnecessary work for us that should have been handled. Luckily my timer code is very robust and can deal with this problem easily, but I can't imagine it's that easy for most others. Edit: I said I could confirm the PS Vita, but the last time I confirmed it was sometime mid last year. So technically I would think it's still the same. And as I stated on the other thread, no updating should be done in 'OnRender'. As I told you in the other thread, it was for the purpose of visually seeing this problem. You couldn't see it if I didn't move the code over. Geez. |
| ||
| Goodlookinguy: "As I told you in the other thread, it was for the purpose of visually seeing this problem. You couldn't see it if I didn't move the code over. Geez." You're acting as if that wasn't still a mistake. You're also acting as if I wasn't reinforcing that ideal to ensure that others within this thread were on the same page. At this point, this whole thing doesn't even sound like a bug; but it does sound like an inconsistency between some targets. You should expect 'OnRender' to be called at any time, and not rely on it for any unrelated updating. And as a response to what you said about 'Millisecs', it's not supposed to be based on 'OnUpdate' to begin with. It's simply stating how much time has passed since the program started, nothing more. If your timer code (Assuming it's setup like: "Millisecs()-Timer >= Timeout") should used under the impression that this waits X milliseconds of time, not some arbitrary number based on the activity of the application and/or what the system has done to update your application. If the PS Vita target works like that, then that target is the one falling out of line. Unless of course Mark thinks having an inaccurate 'Millisecs' command is a good idea. If that's the case, I'd not only be disappointed, but that could also break some people's code (Possibly even my own). Most notably, that kind of functionality could completely break some people's delta-timing code. And if the PS Vita target causes this, then I might not even consider it for future projects (Or I'd hack my own command in). |
| ||
| You're acting as if that wasn't still a mistake. It wasn't a mistake on my part. It was on purpose because of something weird I saw I decided to move the logic to attempt to see if what was happening could be visualized. My god you're think headed. You're also acting as if I wasn't reinforcing that ideal to ensure that others within this thread were on the same page. Reinforcement to others is fine, but you sure didn't come across that way. Your statement brought up the other thread in which you implied that I make a mistake, which I didn't. Hence the context involved me selectively unless the context was otherwise broadened. At this point, this whole thing doesn't even sound like a bug; but it does sound like an inconsistency between some targets. Yes it is, but in the world of Monkey this is a bug seeing as how the purpose is a make once deploy all. As for your statements about my timer code, it's far more advanced than the simple stuff seen on the forums. I also have a variety of timers. Point is, they can shift time quite easily which means I just have to capture the time at OnSuspend and then shift the difference at OnResume. Not a problem for me, but for others this could sure be annoying. (Or I'd hack my own command in). Doubt it. If you don't own a Vita you might not understand what it does when you go back to the main menu and then back to the game. It seems to actually have a separate timer built in that runs on its own accord. I haven't worked with the PSM target in a while, but it had some weird stuff going on. |
   |