The start of a game in pygame, blitting images to the screen
up vote
1
down vote
favorite
The small bit of code below blits and image to the screen within a class. I call this 4 times to display the image 4 times, each image has a different y coordinate and doesn't need different x but when they are blitted they make the code MUCH slower. I know it is the blitting as well due to the fact that if i just draw rects instead, the program moves smoothly.
tableTex = pygame.transform.scale(pygame.image.load('./Sources/Table.png'), (270, 240))
def display(self):
if not self.occupied:
screen.blit(tableTex, (self.x, self.y))
else:
pygame.draw.rect(screen, (127, 0, 0), self.rect, 0)
A link to the full code can be found here if needed.
I just want to know if there is any reason this is so slow and if there are any other methods I could use that are faster?
Thanks
python object-oriented pygame
bumped to the homepage by Community♦ 2 days ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
up vote
1
down vote
favorite
The small bit of code below blits and image to the screen within a class. I call this 4 times to display the image 4 times, each image has a different y coordinate and doesn't need different x but when they are blitted they make the code MUCH slower. I know it is the blitting as well due to the fact that if i just draw rects instead, the program moves smoothly.
tableTex = pygame.transform.scale(pygame.image.load('./Sources/Table.png'), (270, 240))
def display(self):
if not self.occupied:
screen.blit(tableTex, (self.x, self.y))
else:
pygame.draw.rect(screen, (127, 0, 0), self.rect, 0)
A link to the full code can be found here if needed.
I just want to know if there is any reason this is so slow and if there are any other methods I could use that are faster?
Thanks
python object-oriented pygame
bumped to the homepage by Community♦ 2 days ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
You should add the definition oftableTex
to the code, since it is actually quite relevant.
– Graipher
Jul 3 at 15:49
1
@Graipher My bad - Updated it now
– Thomas Ayling
Jul 3 at 15:51
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
The small bit of code below blits and image to the screen within a class. I call this 4 times to display the image 4 times, each image has a different y coordinate and doesn't need different x but when they are blitted they make the code MUCH slower. I know it is the blitting as well due to the fact that if i just draw rects instead, the program moves smoothly.
tableTex = pygame.transform.scale(pygame.image.load('./Sources/Table.png'), (270, 240))
def display(self):
if not self.occupied:
screen.blit(tableTex, (self.x, self.y))
else:
pygame.draw.rect(screen, (127, 0, 0), self.rect, 0)
A link to the full code can be found here if needed.
I just want to know if there is any reason this is so slow and if there are any other methods I could use that are faster?
Thanks
python object-oriented pygame
The small bit of code below blits and image to the screen within a class. I call this 4 times to display the image 4 times, each image has a different y coordinate and doesn't need different x but when they are blitted they make the code MUCH slower. I know it is the blitting as well due to the fact that if i just draw rects instead, the program moves smoothly.
tableTex = pygame.transform.scale(pygame.image.load('./Sources/Table.png'), (270, 240))
def display(self):
if not self.occupied:
screen.blit(tableTex, (self.x, self.y))
else:
pygame.draw.rect(screen, (127, 0, 0), self.rect, 0)
A link to the full code can be found here if needed.
I just want to know if there is any reason this is so slow and if there are any other methods I could use that are faster?
Thanks
python object-oriented pygame
python object-oriented pygame
edited Jul 3 at 15:52
asked Jul 3 at 12:08
Thomas Ayling
194
194
bumped to the homepage by Community♦ 2 days ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 2 days ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
You should add the definition oftableTex
to the code, since it is actually quite relevant.
– Graipher
Jul 3 at 15:49
1
@Graipher My bad - Updated it now
– Thomas Ayling
Jul 3 at 15:51
add a comment |
You should add the definition oftableTex
to the code, since it is actually quite relevant.
– Graipher
Jul 3 at 15:49
1
@Graipher My bad - Updated it now
– Thomas Ayling
Jul 3 at 15:51
You should add the definition of
tableTex
to the code, since it is actually quite relevant.– Graipher
Jul 3 at 15:49
You should add the definition of
tableTex
to the code, since it is actually quite relevant.– Graipher
Jul 3 at 15:49
1
1
@Graipher My bad - Updated it now
– Thomas Ayling
Jul 3 at 15:51
@Graipher My bad - Updated it now
– Thomas Ayling
Jul 3 at 15:51
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
As noted in the beginners guide, you should convert your image right after loading it. So instead of
tableTex = pygame.transform.scale(pygame.image.load('./Sources/Table.png'), (270, 240))
Do
tableTex = pygame.transform.scale(pygame.image.load('./Sources/Table.png').convert(), (270, 240))
As noted in the guide linked above, this can lead to a speed-up of about a factor 6. The reason is:
The 'format' that convert() refers to isn't the file format (ie PNG,
JPEG, GIF), it's what's called the 'pixel format'. This refers to the
particular way that a surface records individual colors in a specific
pixel. If the surface format isn't the same as the display format, SDL [what pygame uses underneath]
will have to convert it on-the-fly for every blit -- a fairly
time-consuming process. Don't worry too much about the explanation;
just note that convert() is necessary if you want to get any kind of
speed out of your blits.
Thanks very much for the reply, however using convert adds some very strange deformities to my loaded images imgur.com/a/htautZi
– Thomas Ayling
Jul 3 at 15:55
@ThomasAyling: I don't see them. But I just changed my answer to callconvert
on the loaded image, not the scaled one. Does that change anything?
– Graipher
Jul 3 at 15:57
No, i still get the same problem imgur.com/a/80IPaj7 (New image)
– Thomas Ayling
Jul 3 at 15:59
@ThomasAyling: That does indeed look weird (comparing it to the original in the github). Maybe the picture contains transparency which is wrongly interpreted?
– Graipher
Jul 3 at 16:01
Possibly, it works properly without the convert in still so maybe there were some issues with compression, i'll try re-saving it from Photoshop
– Thomas Ayling
Jul 3 at 16:03
|
show 1 more comment
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
As noted in the beginners guide, you should convert your image right after loading it. So instead of
tableTex = pygame.transform.scale(pygame.image.load('./Sources/Table.png'), (270, 240))
Do
tableTex = pygame.transform.scale(pygame.image.load('./Sources/Table.png').convert(), (270, 240))
As noted in the guide linked above, this can lead to a speed-up of about a factor 6. The reason is:
The 'format' that convert() refers to isn't the file format (ie PNG,
JPEG, GIF), it's what's called the 'pixel format'. This refers to the
particular way that a surface records individual colors in a specific
pixel. If the surface format isn't the same as the display format, SDL [what pygame uses underneath]
will have to convert it on-the-fly for every blit -- a fairly
time-consuming process. Don't worry too much about the explanation;
just note that convert() is necessary if you want to get any kind of
speed out of your blits.
Thanks very much for the reply, however using convert adds some very strange deformities to my loaded images imgur.com/a/htautZi
– Thomas Ayling
Jul 3 at 15:55
@ThomasAyling: I don't see them. But I just changed my answer to callconvert
on the loaded image, not the scaled one. Does that change anything?
– Graipher
Jul 3 at 15:57
No, i still get the same problem imgur.com/a/80IPaj7 (New image)
– Thomas Ayling
Jul 3 at 15:59
@ThomasAyling: That does indeed look weird (comparing it to the original in the github). Maybe the picture contains transparency which is wrongly interpreted?
– Graipher
Jul 3 at 16:01
Possibly, it works properly without the convert in still so maybe there were some issues with compression, i'll try re-saving it from Photoshop
– Thomas Ayling
Jul 3 at 16:03
|
show 1 more comment
up vote
0
down vote
As noted in the beginners guide, you should convert your image right after loading it. So instead of
tableTex = pygame.transform.scale(pygame.image.load('./Sources/Table.png'), (270, 240))
Do
tableTex = pygame.transform.scale(pygame.image.load('./Sources/Table.png').convert(), (270, 240))
As noted in the guide linked above, this can lead to a speed-up of about a factor 6. The reason is:
The 'format' that convert() refers to isn't the file format (ie PNG,
JPEG, GIF), it's what's called the 'pixel format'. This refers to the
particular way that a surface records individual colors in a specific
pixel. If the surface format isn't the same as the display format, SDL [what pygame uses underneath]
will have to convert it on-the-fly for every blit -- a fairly
time-consuming process. Don't worry too much about the explanation;
just note that convert() is necessary if you want to get any kind of
speed out of your blits.
Thanks very much for the reply, however using convert adds some very strange deformities to my loaded images imgur.com/a/htautZi
– Thomas Ayling
Jul 3 at 15:55
@ThomasAyling: I don't see them. But I just changed my answer to callconvert
on the loaded image, not the scaled one. Does that change anything?
– Graipher
Jul 3 at 15:57
No, i still get the same problem imgur.com/a/80IPaj7 (New image)
– Thomas Ayling
Jul 3 at 15:59
@ThomasAyling: That does indeed look weird (comparing it to the original in the github). Maybe the picture contains transparency which is wrongly interpreted?
– Graipher
Jul 3 at 16:01
Possibly, it works properly without the convert in still so maybe there were some issues with compression, i'll try re-saving it from Photoshop
– Thomas Ayling
Jul 3 at 16:03
|
show 1 more comment
up vote
0
down vote
up vote
0
down vote
As noted in the beginners guide, you should convert your image right after loading it. So instead of
tableTex = pygame.transform.scale(pygame.image.load('./Sources/Table.png'), (270, 240))
Do
tableTex = pygame.transform.scale(pygame.image.load('./Sources/Table.png').convert(), (270, 240))
As noted in the guide linked above, this can lead to a speed-up of about a factor 6. The reason is:
The 'format' that convert() refers to isn't the file format (ie PNG,
JPEG, GIF), it's what's called the 'pixel format'. This refers to the
particular way that a surface records individual colors in a specific
pixel. If the surface format isn't the same as the display format, SDL [what pygame uses underneath]
will have to convert it on-the-fly for every blit -- a fairly
time-consuming process. Don't worry too much about the explanation;
just note that convert() is necessary if you want to get any kind of
speed out of your blits.
As noted in the beginners guide, you should convert your image right after loading it. So instead of
tableTex = pygame.transform.scale(pygame.image.load('./Sources/Table.png'), (270, 240))
Do
tableTex = pygame.transform.scale(pygame.image.load('./Sources/Table.png').convert(), (270, 240))
As noted in the guide linked above, this can lead to a speed-up of about a factor 6. The reason is:
The 'format' that convert() refers to isn't the file format (ie PNG,
JPEG, GIF), it's what's called the 'pixel format'. This refers to the
particular way that a surface records individual colors in a specific
pixel. If the surface format isn't the same as the display format, SDL [what pygame uses underneath]
will have to convert it on-the-fly for every blit -- a fairly
time-consuming process. Don't worry too much about the explanation;
just note that convert() is necessary if you want to get any kind of
speed out of your blits.
edited Jul 3 at 15:56
answered Jul 3 at 15:49
Graipher
22.6k53384
22.6k53384
Thanks very much for the reply, however using convert adds some very strange deformities to my loaded images imgur.com/a/htautZi
– Thomas Ayling
Jul 3 at 15:55
@ThomasAyling: I don't see them. But I just changed my answer to callconvert
on the loaded image, not the scaled one. Does that change anything?
– Graipher
Jul 3 at 15:57
No, i still get the same problem imgur.com/a/80IPaj7 (New image)
– Thomas Ayling
Jul 3 at 15:59
@ThomasAyling: That does indeed look weird (comparing it to the original in the github). Maybe the picture contains transparency which is wrongly interpreted?
– Graipher
Jul 3 at 16:01
Possibly, it works properly without the convert in still so maybe there were some issues with compression, i'll try re-saving it from Photoshop
– Thomas Ayling
Jul 3 at 16:03
|
show 1 more comment
Thanks very much for the reply, however using convert adds some very strange deformities to my loaded images imgur.com/a/htautZi
– Thomas Ayling
Jul 3 at 15:55
@ThomasAyling: I don't see them. But I just changed my answer to callconvert
on the loaded image, not the scaled one. Does that change anything?
– Graipher
Jul 3 at 15:57
No, i still get the same problem imgur.com/a/80IPaj7 (New image)
– Thomas Ayling
Jul 3 at 15:59
@ThomasAyling: That does indeed look weird (comparing it to the original in the github). Maybe the picture contains transparency which is wrongly interpreted?
– Graipher
Jul 3 at 16:01
Possibly, it works properly without the convert in still so maybe there were some issues with compression, i'll try re-saving it from Photoshop
– Thomas Ayling
Jul 3 at 16:03
Thanks very much for the reply, however using convert adds some very strange deformities to my loaded images imgur.com/a/htautZi
– Thomas Ayling
Jul 3 at 15:55
Thanks very much for the reply, however using convert adds some very strange deformities to my loaded images imgur.com/a/htautZi
– Thomas Ayling
Jul 3 at 15:55
@ThomasAyling: I don't see them. But I just changed my answer to call
convert
on the loaded image, not the scaled one. Does that change anything?– Graipher
Jul 3 at 15:57
@ThomasAyling: I don't see them. But I just changed my answer to call
convert
on the loaded image, not the scaled one. Does that change anything?– Graipher
Jul 3 at 15:57
No, i still get the same problem imgur.com/a/80IPaj7 (New image)
– Thomas Ayling
Jul 3 at 15:59
No, i still get the same problem imgur.com/a/80IPaj7 (New image)
– Thomas Ayling
Jul 3 at 15:59
@ThomasAyling: That does indeed look weird (comparing it to the original in the github). Maybe the picture contains transparency which is wrongly interpreted?
– Graipher
Jul 3 at 16:01
@ThomasAyling: That does indeed look weird (comparing it to the original in the github). Maybe the picture contains transparency which is wrongly interpreted?
– Graipher
Jul 3 at 16:01
Possibly, it works properly without the convert in still so maybe there were some issues with compression, i'll try re-saving it from Photoshop
– Thomas Ayling
Jul 3 at 16:03
Possibly, it works properly without the convert in still so maybe there were some issues with compression, i'll try re-saving it from Photoshop
– Thomas Ayling
Jul 3 at 16:03
|
show 1 more comment
Thanks for contributing an answer to Code Review Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f197718%2fthe-start-of-a-game-in-pygame-blitting-images-to-the-screen%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
You should add the definition of
tableTex
to the code, since it is actually quite relevant.– Graipher
Jul 3 at 15:49
1
@Graipher My bad - Updated it now
– Thomas Ayling
Jul 3 at 15:51