Re: [pygame] p4a animation lag
Good info, I'll move the clock tick to the main loop and see what that gets me. Thanks for the tip. On Fri, Dec 30, 2011 at 5:46 PM, Ian Mallett wrote: > On Fri, Dec 30, 2011 at 8:00 AM, Sean Wolfe wrote: >> >> Don't have to click for every frame, it will run the whole list of >> frames on a single mousebuttondown. > > That wasn't really my point; graphics is only being drawn when the user > clicks. Generally input and graphics are disassociated. I see that this > way allows you to only redraw when you need to, but it's a bad idea in > general. > > However, given that this *is* your desired behavior, I suspect the actual > problem to be with the clock.tick calls. When passed a framerate argument, > the clock will attempt to average over a certain number of time samples to > get a proper framerate. You're only ever calling tick when there's a mouse > event, so the average will get screwed up. Also, it's set to 10fps, which > is kinda low. > > Ian -- A musician must make music, an artist must paint, a poet must write, if he is to be ultimately at peace with himself. - Abraham Maslow
Re: [pygame] p4a animation lag
On Fri, Dec 30, 2011 at 8:00 AM, Sean Wolfe wrote: > Don't have to click for every frame, it will run the whole list of > frames on a single mousebuttondown. That wasn't really my point; graphics is only being drawn when the user clicks. Generally input and graphics are disassociated. I see that this way allows you to only redraw when you need to, but it's a bad idea in general. However, given that this *is* your desired behavior, I suspect the actual * problem* to be with the clock.tick calls. When passed a framerate argument, the clock will attempt to average over a certain number of time samples to get a proper framerate. You're only ever calling tick when there's a mouse event, so the average will get screwed up. Also, it's set to 10fps, which is kinda low. Ian
Re: [pygame] p4a animation lag
sweet, this is a lot of good information. I've incorporated the convert bit and I'm pushing to the phone now to see. I'll look at the other pieces as well. The good news is the music is working well on android, I've got a background music track playing along with individual sounds for my characters' various attacks. Sounds killer. On Fri, Dec 30, 2011 at 1:38 PM, René Dudfield wrote: > Hi, > > after you convert(), it should definitely be much faster. > > If you don't change the whole background, it might be good just to redraw > the part you are changing. It can be easy to use the sprite.DirtySprite and > sprite.LayeredDirty for this. Or if your other images are completely over > writing it, then you do not need to draw the background at all. You want to > avoid 'overdraw' of pixels if possible, and the work tracking what pixels > you have drawn already is less than the work drawing those pixels. > > Also, the .fill() method is often very fast compared to blit, so that might > be appropriate for you. > > cheers, > > > > On Fri, Dec 30, 2011 at 5:18 PM, Sean Wolfe wrote: >> >> I have *not* converted the surfaces ... I will try that! >> >> I'm blitting the background to basically clear the screen for the next >> frame. Is there a better way to do this? >> >> Thanks for the pointer... >> >> >> >> On Fri, Dec 30, 2011 at 1:05 PM, René Dudfield wrote: >> > Hi, >> > >> > Do you need to blit the background each time? >> > >> > Have you used convert() on the surfaces? >> > >> > cheers, >> > >> > >> > On Fri, Dec 30, 2011 at 5:00 PM, Sean Wolfe wrote: >> >> >> >> Don't have to click for every frame, it will run the whole list of >> >> frames on a single mousebuttondown. >> >> >> >> And the blit of the background takes care of drawing on top of one >> >> another. >> >> >> >> Anybody have any ideas about the lag though? Maybe we need a p4a port >> >> to the Android native kit. >> >> >> >> >> >> >> >> >> >> On Thu, Dec 29, 2011 at 6:59 PM, Ian Mallett >> >> wrote: >> >> > On Thu, Dec 29, 2011 at 1:52 PM, Sean Wolfe >> >> > wrote: >> >> >> >> >> >> frames = [image1, image2, image3] >> >> >> running = True >> >> >> while running: >> >> >> for event in pygame.event.get(): >> >> >> if event.type == MOUSEBUTTONDOWN: >> >> >> clock.tick(10) >> >> >> for img in frames: >> >> >> screen.blit(background, (0,0)) >> >> >> screen.blit(img, position) >> >> >> pygame.display.flip() >> >> >> clock.tick(10) >> >> > >> >> > You do realize that you're only ever drawing when the mouse is >> >> > pressed, >> >> > right? So, you'll have to click for every frame. >> >> > >> >> > Also, you're drawing every frame in the animation on top of each >> >> > other. >> >> > >> >> > Ian >> >> >> >> >> >> >> >> -- >> >> A musician must make music, an artist must paint, a poet must write, >> >> if he is to be ultimately at peace with himself. >> >> - Abraham Maslow >> > >> > >> >> >> >> -- >> A musician must make music, an artist must paint, a poet must write, >> if he is to be ultimately at peace with himself. >> - Abraham Maslow > > -- A musician must make music, an artist must paint, a poet must write, if he is to be ultimately at peace with himself. - Abraham Maslow
Re: [pygame] p4a animation lag
Hi, after you convert(), it should definitely be much faster. If you don't change the whole background, it might be good just to redraw the part you are changing. It can be easy to use the sprite.DirtySprite and sprite.LayeredDirty for this. Or if your other images are completely over writing it, then you do not need to draw the background at all. You want to avoid 'overdraw' of pixels if possible, and the work tracking what pixels you have drawn already is less than the work drawing those pixels. Also, the .fill() method is often very fast compared to blit, so that might be appropriate for you. cheers, On Fri, Dec 30, 2011 at 5:18 PM, Sean Wolfe wrote: > I have *not* converted the surfaces ... I will try that! > > I'm blitting the background to basically clear the screen for the next > frame. Is there a better way to do this? > > Thanks for the pointer... > > > > On Fri, Dec 30, 2011 at 1:05 PM, René Dudfield wrote: > > Hi, > > > > Do you need to blit the background each time? > > > > Have you used convert() on the surfaces? > > > > cheers, > > > > > > On Fri, Dec 30, 2011 at 5:00 PM, Sean Wolfe wrote: > >> > >> Don't have to click for every frame, it will run the whole list of > >> frames on a single mousebuttondown. > >> > >> And the blit of the background takes care of drawing on top of one > >> another. > >> > >> Anybody have any ideas about the lag though? Maybe we need a p4a port > >> to the Android native kit. > >> > >> > >> > >> > >> On Thu, Dec 29, 2011 at 6:59 PM, Ian Mallett > wrote: > >> > On Thu, Dec 29, 2011 at 1:52 PM, Sean Wolfe > wrote: > >> >> > >> >> frames = [image1, image2, image3] > >> >> running = True > >> >> while running: > >> >>for event in pygame.event.get(): > >> >>if event.type == MOUSEBUTTONDOWN: > >> >>clock.tick(10) > >> >>for img in frames: > >> >>screen.blit(background, (0,0)) > >> >>screen.blit(img, position) > >> >>pygame.display.flip() > >> >>clock.tick(10) > >> > > >> > You do realize that you're only ever drawing when the mouse is > pressed, > >> > right? So, you'll have to click for every frame. > >> > > >> > Also, you're drawing every frame in the animation on top of each > other. > >> > > >> > Ian > >> > >> > >> > >> -- > >> A musician must make music, an artist must paint, a poet must write, > >> if he is to be ultimately at peace with himself. > >> - Abraham Maslow > > > > > > > > -- > A musician must make music, an artist must paint, a poet must write, > if he is to be ultimately at peace with himself. > - Abraham Maslow >
Re: [pygame] p4a animation lag
I have *not* converted the surfaces ... I will try that! I'm blitting the background to basically clear the screen for the next frame. Is there a better way to do this? Thanks for the pointer... On Fri, Dec 30, 2011 at 1:05 PM, René Dudfield wrote: > Hi, > > Do you need to blit the background each time? > > Have you used convert() on the surfaces? > > cheers, > > > On Fri, Dec 30, 2011 at 5:00 PM, Sean Wolfe wrote: >> >> Don't have to click for every frame, it will run the whole list of >> frames on a single mousebuttondown. >> >> And the blit of the background takes care of drawing on top of one >> another. >> >> Anybody have any ideas about the lag though? Maybe we need a p4a port >> to the Android native kit. >> >> >> >> >> On Thu, Dec 29, 2011 at 6:59 PM, Ian Mallett wrote: >> > On Thu, Dec 29, 2011 at 1:52 PM, Sean Wolfe wrote: >> >> >> >> frames = [image1, image2, image3] >> >> running = True >> >> while running: >> >> for event in pygame.event.get(): >> >> if event.type == MOUSEBUTTONDOWN: >> >> clock.tick(10) >> >> for img in frames: >> >> screen.blit(background, (0,0)) >> >> screen.blit(img, position) >> >> pygame.display.flip() >> >> clock.tick(10) >> > >> > You do realize that you're only ever drawing when the mouse is pressed, >> > right? So, you'll have to click for every frame. >> > >> > Also, you're drawing every frame in the animation on top of each other. >> > >> > Ian >> >> >> >> -- >> A musician must make music, an artist must paint, a poet must write, >> if he is to be ultimately at peace with himself. >> - Abraham Maslow > > -- A musician must make music, an artist must paint, a poet must write, if he is to be ultimately at peace with himself. - Abraham Maslow
Re: [pygame] p4a animation lag
Hi, Do you need to blit the background each time? Have you used convert() on the surfaces? cheers, On Fri, Dec 30, 2011 at 5:00 PM, Sean Wolfe wrote: > Don't have to click for every frame, it will run the whole list of > frames on a single mousebuttondown. > > And the blit of the background takes care of drawing on top of one another. > > Anybody have any ideas about the lag though? Maybe we need a p4a port > to the Android native kit. > > > > > On Thu, Dec 29, 2011 at 6:59 PM, Ian Mallett wrote: > > On Thu, Dec 29, 2011 at 1:52 PM, Sean Wolfe wrote: > >> > >> frames = [image1, image2, image3] > >> running = True > >> while running: > >>for event in pygame.event.get(): > >>if event.type == MOUSEBUTTONDOWN: > >>clock.tick(10) > >>for img in frames: > >>screen.blit(background, (0,0)) > >>screen.blit(img, position) > >>pygame.display.flip() > >>clock.tick(10) > > > > You do realize that you're only ever drawing when the mouse is pressed, > > right? So, you'll have to click for every frame. > > > > Also, you're drawing every frame in the animation on top of each other. > > > > Ian > > > > -- > A musician must make music, an artist must paint, a poet must write, > if he is to be ultimately at peace with himself. > - Abraham Maslow >
Re: [pygame] p4a animation lag
Don't have to click for every frame, it will run the whole list of frames on a single mousebuttondown. And the blit of the background takes care of drawing on top of one another. Anybody have any ideas about the lag though? Maybe we need a p4a port to the Android native kit. On Thu, Dec 29, 2011 at 6:59 PM, Ian Mallett wrote: > On Thu, Dec 29, 2011 at 1:52 PM, Sean Wolfe wrote: >> >> frames = [image1, image2, image3] >> running = True >> while running: >> for event in pygame.event.get(): >> if event.type == MOUSEBUTTONDOWN: >> clock.tick(10) >> for img in frames: >> screen.blit(background, (0,0)) >> screen.blit(img, position) >> pygame.display.flip() >> clock.tick(10) > > You do realize that you're only ever drawing when the mouse is pressed, > right? So, you'll have to click for every frame. > > Also, you're drawing every frame in the animation on top of each other. > > Ian -- A musician must make music, an artist must paint, a poet must write, if he is to be ultimately at peace with himself. - Abraham Maslow
