By default, both are allowed. Returns True when the display Surface is considered actively renderable on the screen and may be visible to the user. This is the default state immediately after pygame. This method may return True even if the application is fully hidden behind another application window. This will return False if the display Surface has been iconified or minimized either via pygame.
The method can also return False for other reasons without the application being explicitly iconified or minimized by the user. A notable example being if the user has multiple virtual desktops and the display Surface is not on the active virtual desktop. This function returning True is unrelated to whether the application has input focus.
Please see pygame. Request the window for the display surface be iconified or hidden. Not all systems and displays support an iconified display. The function will return True if successful. When the display is iconified pygame.
Switches the display window between windowed and fullscreen modes. Display driver support is not great when using pygame 1, but with pygame 2 it is the most reliable method to switch to and from fullscreen.
See issue Set the red, green, and blue gamma values on the display hardware. If the green and blue arguments are not passed, they will both be the same as red. Not all systems and hardware support gamma ramps, if the function succeeds it will return True. A gamma value of 1. Lower values will darken the display and higher values will brighten. Set the red, green, and blue gamma ramps with an explicit lookup table.
Each argument should be sequence of integers. The integers should range between 0 and 0xffff. Sets the runtime icon the system will use to represent the display window. All windows default to a simple pygame logo for the window icon. You can pass any surface, but most systems want a smaller image around 32x The image can have colorkey transparency which will be passed to the system.
Some systems do not allow the window icon to change after it has been shown. This function can be called before pygame. If the display has a window title, this function will change the name on the window. Some systems support an alternate shorter title to be used for minimized displays. This will change the video display color palette for 8-bit displays. This does not change the palette for the actual display Surface, only the palette that is used to display the Surface.
If no palette argument is passed, the system default palette will be restored. The palette is a sequence of RGB triplets. Returns the number of available displays. This is always 1 if pygame. Returns the size of the window initialized with pygame. Return whether screensaver is allowed to run whilst the app is running. Default is False. By default pygame does not allow the screensaver during game play.
Some platforms do not have a screensaver or support disabling the screensaver. Change whether screensavers should be allowed whilst the app is running. The default is False. If the screensaver has been disallowed due to this function, it will automatically be allowed to run when pygame. Disabling screensaver is subject to platform support. When platform support is absent, this function will silently appear to work even though the screensaver state is unchanged.
The lack of feedback is due to SDL not providing any supported method for determining whether it supports changing the screensaver state. Initialize the display module. Windows : windib , directx Unix : x11 , dga , fbcon , directfb , ggi , vgl , svgalib , aalib. Uninitialize the display module. Returns True if the display module has been initialized.
Initialize a window or screen for display. SHOWN window is opened in visible mode default pygame. Get a reference to the currently set display surface. Update the full display Surface to the screen. Update portions of the screen for software displays. Get the name of the pygame display backend. Create a video display information object. They are - 1 on error , or if an old SDL is being used. Get information about the current windowing system.
Get sizes of active desktops. Get list of available fullscreen modes. Pick the best color depth for a display mode. Get the value for an OpenGL flag for the current display.
Request an OpenGL display attribute for the display mode. Whether to enable multisampling anti-aliasing. Defaults to 0 disabled. Returns True when the display is active on the screen.
Note This function returning True is unrelated to whether the application has input focus. Learn more. Difference between pygame. Asked 6 years, 9 months ago. Active 5 months ago. Viewed 49k times. Improve this question. Danis 2 2 silver badges 12 12 bronze badges. Yubin Lee Yubin Lee 2 2 gold badges 7 7 silver badges 26 26 bronze badges. Add a comment. Active Oldest Votes. Passing no arguments, updates the entire display To tell PyGame which portions of the screen it should update i.
Improve this answer. Andreas detests censorship 1, 2 2 gold badges 17 17 silver badges 33 33 bronze badges. I wonder why they didn't just make it update with optional arguments. So if I have more than 1 surface object, update will be faster than flip? Imagine you have an image and you blit it. Instead of updating the whole screen, if you update the surface corresponding to the image, it will be faster if the image is smaller than the screen.
Manan Patel Manan Patel 1. With only a single buffer either will work, and single buffering is what you are using unless you specifically create a double buffered window, such as this: pygame.
There are two cases where this technique just won't work. The first is where the whole window or screen really is being updated every frame -- think of a smooth-scrolling engine like an overhead real-time strategy game or a side-scroller. So what do you do in this case?
Well, the short answer is -- don't write this kind of game in pygame. The long answer is to scroll in steps of several pixels at a time; don't try to make scrolling perfectly smooth. Your player will appreciate a game that scrolls quickly, and won't notice the background jumping along too much.
A final note -- not every game requires high framerates. A strategic wargame could easily get by on just a few updates per second -- in this case, the added complexity of dirty rect animation may not be necessary. If you've been looking at the various flags you can use with pygame. Well, I want that -- who doesn't like hardware acceleration. It's not your fault; we've been trained by years of 3-d gaming to believe that hardware acceleration is good, and software rendering is slow.
It only works on some platforms. Windows machines can usually get hardware surfaces if you ask for them. Most other platforms can't. Linux, for example, may be able to provide a hardware surface if X4 is installed, if DGA2 is working properly, and if the moons are aligned correctly.
If a hardware surface is unavailable, SDL will silently give you a software surface instead. It complicates per-pixel access. If you have a hardware surface, you need to Lock the surface before writing or reading individual pixel values on it. If you don't, Bad Things Happen. Then you need to quickly Unlock the surface again, before the OS gets all confused and starts to panic.
Most of this process is automated for you in pygame, but it's something else to take into account. You lose the mouse pointer. You'll need to create a sprite to act as a manual mouse pointer, and you'll need to worry about pointer acceleration and sensitivity. What a pain. It might be slower anyway. Many drivers are not accelerated for the types of drawing that we do, and since everything has to be blitted across the video bus unless you can cram your source surface into video memory as well , it might end up being slower than software access anyway.
Hardware rendering has it's place. It works pretty reliably under Windows, so if you're not interested in cross-platform performance, it may provide you with a substantial speed increase.
However, it comes at a cost -- increased headaches and complexity. Sometimes, new game programmers spend too much time worrying about issues that aren't really critical to their game's success.
The desire to get secondary issues 'right' is understandable, but early in the process of creating a game, you cannot even know what the important questions are, let alone what answers you should choose.
The result can be a lot of needless prevarication. For example, consider the question of how to organize your graphics files. Should each frame have its own graphics file, or each sprite? Perhaps all the graphics should be zipped up into one archive? A great deal of time has been wasted on a lot of projects, asking these questions on mailing lists, debating the answers, profiling, etc, etc. This is a secondary issue; any time spent discussing it should have been spent coding the actual game.
The insight here is that it is far better to have a 'pretty good' solution that was actually implemented, than a perfect solution that you never got around to writing. Pete Shinners' wrapper may have cool alpha effects and fast blitting speeds, but I have to admit my favorite part of pygame is the lowly Rect class.
A rect is simply a rectangle -- defined only by the position of its top left corner, its width, and its height. Many pygame functions take rects as arguments, and they also take 'rectstyles', a sequence that has the same values as a rect. So if I need a rectangle that defines the area between 10, 20 and 40, 50, I can do any of the following:. If you use any of the first three versions, however, you get access to Rect's utility functions.
These include functions to move, shrink and inflate rects, find the union of two rects, and a variety of collision-detection functions. For example, suppose I'd like to get a list of all the sprites that contain a point x, y -- maybe the player clicked there, or maybe that's the current location of a bullet. It's simple if each sprite has a. Rects have no other relation to surfaces or graphics functions, other than the fact that you can use them as arguments.
You can also use them in places that have nothing to do with graphics, but still need to be defined as rectangles. Every project I discover a few new places to use rects where I never thought I'd need them. So you've got your sprites moving around, and you need to know whether or not they're bumping into one another.
It's tempting to write something like the following:. For each pixel in the overlapping area, see if the corresponding pixels from both sprites are opaque. If so, there's a collision. There are other ways to do this, with ANDing sprite masks and so on, but any way you do it in pygame, it's probably going to be too slow. For most games, it's probably better just to do 'sub-rect collision' -- create a rect for each sprite that's a little smaller than the actual image, and use that for collisions instead.
It will be much faster, and in most cases the player won't notice the imprecision. Pygame's event system is kind of tricky. There are actually two different ways to find out what an input device keyboard, mouse or joystick is doing.
0コメント