-
Screen Flicker
Hi all,
A while ago when I posted my Hovertank project, you may have noticed 'screen flicker.' I specifically remember Bubba suggesting that I clamp the framerate (V-Sync). I am not totally sure what the cause of this problem is.
I will describe it in better detail. Occasionally, while running the simulation, everything but the sky seems to 'disappear,' meaning that the renderer is not rendering everything else. This lasts for only a frame or so, and does not happen often. I am trying to reproduce the results to find out what, exactly, may be the cause of this problem.
As of yet I am still not sure if this happens at high or low framerates, or if the coordination between rendering physics and rendering graphics is having a problem. I am also instructing the system to sleep a certain amount as to yield processing cycles. I have tried disabling this feature, but I am having a lot of difficulty reproducing/predicting the problem (as stated, it does not happen consistently).
If any of you have any ideas as per what may be causing this, please let me know.
The project link I refer to may be downloaded from here.
ihatenature.thejefffiles.com/hover.zip
It would help me a lot if some of you could try varying the resolution to see when the screen flicker occurs. Thanks.
-
I was wondering if your game already implemented Double Bouffering. The screen flicker might simply be the visible artifacts from the drawing process during random high load time.
-
Yes, the app. uses double buffering.
-
Does everyone see this or is it just a few comps? maybe it's related to a specific driver or card type..
-
Actually, I cannot verify that everyone sees it. I'd noticed it before posting it, and then when Bubba brought it up I decided it was an issue I needed to tackle. I believe Bubba has an nVidia chipset, while I have an ATI, therefore my guess is it is not driver specific.
-
The only time I see any flickering is at really high velocities (like if you drive of the edge and spin really fast). That's at 1024x768x32 windowed. See sig for system details.
-
Yep! You got it. When you said that, I promptly flew off of the cliff, rather than just trying to drive over the jumps, let the craft fall, and eventually the craft disappears entirely! It's not a problem of synchronization I don't think, but rather the relationship between the physics and rendering the results of the physics (because only the model disappears, not the skybox or the world).
Thanks for figuring that out for me Psychopath.
-
No prob. Glad I could help :).
-
Well if you solved the issue congrats but most screen flicker, specifically the type I witnessed in your app Bob, is caused by extremely high frame rates.
But I could see that a synchronization error between physics code and render code could also cause some very odd artifacts.
-
I have solved the problem. I understand that visible artifacts can be a direct result of not synchronizing the framerate, but I'm already synching it at 100 FPS and that in and of itself is typically good enough to avoid problems (in my experience).
I disabled frustum culling on the Model that represents the hovercraft. The problem is that the frustum I was building was actually from the *last frame*. Therefore, if you are sitting in the cockpit, the sphere of the model that you are technically inside is actually quite close to not 'being in the frustum.' The way I've got it setup, the hovercraft always does a frustum test before sending itself to the renderer (there are multiple hovercraft, one driven by the player, others driven by AI, so the hovercraft doesn't know that you might always be in the cockpit and hence always visible).
So, what happens is that, if you are going at very high velocities, and due to the fact that the frustum is built from the last frame, then the actual position between the hovercraft model and where the frustum is becomes large enough that the hovercraft is outside the frustum, the frustum test fails, and the hovercraft model does not get rendered!
From my main Cycle function:
Code:
pTest_Hovertank->Render();
pTest_Hovertank1->Render();
Export.pRenderScene();
Hovertank::Render() does a frustum test, and if it is visible, it sends its model to gpGLRenderer. The Export.pRenderScene() builds the frustum, and then instructs the world to render itself, and does some more high-level stuff. But, the point is, I'm not building the frustum until *after* I added the Hovercraft to the renderer, meaning that when the Hovercraft does a frustum test, it's using the frustum *from the last frame*!!!
So I just built the frustum prior to calling the render hook on the hovercraft.
I want to add so many things to this project, but I'm just so damn busy! I want to add friction to the underbody so that you slow down and don't drift as much, I want to make it so you can look around within the cockpit, I've got to fix a couple of problems with the way unpenetrations are handled, I want to add more complex collision bodies such as boxes, ellipsoids and cylinders, I want to make it so that you can join rigid bodies together at a joint, and tow stuff around. I want to do some fluid approximations to get fluid flow across a lamina, and then get lift and drag. On top of this I'm still working on a ship structure and stability program and a water simulation program, and also doing school.
