Re: [pygame] If statements paused at click hold on window title bar?!

["Brian Fisher" <brian@xxxxxxxxxxxxxxxxxxx>]

Sorry I didn't express myself well - I didn't mean to say the time
elapsed didn't matter, I meant to say that one's movement was also
controlled by code, specifically the % like you pointed out:
  if (frame_num%5)==0:
    x2 = x2+distance_moved*5.
so in that way they are very different.

What I think is happening is after letting go of the mouse, you get
one pass through your game with a big number for distance_moved (like
say 3 seconds worth), and only one in 5 times will that frame_num%5
condition be hit, so 4/5ths of the time, only one sprite gets the time
applied.

Since this is clearly just test code, I didn't say it before, but I
would recommend people decouple draw and update and do a variable
number of fixed time-slice updates based on the time elapsed between
draws as opposed to do updates for a variable amount of time. Meaning
more like this:

  while time_elapsed > time_slice:
    update(time_slice)
    time_elapsed -= time_slice

instead of this:

  update(time_elapsed)

because you get much more consistent simulations regardless of frame
rate, but still are able to adapt to a variety of performance
conditions. I think it's a great way to make it so issues like this
(stuff that makes a long time elapse between updates) aren't so crazy.

....
Also, like I said before, it's perfectly possible to make updates loop
not block during resize or move on windows, it just takes a bit of
ugly platform specific work that may be good to make part of the
pygame or SDL library or something.


On Feb 12, 2008 1:54 PM, Gabriel Hasbun <gastomaster@xxxxxxxxx> wrote:
> "since one sprite is moved by time, and the other is moved by your code
> executing, they move based on different conditions and there you go."
>
> Both sprites are moved based on distance_moved, which is a variable
> resulting from the pygame.time.Clock() instance times the speed, so both
> variables have the same conditions, unless I misunderstood your statement.
>
>
>
>
> Brian Fisher <brian@xxxxxxxxxxxxxxxxxxx> wrote:
>  in windows, when people are clicking the title bar they are moving the
> window (even if not moving the mouse). And by default, moving or
> resizing blocks in your message loop (basically this line doesn't
> return in the way you'd like: "for event in pygame.event.get():")
>
> since one sprite is moved by time, and the other is moved by your code
> executing, they move based on different conditions and there you go.
>
> There is a way to get an app in windows to not be blocked by event
> processing like that (something about calling your update from a
> particular message or returning the right value from some weird barely
> documented message or something like that) but I can't remember the
> exact thing there off the top of my head - I think pyglet had trouble
> with this and found a resolution. Pygame may be able to do the same,
> but it may require some SDL changes or unpleasant hacks.
>
>
>
> On Feb 12, 2008 9:30 AM, Gabriel Hasbun wrote:
> > Probably you already noticed this.
> >
> > I am using Windows XP pro, no service pack, python 2.4 and pygame 1.7.1 ,
> > ran this script:
> >
> > import pygame
> > from pygame.locals import *
> > from sys import exit
> >
> > background_filename='sushiplate.jpg'
> > sprite_filename = 'fugu.png'
> > pygame.init()
> > screen = pygame.display.set_mode((640,480),0,32)
> > background = pygame.image.load(background_filename).convert()
> > sprite = pygame.image.load(sprite_filename).convert_alpha()
> >
> > # Our clock object
> > clock = pygame.time.Clock()
> >
> > # X coordinate of our sprite
> > x1 = -sprite.get_width()
> > x2 = -sprite.get_width()
> > # Speed in pixel(s) per second
> > speed = 250.
> >
> > frame_num = 0
> >
> > while True:
> > for event in pygame.event.get():
> > if event.type == QUIT:
> > exit()
> >
> > screen.blit(background,(0,0))
> > screen.blit(sprite,(x1,50))
> > screen.blit(sprite,(x2,250))
> >
> > time_passed_in_sec = clock.tick(30)/1000.
> > distance_moved = time_passed_in_sec*speed
> > x1+=distance_moved
> >
> > if (frame_num%5)==0:
> > x2 = x2+distance_moved*5.
> >
> > if x1>screen.get_width() or x2>screen.get_width() :
> > x1, x2 = -sprite.get_width(),-sprite.get_width()
> >
> > frame_num+=1
> > pygame.display.update()
> >
> > When I press and hold the mouse on the window title bar, the first sprite
> > (The one with x value blited = x1) advances, while the second one (The one
> > with x value blited = x2) is stuck in the same old x2 value, which makes
> me
> > think that the
> >
> >
> > if (frame_num%5)==0:
> > x2 = x2+distance_moved*5.
> >
> > statements are not read while the mouse button is pressed in the window's
> > title. Also when I leave it for about 5 seconds, when I am sure value of
> x1
> > should be > screen.get_width() , the sprites are drawn from
> >
> > x1, x2 = -sprite.get_width(),-sprite.get_width()
> >
> > after I release the mouse button. The same happens if I leave the mouse
> > button from ~3 seconds up. It makes me think the if statement is not read
> as
> > well
> >
> > if x1>screen.get_width() or x2>screen.get_width() :
> > x1, x2 = -sprite.get_width(),-sprite.get_width()
> >
> >
> >
> >
> > Hope you have any ideas why this happens, and if you've experienced same
> > issues in other OSs and on Windows but with python 2.5 and pygame 1.8.
> >
> > Cheers.
> >
> >
> > ________________________________
> > Looking for last minute shopping deals? Find them fast with Yahoo! Search.
>
>
>
>
>  ________________________________
> Looking for last minute shopping deals? Find them fast with Yahoo! Search.