Jitterbug Blues (or debugging's smoother than not)
Blitz3D Forums/Blitz3D Programming/Jitterbug Blues (or debugging's smoother than not)
| ||
| My program runs fine with debug enabled. When I disable debugging, it tends to have jitters quite frequently. What causes this and how can I fix it? |
| ||
| make sure your syncing works properly. You shouldn't run your game at "full speed" cause background tasks of the OS will make it jitter. Depending on the priority level of a process your game will be paused. If your game lets the OS breath frequenty then you got a better chance for a smooth framerate. Try both: Flip 1 or vwait: flip 0 You may have to implement a function that searches for the best synching method on every machine. |
| ||
| I only use a fraction of the available processing time. I think my loop takes 5 ms per frame or thereabouts. I use vwait : flip 0. I thought flip 1 was the same but a bit iffy and unreliable? What difference would it make? Okay, I just tried switching Flip method and it didn't seem to make any difference. I get the problem in the menu screen which is doing no work at all. Every second or two there's a stutter of a quarter of a second - very noticeable and sometimes causing user input to be dropped with mouse clicks not responding. I ran the main program and the animation is flawlessly smooth, and then suddenly stutters at low frame rate for half a second or so. It feels really crap and is very disappointing. It's been working perfectly while debugging :( If it's an OS thing, how can I release more resources? Will things be better if I create an executable rather than run the compiler? And why would the program run without problem in debug mode when more's going on, than without debug where I'm surely asking less of the system? I'd have thought the moment you lose the debug it'd be running smoother! ?? :( It also seems to only be a problem in full-screen mode. Windowed it runs as smoothly as it should. |
| ||
| I've tried a few Blitz demos. they seemed fine, except the castle demo that I used for it's frame tweening method which I use. That had some jitters, though not as bad as my mouse freezes. Has no-one else had this? Programs running fine in debug mode, then jittering the moment you switch debugging off ?? Edit : Here's an example of the code that freezes for quarter (editied out useful bits but this code still jitters for me) of a second at a time. While program_state=STATE_LEVEL_INTRO mouseupdate() mx = mouse\X my = mouse\Y CaptureWorld() : TG_Draw_UI VWait Flip False Wend Function TG_Draw_UI() TG_Position_Sprite(TG_pointer\sprite,mouse\x,mouse\y) RenderWorld tween End Function Function TG_Position_Sprite(sprite , x#, y#, z#=0) PositionEntity sprite, ( x - HGW ) * GUIsx , ( HGH - y ) * GUIsy, z# End Function Function MouseUpdate() Local b.mousebutton For b=Each mousebutton b\released=0 b\hitdouble=0 b\hit=MouseHit(b\index)>0 b\down=MouseDown(b\index) If b\down If b\hittime=0 b\hittime=MilliSecs() EndIf EndIf If b\hitcheck=0 b\hitcheck=b\hit EndIf If b\hitcheck=1 And b\down=0 Then b\released=1 b\hitcheck=0 b\downtime=0 b\hittime=0 EndIf If b\hit=1 Then b\startx=mouse\x b\starty=mouse\y If MilliSecs()-b\releasedtime<mouse\hitdoublespeed Then b\hitdouble=1 EndIf b\releasedtime=MilliSecs() EndIf If b\down b\downtime=MilliSecs()-b\hittime EndIf Next mouse\speedz=MouseZSpeed() mouse\speedx=MouseXSpeed() mouse\speedy=MouseYSpeed() If mouse\controlled Then mouse\x=mouse\x+mouse\speedx mouse\y=mouse\y+mouse\speedy MoveMouse GraphicsWidth()/2,GraphicsHeight()/2 ;done after movemouse to fix mouse problems on some computers MouseXSpeed() MouseYSpeed() If mouse\x<0 Then mouse\x=0 ElseIf mouse\x>GraphicsWidth()-1 mouse\x=GraphicsWidth()-1 EndIf If mouse\y<0 Then mouse\y=0 ElseIf mouse\y>GraphicsHeight()-1 mouse\y=GraphicsHeight()-1 EndIf Else If mouse\holding_object=0 mouse\x=MouseX() mouse\y=MouseY() EndIf EndIf End Function That's it. The screen is rendering a dozen boxes with no textures, and a few sprites with alpha blending for the interface. I get the postion of the mouse, postion a sprite there, capture the scene and render. I get loads of jitters. If I lose the tween it still jitters. If I lose the function calls, lose the captureworld(), and insert the code directly, I get jitters. If I lose the vwait and try Flip 0 and 1, the jitters are much less pronounced but still there. There's no background music or anything. Basically doing nothing more than looping through moving a mouse pointer gives me jitters where in debug it doesn't. |
| ||
| try adding a delay line after rendering? Might be choking your cpu :) |
| ||
| Yeah, I tried that too. It freed up CPU usage on the Windows' Process Monitor but the glitching was still there. Could people try this test case... http://www.davidcoombes.f2s.com/refresh_test.zip ...and just moce the mouse in small circles. It exhibits the same problem I'm experiencing in my program. Windowed it's smooth. Full screen without debug it's jittery. It's very jittery to start with, then the jitters calm down after a few seconds but still appear throughout running. It's more the mouse stopping thats the problem. In this test code the background only seems to jitter on start which I put down to initialisation. I do have periods of slight roughness in my 3D graphics of the main program though. And this test program isn't as noticeable in the problems as mine. The only real difference is a few more small alpha blended button sprites and a load of file accessing before hand to load the UI and level. Argh, it's driving me nuts! The thing is finished after the best part of a year's effort, only to find that the moment I create what I believe a release version, it loses all the quality it had while developing. |
| ||
| Argh, it's driving me nuts! The thing is finished after the best part of a year's effort, only to find that the moment I create what I believe a release version, it loses all the quality it had while developing. Are you saying you developed it completely in debug mode? :O I only ever turn debug on when I hit a problem.Anyway, testing now... [edit]Well, my monitor doesn't support 1024x768 so I had to test in 800x600. Everything seems pretty smooth to me - the movement of the floating cubes does seem to glitch very slightly, though. Nothing very bad - I doubt I would have noticed if I wasn't looking for it. Have you tried turning off as many background tasks (AV, firewall etc.) and re-testing? |
| ||
| I've tried without antivirus. Unfortunately I can't ask users to disable these so even if I trace it to that, it's something I'd need to work around. The drops might be very small, but they screw up the timing of my machines and turn a level that works into one that doesn't. I've had that happen a couple of times and it'd be quite annoying/confusing to have the level solved but it not work. Also even though the 3D portion might be running without glitch, the mouse freezes are very noticeable and can cause problelms with the UI, dragging a slider only for the mouse to freeze and then appear elsewhere without moving the control. I've just added a time-check for each loop iteration. On average I'm hitting 3 to 5 ms for each frame with all the physics and rendering (but no flip). I also catch the longest time, and some frames takes 7,8, or 9 ms. I've even had jumps to 13 and even 35 ms for a frame! It's as though the Blitz executable is being stopped by the system or something? Putting in a delay of 5 ms at first glance seems to keep these spikes in execution down to 8 ms. It'd make sense to free up time for the OS which otherwise will just take it away from the Blitx program. I'm also using a Wacom Graphire tablet+mouse. Could it be the driver somehow loses focus which would explain the issues with the mouse freezing while the rest of the progran runs okay. I'll need to try a normal mouse and a couple other machines. |
| ||
| I didn't think that running Flip False was a wise thing to do. |
| ||
| I had some similar problems with the zonealarm firewall some time ago. The reason was I had no router and therefor there was a firewall popup alert every other second. It seems for some reason this popup paused the millisecs counter of the machine. Or maybe it simply paused the machine due to a top priority background activity by the firewall (true vector stuff, esp. in fullscreen bitz will be paused when an other process is active), I'm not sure. However, after using a router I rarely have any firewall alerts anymore since the common attacks like port scanning, netbios knocking etc. are blocked in the router. You may try your app after unplugging the net and disabling the firewall. Or maybe even better: set the firewall mode to "block silently" or something like that. |
| ||
| I am using ZA, though with alerts switched off. I'll have to do some system pruning and further investigations... |
| ||
| I'm experiencing the same problems when not in debug mode. I don't have that many demanding background tasks running (and other demanding games run as smooth as anything), and my program runs smoothly in debug mode (windowed) and in non-debug windowed mode. I have tried running full-screen debug mode too, and the performance is good. I think you can comile a program with debug still enabled, which sounds daft but might produce resonable interim results until a proper fix is available! I would have expected that the performance in debug/window to be worse if anything. Hope someone can come up with a solution, I will be most grateful! |
| ||
| I am having this problem as well. It seems like the Blitz3D executable might be updating something once every second. |
| ||
| I dont' know what affect debug mode had, but I did find my textboxes were causing the periodic slowdowns. I was using the Text command to write to a texture and showing this, and that is SLOOOWWWWWW!!!!. Every tenth of a second when my clock updated, Wham, 30+ ms taken drawing a 100x50 pixel 2 digit counter! A different text engine, writing to backbuffer and copying to texture, improved things. Optimally I ought to write straight to backbuffer after rendering, but my results were very good. I overlooked this bottleneck on my system as I wasn't expecting it. I timed all the loops and physics and complex stuff, but didn't time my one call to Draw_Text(). Only when I worked systematically through every block of code did I isolate the problem and manage to get a fix. I can only suggest you do the same, find exactly what line is causing your periodic slowdown, and then find a fix. I don't know what differences debug mode makes, but I'm thinking that slowdowns can be traced to programme behaviour, and so can be fixed. It's not terminal bug in Blitz3D as I first feared when this monster reered it's ugly head. |
| ||
| It's strange that it won't happen in debug mode. I think this has something to do with windows font management that will be in troubles when your program is running at full speed. I wonder if the pauses happen too when you add something like Delay 2 somewhere in the mainloop. BTW it would be relative easy to replace the Text command by a bitmap font that was created at runtime. Simply text all 255 characters to the backbuffer and grab them in an array of bitmaps. Their width can be strored as well, using stringwidth(). Using a negative version of them (using maskcolor) even allows to utilize Color and Rect to achieve colored text. |
| ||
| I used one of the text libs someone created that does just that. Improves speed and gives antialiased edges, so better in every way! |
   |