I don't know if it really is that big of an issue, or just a case of people complaining because it's hard to get right :) There may be a way we can aleviate this in pyglet, and we definitely should try to do that even if it's difficult.
I forgot about this bug: https://bitbucket.org/pyglet/pyglet/issues/40/windows-clock-timing-is-not-precise-enough but it looks like your one system is affected. Unfortunately stutterning is still present on Linux, where all of the tests pass, but it would be nice to squash this issue. What differences are there between your two systems? Are they the same python versions, and same Windows version? Also, if you have a moment, could you try those tests again with Leif's new heap_clock? You should be able to just clone his repo and run the tests directly, or just copy the pyglet/clock.py file into your local copy of pyglet. https://bitbucket.org/leif_theden/pyglet/branch/heap_clock On Wednesday, March 1, 2017 at 6:11:08 AM UTC+9, Charles wrote: > > I see, I had no idea this was such a big issue with OpenGL. I don't recall > seeing this issue in any DirectX games, so that makes sense. > > Also I have tested the timer (and the test FPS in the tests folder) and it > failed on one system, passed on one other. It failed on one i7 processor > and passed on an i5 processor. I am not sure what these tests are to > determine (precision of timer?). > > On Sunday, February 26, 2017 at 11:21:07 PM UTC-6, Benjamin Moran wrote: >> >> Just wanted to add that smooth scrolling is really difficult to do, and a >> lot of production games also have stutters. For example, Axiom Verge has >> exactly this same stuttering. I've been playing that recently, and you can >> notice it if you look. >> >> One trick that people do is to set the target FPS to 61, and make sure >> vsync is enabled. This will give you the smooth scrolling you desire by >> pushing against the vsync and effectively letting the GPU do it. >> Unfortunately, this won't work with higher refresh rate monitors that are >> starting to come out now, but will do the trick for the majority of users. >> >> I've seen some general OpenGL articles claiming that completely smooth >> scrolling is "impossible on the CPU" and that you need to let the GPU do it >> (as in the trick above). I'm not sure if that's true or not, since we do >> have access to much higher precision counters these days. Anyway, if we can >> improve pyglet in the area then we should do it. >> >> >> On Thursday, February 23, 2017 at 11:27:29 PM UTC+9, Benjamin Moran wrote: >>> >>> I'm not an expert on this topic, but pyglet is currently using a >>> Waitable Timer on Windows, and Glibc usleep on Linux. This should be >>> microsecond precision on both platforms. If there is a more precise way to >>> do this, then it's worth doing. The clock module actually has a built in >>> test function that you can run by: "python pyglet/clock.py" >>> There are a few options for testing. >>> >>> >>> >>> On Wednesday, February 22, 2017 at 4:03:39 PM UTC+9, Charles wrote: >>>> >>>> I've been noticing this quite often, but what essentially what happens >>>> is, the sprite 'catches' and has a small stutter as it moves. At first I >>>> thought this was a camera issue, but I have since noticed it on sprites >>>> moving without any screen movement whatsoever. >>>> >>>> The movement is fast, but there seems to be periods where it starts to >>>> stutter. This can be several in a row, to constant, to every other second, >>>> but it's there. >>>> >>>> I have reduced the issue to a basic program: >>>> >>>> import pyglet >>>> >>>> window = pyglet.window.Window(800,600, vsync=False) >>>> fps_display = pyglet.clock.ClockDisplay(color=(1,0,0,0.5)) >>>> >>>> batch = pyglet.graphics.Batch() >>>> >>>> tileImg = pyglet.image.load("tile_test.png") >>>> >>>> playerImg = pyglet.image.load("square.png") >>>> >>>> group = pyglet.graphics.Group() >>>> >>>> sprites = [] >>>> for i in xrange(50): >>>> for j in xrange(50): >>>> sprites.append(pyglet.sprite.Sprite(tileImg, x=i*32, y=j*32, >>>> batch=batch)) >>>> >>>> playerSprite = pyglet.sprite.Sprite(playerImg, x=50, y=50, batch=batch) >>>> >>>> @window.event >>>> def on_draw(): >>>> window.clear() >>>> >>>> batch.draw() >>>> >>>> def moveChar(dt, axis, val): >>>> if axis == "x": >>>> playerSprite.update(x=playerSprite.x+val) >>>> else: >>>> playerSprite.update(y=playerSprite.y+val) >>>> >>>> @window.event >>>> def on_key_press(symbol,modifiers): >>>> if symbol == pyglet.window.key.LEFT: >>>> pyglet.clock.schedule_interval(moveChar, 1/60.0, "x", -1) >>>> >>>> elif symbol == pyglet.window.key.RIGHT: >>>> pyglet.clock.schedule_interval(moveChar, 1/60.0, "x", 1) >>>> >>>> elif symbol == pyglet.window.key.UP: >>>> pyglet.clock.schedule_interval(moveChar, 1/60.0, "y", 1) >>>> >>>> elif symbol == pyglet.window.key.DOWN: >>>> >>>> pyglet.clock.schedule_interval(moveChar, 1/60.0, "y", -1) >>>> >>>> else: >>>> pyglet.clock.unschedule(moveChar) >>>> >>>> >>>> pyglet.app.run() >>>> >>>> >>>> Can anyone test this to see if they too get an issue? I am not sure if >>>> we are allowed to post links here but I have a simple video showcasing the >>>> issue: http://www.mediafire.com/file/ir7f5x5gxnbgi90/sprite-stutter.mp4 >>>> (Sorry on the hosting, YT butchers the quality to where you can't see it) >>>> >>> -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
