[pygame] Import error on Windows

[Russell E. Owen]

A colleague is building a Windows application using py2exe. He recently 
upgraded from Python 2.5 and pygame 1.9.1 to Python 2.7 and pygame 
1.9.2pre.win32.py2.7 (I'm guessing 1.9.2a0 but I can't confirm that).

This application only plays sounds, so it only imports pygame.mixer
However, after upgrading Python and pygame the application fails with an 
import error, saying it can't find pygame._view.

For now he's hacked around the problem by explicitly importing 
pygame._view in the code. However, surely this should not be necessary? 
I hope this is a fixable bug in 1.9.2 prerelease

-- Russell

P.S. I never got any response to my offer of a binary installer of 1.9.1 
for Mac Python 2.7. It's still available here:

and it would be great if you folks were willing to serve it.

Re: [pygame] car game mechanics

[Christopher Night]

Oops. I realize I missed the line where you are updating self.rect after
calling transform. I shouldn't have put it in there again. The bit I posted
from the update method should only have read:

#move the car
self.x += speedx
self.y += speedy

#rotate the car
self.sprite = pygame.transform.rotate(self.original,
self.angle * -1)
self.rect = self.sprite.get_rect(center = (self.x, self.y))

Sorry for the confusion!

-Christopher

On Tue, Aug 30, 2011 at 10:22 AM, Christopher Night
wrote:

> Three things you can do to make this more realistic.
>
> 1. use self.angle as the argument to pygame.transform.rotate instead of
> a_deg, as Joe suggested.
>
> 2. use separate variables to keep the car's position. Don't store it in
> self.rect.center. This is because rect positions are coerced to ints, so if
> your car should be moving 0.5 pixels per frame to the right, this will be
> rounded down to 0.
>
> 3. update self.rect after you transform. This is because the rotated image
> doesn't have the same size as the original image, so its center will be
> offset. Also, your second argument to screen.blit should be self.rect, not
> self.rect.center. (If you pass it a position like self.rect.center, it will
> use that as the upper-left position of the blitted rect.
>
> I modified your file to have this in your init method:
>
> self.x, self.y = SCREEN_SIZE_X/2, SCREEN_SIZE_Y -
> self.rect.height * 2
>
> this in your update:
>
> #rotate the car
> self.sprite = pygame.transform.rotate(self.original,
> self.angle * -1)
> self.rect = self.sprite.get_rect(center = self.rect.center)
>
>
> #move the car
> self.x += speedx
> self.y += speedy
>
> self.rect = self.sprite.get_rect()
> self.rect.center = self.x, self.y
>
> and this in your draw:
>
> screen.blit(self.sprite, self.rect)
>
> And it looked much better to me. Let me know what you think.
>
> -Christopher
>
>
> On Tue, Aug 30, 2011 at 5:46 AM, Nathan BIAGINI wrote:
>
>> Hi,
>>
>> i'm trying to write a car game and i have decided to start by the movement
>> part. I calculate the X and Y components of the car and update his position
>> by increasing the current one with the two new components. The two
>> components depend of the orientation of the car, managed by the right and
>> left arrow :
>>
>>
>> speedx = math.sin(self.angle * (math.pi/180)) * SPEED
>>> speedy = math.cos(self.angle * (math.pi/180)) * SPEED * -1
>>>
>>
>> Where SPEED is a constant and self.angle a int representing the
>> orientation. I don't know if this is the best way because, the car speed
>> depends of his orientation. Increasing the self.angle value will increase
>> the components, this is not suitable for a car game i think.
>>
>> I have another problem with the car movement. Each time the orientation
>> change, i would like to rotate the car in the right direction. I thought to
>> do something like that :
>>
>> a_rad = math.asin(speedx/SPEED)
>>> a_deg = math.degrees(a_rad)
>>
>> self.sprite = pygame.transform.rotate(self.original, a_deg * -1)
>>> self.rect = self.sprite.get_rect(center = self.rect.center)
>>>
>>
>> It does not work properly, this way, my car can't rotate over 90° because
>> of the speedx values.
>>
>> Here is my code :
>>
>> http://pastebin.com/VJgQRtYq
>>
>> and the sprite i use for the car is joined.
>>
>> Thanks for reading me.
>>
>
>

Re: [pygame] car game mechanics

[Joe Ranalli]

Just to add one point, the math Nathan is concerned about is technically
sound for basic sprite behavior.  The issue causing dramatically unrealistic
behavior is something caused by the implementation of it.  Specifically that
numerically, some of the values are being rounded to the nearest integer,
which you don't want to happen for realistic movement.

The article that Nathan linked does provide a method for more complex
treatment of a car.  Instead of treating the car as simply rotating about
its center, they're accounting for the fact that a real car steers using its
front wheels while the back wheels are fixed.  Even implementing that
approach in python using Nathans current programming method would cause
unrealistic behavior due to similar rounding and transformation size errors
.

On Tue, Aug 30, 2011 at 10:22 AM, Christopher Night
wrote:

> Three things you can do to make this more realistic.
>
> 1. use self.angle as the argument to pygame.transform.rotate instead of
> a_deg, as Joe suggested.
>
> 2. use separate variables to keep the car's position. Don't store it in
> self.rect.center. This is because rect positions are coerced to ints, so if
> your car should be moving 0.5 pixels per frame to the right, this will be
> rounded down to 0.
>
> 3. update self.rect after you transform. This is because the rotated image
> doesn't have the same size as the original image, so its center will be
> offset. Also, your second argument to screen.blit should be self.rect, not
> self.rect.center. (If you pass it a position like self.rect.center, it will
> use that as the upper-left position of the blitted rect.
>
> I modified your file to have this in your init method:
>
> self.x, self.y = SCREEN_SIZE_X/2, SCREEN_SIZE_Y -
> self.rect.height * 2
>
> this in your update:
>
> #rotate the car
> self.sprite = pygame.transform.rotate(self.original,
> self.angle * -1)
> self.rect = self.sprite.get_rect(center = self.rect.center)
>
>
> #move the car
> self.x += speedx
> self.y += speedy
>
> self.rect = self.sprite.get_rect()
> self.rect.center = self.x, self.y
>
> and this in your draw:
>
> screen.blit(self.sprite, self.rect)
>
> And it looked much better to me. Let me know what you think.
>
> -Christopher
>
>
> On Tue, Aug 30, 2011 at 5:46 AM, Nathan BIAGINI wrote:
>
>> Hi,
>>
>> i'm trying to write a car game and i have decided to start by the movement
>> part. I calculate the X and Y components of the car and update his position
>> by increasing the current one with the two new components. The two
>> components depend of the orientation of the car, managed by the right and
>> left arrow :
>>
>>
>> speedx = math.sin(self.angle * (math.pi/180)) * SPEED
>>> speedy = math.cos(self.angle * (math.pi/180)) * SPEED * -1
>>>
>>
>> Where SPEED is a constant and self.angle a int representing the
>> orientation. I don't know if this is the best way because, the car speed
>> depends of his orientation. Increasing the self.angle value will increase
>> the components, this is not suitable for a car game i think.
>>
>> I have another problem with the car movement. Each time the orientation
>> change, i would like to rotate the car in the right direction. I thought to
>> do something like that :
>>
>> a_rad = math.asin(speedx/SPEED)
>>> a_deg = math.degrees(a_rad)
>>
>> self.sprite = pygame.transform.rotate(self.original, a_deg * -1)
>>> self.rect = self.sprite.get_rect(center = self.rect.center)
>>>
>>
>> It does not work properly, this way, my car can't rotate over 90° because
>> of the speedx values.
>>
>> Here is my code :
>>
>> http://pastebin.com/VJgQRtYq
>>
>> and the sprite i use for the car is joined.
>>
>> Thanks for reading me.
>>
>
>

Re: [pygame] car game mechanics

[Nathan BIAGINI]

Yeah actually this is great!

Thanks all for your help. I'll try go ahead and go to the next step. :)

2011/8/30 Christopher Night 

> Three things you can do to make this more realistic.
>
> 1. use self.angle as the argument to pygame.transform.rotate instead of
> a_deg, as Joe suggested.
>
> 2. use separate variables to keep the car's position. Don't store it in
> self.rect.center. This is because rect positions are coerced to ints, so if
> your car should be moving 0.5 pixels per frame to the right, this will be
> rounded down to 0.
>
> 3. update self.rect after you transform. This is because the rotated image
> doesn't have the same size as the original image, so its center will be
> offset. Also, your second argument to screen.blit should be self.rect, not
> self.rect.center. (If you pass it a position like self.rect.center, it will
> use that as the upper-left position of the blitted rect.
>
> I modified your file to have this in your init method:
>
> self.x, self.y = SCREEN_SIZE_X/2, SCREEN_SIZE_Y -
> self.rect.height * 2
>
> this in your update:
>
> #rotate the car
> self.sprite = pygame.transform.rotate(self.original,
> self.angle * -1)
> self.rect = self.sprite.get_rect(center = self.rect.center)
>
>
> #move the car
> self.x += speedx
> self.y += speedy
>
> self.rect = self.sprite.get_rect()
> self.rect.center = self.x, self.y
>
> and this in your draw:
>
> screen.blit(self.sprite, self.rect)
>
> And it looked much better to me. Let me know what you think.
>
> -Christopher
>
>
> On Tue, Aug 30, 2011 at 5:46 AM, Nathan BIAGINI wrote:
>
>> Hi,
>>
>> i'm trying to write a car game and i have decided to start by the movement
>> part. I calculate the X and Y components of the car and update his position
>> by increasing the current one with the two new components. The two
>> components depend of the orientation of the car, managed by the right and
>> left arrow :
>>
>>
>> speedx = math.sin(self.angle * (math.pi/180)) * SPEED
>>> speedy = math.cos(self.angle * (math.pi/180)) * SPEED * -1
>>>
>>
>> Where SPEED is a constant and self.angle a int representing the
>> orientation. I don't know if this is the best way because, the car speed
>> depends of his orientation. Increasing the self.angle value will increase
>> the components, this is not suitable for a car game i think.
>>
>> I have another problem with the car movement. Each time the orientation
>> change, i would like to rotate the car in the right direction. I thought to
>> do something like that :
>>
>> a_rad = math.asin(speedx/SPEED)
>>> a_deg = math.degrees(a_rad)
>>
>> self.sprite = pygame.transform.rotate(self.original, a_deg * -1)
>>> self.rect = self.sprite.get_rect(center = self.rect.center)
>>>
>>
>> It does not work properly, this way, my car can't rotate over 90° because
>> of the speedx values.
>>
>> Here is my code :
>>
>> http://pastebin.com/VJgQRtYq
>>
>> and the sprite i use for the car is joined.
>>
>> Thanks for reading me.
>>
>
>

Re: [pygame] car game mechanics

[Christopher Night]

Three things you can do to make this more realistic.

1. use self.angle as the argument to pygame.transform.rotate instead of
a_deg, as Joe suggested.

2. use separate variables to keep the car's position. Don't store it in
self.rect.center. This is because rect positions are coerced to ints, so if
your car should be moving 0.5 pixels per frame to the right, this will be
rounded down to 0.

3. update self.rect after you transform. This is because the rotated image
doesn't have the same size as the original image, so its center will be
offset. Also, your second argument to screen.blit should be self.rect, not
self.rect.center. (If you pass it a position like self.rect.center, it will
use that as the upper-left position of the blitted rect.

I modified your file to have this in your init method:

self.x, self.y = SCREEN_SIZE_X/2, SCREEN_SIZE_Y -
self.rect.height * 2

this in your update:

#rotate the car
self.sprite = pygame.transform.rotate(self.original,
self.angle * -1)
self.rect = self.sprite.get_rect(center = self.rect.center)

#move the car
self.x += speedx
self.y += speedy

self.rect = self.sprite.get_rect()
self.rect.center = self.x, self.y

and this in your draw:

screen.blit(self.sprite, self.rect)

And it looked much better to me. Let me know what you think.

-Christopher

On Tue, Aug 30, 2011 at 5:46 AM, Nathan BIAGINI wrote:

> Hi,
>
> i'm trying to write a car game and i have decided to start by the movement
> part. I calculate the X and Y components of the car and update his position
> by increasing the current one with the two new components. The two
> components depend of the orientation of the car, managed by the right and
> left arrow :
>
>
> speedx = math.sin(self.angle * (math.pi/180)) * SPEED
>> speedy = math.cos(self.angle * (math.pi/180)) * SPEED * -1
>>
>
> Where SPEED is a constant and self.angle a int representing the
> orientation. I don't know if this is the best way because, the car speed
> depends of his orientation. Increasing the self.angle value will increase
> the components, this is not suitable for a car game i think.
>
> I have another problem with the car movement. Each time the orientation
> change, i would like to rotate the car in the right direction. I thought to
> do something like that :
>
> a_rad = math.asin(speedx/SPEED)
>> a_deg = math.degrees(a_rad)
>
> self.sprite = pygame.transform.rotate(self.original, a_deg * -1)
>> self.rect = self.sprite.get_rect(center = self.rect.center)
>>
>
> It does not work properly, this way, my car can't rotate over 90° because
> of the speedx values.
>
> Here is my code :
>
> http://pastebin.com/VJgQRtYq
>
> and the sprite i use for the car is joined.
>
> Thanks for reading me.
>

Re: [pygame] car game mechanics

[Nathan BIAGINI]

Yeah indeed it works for the rotation but the movement are not realist at
all the way i did. I found this on the internet :

http://engineeringdotnet.blogspot.com/2010/04/simple-2d-car-physics-in-games.html

it's illustrated by C++ example so i would like to know if there is an
equivalent class to the Vector2 C++ class? Or maybe can i just a numpy array
instead?

2011/8/30 Joe Ranalli 

> You already have self.angle.  Why not just do your transform as a function
> of that?
>
> a_deg = self.angle % 360
>
> sprite = pygame.transform.rotate(self.original, a_deg * -1)
>
> On Tue, Aug 30, 2011 at 7:21 AM, Nathan BIAGINI wrote:
>
>> Doing something like :
>>
>> a_rad = math.atan2(speedy, speedx)
>>
>> ?
>>
>> I can turn 360 degrees yeah but it does not make proper rotation... i ll
>> try to find something on the internet about 2d car physics.
>>
>>
>> 2011/8/30 Weeble 
>>
>>>
>>> On Aug 30, 2011 10:46 AM, "Nathan BIAGINI" 
>>> wrote:
>>>
>>> >> a_rad = math.asin(speedx/SPEED)
>>>
>>> Try math.atan2, feeding it both the x and y components of the velocity.
>>>
>>
>>
>

Re: [pygame] car game mechanics

[Joe Ranalli]

You already have self.angle.  Why not just do your transform as a function
of that?

a_deg = self.angle % 360
sprite = pygame.transform.rotate(self.original, a_deg * -1)

On Tue, Aug 30, 2011 at 7:21 AM, Nathan BIAGINI wrote:

> Doing something like :
>
> a_rad = math.atan2(speedy, speedx)
>
> ?
>
> I can turn 360 degrees yeah but it does not make proper rotation... i ll
> try to find something on the internet about 2d car physics.
>
>
> 2011/8/30 Weeble 
>
>>
>> On Aug 30, 2011 10:46 AM, "Nathan BIAGINI"  wrote:
>>
>> >> a_rad = math.asin(speedx/SPEED)
>>
>> Try math.atan2, feeding it both the x and y components of the velocity.
>>
>
>

Re: [pygame] car game mechanics

[Nathan BIAGINI]

Doing something like :

a_rad = math.atan2(speedy, speedx)

?

I can turn 360 degrees yeah but it does not make proper rotation... i ll try
to find something on the internet about 2d car physics.

2011/8/30 Weeble 

>
> On Aug 30, 2011 10:46 AM, "Nathan BIAGINI"  wrote:
>
> >> a_rad = math.asin(speedx/SPEED)
>
> Try math.atan2, feeding it both the x and y components of the velocity.
>

Re: [pygame] car game mechanics

[Weeble]

On Aug 30, 2011 10:46 AM, "Nathan BIAGINI"  wrote:

>> a_rad = math.asin(speedx/SPEED)

Try math.atan2, feeding it both the x and y components of the velocity.

[pygame] car game mechanics

[Nathan BIAGINI]

Hi,

i'm trying to write a car game and i have decided to start by the movement
part. I calculate the X and Y components of the car and update his position
by increasing the current one with the two new components. The two
components depend of the orientation of the car, managed by the right and
left arrow :


speedx = math.sin(self.angle * (math.pi/180)) * SPEED
> speedy = math.cos(self.angle * (math.pi/180)) * SPEED * -1
>

Where SPEED is a constant and self.angle a int representing the orientation.
I don't know if this is the best way because, the car speed depends of his
orientation. Increasing the self.angle value will increase the components,
this is not suitable for a car game i think.

I have another problem with the car movement. Each time the orientation
change, i would like to rotate the car in the right direction. I thought to
do something like that :

a_rad = math.asin(speedx/SPEED)
> a_deg = math.degrees(a_rad)

self.sprite = pygame.transform.rotate(self.original, a_deg * -1)
> self.rect = self.sprite.get_rect(center = self.rect.center)
>

It does not work properly, this way, my car can't rotate over 90° because of
the speedx values.

Here is my code :

http://pastebin.com/VJgQRtYq

and the sprite i use for the car is joined.

Thanks for reading me.
<>