When using python and pygame: after loading the screen with the background image and blitting new objects (Text, circles, rectangles, etc.), is there a way to save the modified screen so as to be recalled later in the program? Specifically, I am setting the background and blitting new objects and would like to save the screen image with all of the blits in intact so it can be used later in the program as a new background upon which sprites can be manipulated. Any suggestions welcomed!
Blitting works both ways, meaning you can blit something onto the display screen, but you can also blit the screen onto another surface. So simply make a new surface the same size of your display surface and blit the screen onto that surface for later use.
found a solution and it works better than I expected:
after blitted my raw background onto my surface and then adding numerous circles, rectangles and text to make an image with multiple dial, gauges and labels I ran the following:
pygame.display.update()
window = pygame.display.set_mode((800,480),0,32)
pygame.image.save(TFT,"screen_update.jpg")
the new image is saved to disk(XDcard on my RPi2) as "screen_update.jpg"
then I simply change the name to "ANAL_update.jpg" and use that as the background on my next program run. I commented out all of the code used to create the rectangles, circles and labels and it works. I will add an selectable "update" routine to the program and move all of extra drawing and labelling to that routine to be used when I wish to change the layout of he background. I like the fact that the program creates a new updated file that just needs to be renamed for use and for copying the background to other machines.
note: This is working on my RaspberryPi 2B with HDMI output to a 42" HD tv for development, but it is intended to run on an RPi3B with he official RPi 7 inch TFT display. Thanks to all of you that responded and to the others who left pertinent code for previous questions similar to mine.
Related
I'm using pygame and I've been working so far in a large monitor, but now I need to work on a small laptop, whose screen is much smaller than the mentioned monitor. The dimensions I gave to the display surface and the items blitted to it work well on the previous monitor but it is too large on the laptop and therefore I cannot reach all buttons. Since I can't seem to find a way to resize everything proportionaly, is there an easy way to add a vertical and horizontal scroll bar in order to navigate around the display surface?
Thank you
I don't think that you can add a scroll bar. What you can do is shift the x or y of everything when you press the corresponding arrow keys. But as said by Ted Klein Bergman, it is better to simply resize everything.
I am working on tiny program to capture screen print, I want to do it in a similar fashion that Win Snipping Tool is working. First I need to overlay all screens with a 50% opacity layer and then, using the mouse, draw a rectangle and read vertices coordinates. Honestly, I have no idea how to bite this. I tried with win32api / gui and it is great to get mouse coordinates, but still was unable to draw a rectangle. My idea (one of many) is to (using PIL / ImageGrab) take shots of both displays, put an overlay and print them as a full screen on all windows, but I failed while doing this. Other idea is to take img grab and create two new windows using BeeWare / Toga (that is GUI framework I am using) in full screen, but I was unable to find any method to open window on second display. Any ideas and hints will be greatly appreciated, I am really counting on you, as I feel I reached dead end.
Well,It is very easy to use tkinter.
Ok,It is the principle when I make my screenshot application:
User presses the button to start.
Make a new window whose width and height should full cover all the screens,and hide the title bar(If it is had to achieve,maybe use width=9999 and height=9999).
Take a screenshot of all the desktop(You can use ImageGrab.grab((),all_screens=True)) to do that.
Make the screenshot showed in a Canvas(I know that toga have this widget).
Start your mouse listener thread and save the position of pressed.
When user moves his mouse,create a rectangle(toga's Canvas have a function rect()).Maybe use this rect(pressed_x,pressed_y,move_x,move_y).And delete the last rectangle(Then it will always show only one rectangle).
When user released his mouse,save the position of released.And use ImageGrab.grab((pressed_x,pressed_y,released_x,released_y),all_screens=True) to crop the selected area.
If you want to show it in application interface.toga has a widget called ImageView.You can put the image in it.
I'm having some performance issues in pygame, so I'm trying to optimize the rendering.
Currently, I'm blitting the background image to the display buffer:
self.display.blit(self.bg, (0, 0))
Instead, I'm looking for a way to replace the buffer with a copy of the background surface, and draw over that. This way, I don't have to blit a large image every frame, saving me some time.
Is there any way to do so?
It doesn't matter that much how often you blit something to the screen surface, since the display does only get updated once you call pygame.display.update or pygame.display.flip.
If you're sure that blitting the whole background image to the screen surface is a bottle neck in your game, you can try the following things:
a) Instead of blitting the whole background every frame, use the clear() function to "erase" your sprites from the screen.
b) Instead of calling pygame.display.flip or pygame.display.update without an argument, call pygame.display.update with the list of the areas on the screen that have been changed, which is returned by the draw() function (maybe in combination with clear()).
c) Create your display surface with the FULLSCREEN, DOUBLEBUF and HWSURFACE flags.
But as I already said: make sure you know where your bottle neck is. Some common performance pitfalls are: loading images multiple times from disk, font rendering, using different pixel formats (e.g. not calling convert/convert_alpha on surfaces created from images) and generally the lack of caching.
(also note that python/pygame is generally not the first choice when creating graphically demanding games)
Without seeing your code it will be hard to really see where the bottleneck is. Sloth is correct on his points as a way to optimize. in my experience all images should be pre-processed outside of the main game loop by drawing them onto their own surfaces. Blitting surfaces to surfaces is much faster than blitting images to surfaces.
img_surface = pygame.Surface((img_rect.width, img_rect.height), pygame.SRCALPHA)
img_surface.fill((0, 0, 0, 0))
img_surface.blit(get_image("my_image.png"), img_rect)
This happens outside the game loop. In the game loop you blit the image surface to your surface. If you really want to evaluate you code, use cProfile. This will help you nail down exactly where the bottleneck is. Do as much pre-processing outside the main game loop as possible.
Python getting meaningful results from cProfile
This link really helped me understand cProfile. Sloth is also correct in that pygame is limited, so you are going to need to optimize everything as much as you can. That is where cProfile comes in.
...Also, make sure you are only drawing things that are visible to the user. That can really help improve performance.
So I am making a game with multiple parts using pygame and it has a "drunk" component to it. My goal is to make it so that the more "drunk" the player is, the screen will look more blurry accordingly.
Here is a hack provided for blurring a surface
But that does not work for the whole screen, which is what I need.
How could I go about blurring the entire screen?
How could I go about blurring the entire screen?
When you do pygame.display.set_mode() (or some other function to get the game screen*), what you get back is a Surface.
If you're following the tutorials, you've probably stored it in a variable named screen. Just use that as your surface.
Or you can always just draw to an off-screen surface, transform that, and blit to the screen from the transformed version.
Also, you might want to consider using surfarray; you can probably do a much better blur than just anti-aliased pixelization with about the same amount of code and less CPU work…
* The game screen may be the whole monitor screen, for a full-screen game, or the window, for a windowed game. Either way, if that's the thing you want to blur, that's the Surface you use. If you wanted to blur the entire monitor screen from a windowed game, that wouldn't be possible, because you don't have a handle to that… but from comments, that isn't what you want.
I made a 2D project with a lot of tile sprites, and one player sprite. I'm trying to get the camera to follow the player, and for the most part it's working. However, there's one problem:
If you go to the edge of the map, it scrolls normally, but instead of the black background, it displays copies of the sprites on the edge of the map instead of the background (black). It has the same problem if I leave some squares empty, when I move it displays a copy of the tile that was previously there.
The camera works like this:
Select sprites that should be visible
Do sprite.visible = 1 for them, and sprite.visible = 0 for all other sprites
Set the position sprite.rect of all sprites to coords - offset
Update the screen (I use flip(), because the camera moves every turn, so the whole screen has to be updated every turn)
All DirtySprites have dirty = 2.
Does anyone know why it's displaying copies of the sprites on the edge instead of the background?
Help would be appreciated!
Unless you manually clear your screen surface, flip will not change its content.
Thus, if you neglect to draw to a certain location, it will remain the same.
If you want to get rid of this effect, usually called "hall of mirrors", you will have to keep track of what portions of the screen have not been drawn to yet and draw over these yourself.
It may be easier to define background sprites around your map's contours and block your camera from going off too far.
Since you use a "dirty/clean" approach to only redrawing what's changed, you won't have the option to just fill the whole screen surface before you draw your frame, because that would draw over anything that's stayed the same since the last frame.