-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
flickering #76
Comments
forgot to mention that it regards new_model_format branch from kivent |
more prominent (and more minimal, removed physics and boundary systems and lot of images from atlas) example is in repo, hg clone -r example2 https://bitbucket.org/maho/tmpkh2/ When I run it, I see hamster going to and thru. In theory it should move smoothly (it logs position to debug and positions chnges are smooth), but it's movement is ragged. From time to time it looks like going step backward. Effects is more and more prominent when you wait. For me, it looks like frame with texture X is not written in current position, but in position when it was some time ago. Not always, but sometimes. And not last time, but eg. few seconds ago. I think that it's matter with batch reusing, because when I comment out such code:
in batching pyx, then effect looks like gone (but probably there is huge memory leak) |
Hey @mahomahomaho Saw you tried to get a hold of me on IRC. Wanted to say I haven't had a chance to look into this issue yet, but I have not forgotten you either. I will get to it. |
Why do you create a new entity every 4 frames? This contributes to your jerky motion (if you increase the speed of your gamesystem update you will notice you usually actually have 2 birds on screen because the time between frames is so short the eye cannot tell), but you also do not incorporate dt into your position calculation, and only calculate a new position every .1 seconds. If you want smooth motion you need to both use a faster update time and incorporate time into your position calculation. Notice how position is calculated by multiplying a velocity by dt and adding to current position here: https://github.com/kivy/kivent/blob/master/examples/3_creating_a_gamesystem/main.py#L24 Your update function moves the position of the sprite by 20 pixels each update, this is nowhere near smooth motion. |
re our irc chat today:
Note. that there is no more removing and adding entity.
|
I have written wrong hg url in previous comment (edited already). Proper is hg clone -r example3 ........ |
after exhaustive digging and experiments, I think that it happens when IndexBatch.draw_frame() increments current_frame too far, to frame which is not yet prepared. If I understand it correctly, frame is prepared in renderrer update, while CMesh.apply (which calls IndexBatch.draw_frame) is called from somewhere(from where?), and sometimes is called twice. Then frame counter advances too much and we have flicker. So my idea is to move advancing counter from batch.draw_frame to RotateRenderer.update I will prepare pull request tomorrow (sad thing is, that it's solution for -r example3, but not for example2) |
CMesh.apply calls the draw_fame as a result of Renderer.update calling flag_update on the mesh instruction. Renderers are updated exactly once per frame, or should be. Can you share your evidence that it is being called twice? |
Yes. I have added loggers into kivent as in diff, ran
and I see in logs:
so far everything goes ok,
flickers here^^^^
and then ok again. |
… preparation - gitignore
where are you logging the Batch.draw_frame and the RotateRenderer.update? I cannot duplicate the logs you have printed out here. Given that current_frame is incremented only after calling glDrawElements, the 'proper place' for advancing current_frame is where it is now. Your PR is not an appropriate fix. |
@mahomahomaho thanks very much for sticking with this issue! Great diagnoses, and you did find the right solution. I have pushed a fix that is very similar to your PR, but instead of locating the current_frame increment in Renderer, it is in CMesh. Give the latest changes a pull and let me know if it fixes things for you over here. |
well, strange thing - I downloaded example3 again (to remind you:
), ran it with recent 2.2-dev branch and it's flickering like a hell. I did bisect and I see that it starts in rev 4f277d7 - revision earlier, in c7212e2, everything is ok. I have tried to undo changes between c7212e2 and 4f277d7 in 2.2-dev, but didn't help. |
I hoped that rewriting to animationsystem will help, but it has exactly the same. Steps to reproduce:
animation is created in such way: https://bitbucket.org/maho/tmpkh2/src/461425a1e176773941fb210c6d5fb0c303b13643/game.py?fileviewer=file-view-default#game.py-43 |
Okay, when I switched order of AnimationSystem and Renderer in .kv, it doesn't flicker. Which reminds me that order of systems is important re flickering. I remember that we were discussing it before, but I cannot google it out. So there are two doubts:
Order is important, because when unbatch in animation, then it take place immediately on the screen. But batch and generally draw - on next iteration of update of renderrer. So when renderrer is before animation, then it's draw, unbatch, pause between frames (flicker), draw. when animation is before renderrer, then it's unbatch, batch, draw, pause. I'm not sure if second case is "no flickering" or "flickering so fast that almost nobody can see it" :). |
I close this issue, because discussion lead us to somewhere near nowhere :) |
See example:
hg clone -r 111241e https://bitbucket.org/maho/tmpkh2/
cd tmpkh2
python khamster.py
What I see, is character which initially flickers a bit. Sometimes unnoticeable. But every few second, entity is removed and created again. And then it flickers more. After several second, flickering is very, very noticeable.
The text was updated successfully, but these errors were encountered: