Re: [pygame] New on the mailing list with a strange FPS behavior
Ghislain Leveque wrote: 2007/11/12, claxo [EMAIL PROTECTED]: On 11 Nov 2007 at 22:41, Ghislain Leveque wrote: Today I've come into a strange behavior with my rendering loop. 3. Memory garbage collection kicks in. you can try to do a explicit garbage collection after each M frames to see if max time is reduced. How do I do an explicite garbage collection ? Normal collection is run continuously (reference counting). The periodic part is just for cycle detection. Don't have reference loops. --Noah signature.asc Description: OpenPGP digital signature
Re: [pygame] New on the mailing list with a strange FPS behavior
Look at the module gc in the global module index of Python docs, but in a pinch: import gc ... gc.collect( ) Don't put into a tight loop, this waste cpu time. claxo On 12 Nov 2007 at 8:30, Ghislain Leveque wrote: 2007/11/12, claxo [EMAIL PROTECTED]: On 11 Nov 2007 at 22:41, Ghislain Leveque wrote: Today I've come into a strange behavior with my rendering loop. 3. Memory garbage collection kicks in. you can try to do a explicit garbage collection after each M frames to see if max time is reduced. How do I do an explicite garbage collection ? Thanks -- Ghislain Lévêque
Re: [pygame] New on the mailing list with a strange FPS behavior
I seems to remember time.time() is prefered to calculate delta times? Anybody ? On 12 Nov 2007 at 8:29, Ghislain Leveque wrote: First I will explain how I did measure and what make me think it's the draw that stucks : ... def post(self,event): for listener in self.listeners: now = pygame.time.get_ticks() listener.notify(event) self.stats[listener].append((pygame.time.get_ticks() - now,event)) Ghislain Lévêque
Re: [pygame] New on the mailing list with a strange FPS behavior
On Nov 12, 2007 4:29 PM, Ghislain Leveque [EMAIL PROTECTED] wrote: And I can see the freezing. Put a time.sleep(0) call in your inner loop. The problem will likely go away. -- :: Simon Wittber :: http://www.linkedin.com/in/simonwittber :: phone: +61.4.0135.0685 :: jabber/msn: [EMAIL PROTECTED]
Re: [pygame] ANN: pyglet 1.0beta1
Hmmn... That sounds like an excellent default behavior. However there are a good are good reasons for wanting to change the screen resolution: - The game is pixel art based and only looks right at 640x480 - The game uses a lot of high-powered features and the game wishes to give the end user the option to play the game at a lower resolution if their GPU isn't up to handling it at 1600x1200 or whatever their desktop is set at Anyway - I'm excited to see it's reached beta. I will give it a try one of these days :) Thanks! Phil Casey Duncan [EMAIL PROTECTED] wrote: On Nov 9, 2007, at 2:58 PM, Dave LeCompte (really) wrote: Richard Jones wrote: On Sat, 10 Nov 2007, Brian Fisher wrote: Does pyglet let the developer get full-screen mode in the resolution of their choice, or are they still restricted to having full-screen resolution be the same as the users desktop resolution? You get the desktop resolution. You can alter the default OpenGL projection to display a different resolution. It's certainly true that you can change the projection, but that doesn't change the screen resolution - Pyglet philosophically chooses not to allow the programmer (or user) the option to change the screen resolution. Some arguments for this include: - some users have LCD screens that have a single acceptable resolution - some OSes behave strangely if a single monitor of a multiple monitor setup changes its resolution - sometimes exiting uncleanly leaves a monitor in an incorrect state That's all well and good, but it seems pretty presumptuous for a purported library to make policy decisions like that. One of my first rules about libraries is that they stay out of the way as much as possible. In my experience very few commercial games leave the resolution alone in fullscreen mode and modern LCD displays seem to have little trouble dealing with multiple resolutions acceptably. Oh well, that's probably a deal breaker for me for game development. -Casey __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [pygame] I\'m getting BSOD while using PyGame.
I snipped out a bunch of your code fixes from this reply, except where I didn't understand them. The code was \x = ones( ( 3, 4 ) )\ Not enought context to tell wat was going . What is \'ones\' ? That was a function from PyNum module, following the tutorial. It's supposed to initialize a 3x4 matrix/array with the value '1'. But removing PyNum lib didn't stop the BSOD ( and sometimes just a full freeze, no BSOD, but nothing responds, requiring a reboot ) I tested the exact same code that causes a crash on another computer. As far as I can tell, they both have the exact version of Python and PyGame installed. The 2nd computer does not crash at all. I'm using default values for my surfaces ( meaning they are software, no hardware accel, no OpenGL ). Just regular blit's. I am able to get the same program written in c++ using libSDL to work on both computers, with no crashing. The one that it does crash, sometimes crashes playing other games, but it's not very frequent. And if they crash, it is rarely a BSOD. ( And those games even use 3D accel, ie: teamfortress 2 ) I have updated to my latest video driver, and have been trying newer BIOS drivers. This is the only game that has a 100% BSOD rate ( on one computer, but not the other. ) # ... code ... # blit it self.screen.blit( self.tileset, dest_rect, src_rec ) seems ok, if self.tileset is initialized to a pygame surface anywhere Yes. It is also blitting correctly. Sometimes for multiple seconds before a crash, at many renders a second. def __init__(self, cols, rows): \\\Initialize array size [cols][rows]\\\ self.resize(cols, rows) def resize(self, cols, rows): \\\resize array, works same way as constructor arguments\\\ # populate: None\'s self.__rows = rows self.__cols = cols self.__data = [ [None for row in range(rows)] for col in range(cols) ] Why the names begins with \'__\' ? Usually its only used to hide members. To the readers convey the sense \'We play tricks with this members, dont touch\' I'm new to python, I think prefixing a variable with __ declares it as a private member. I did that so __rows, __cols, wouldn't be accidently modified. I now know from your snippet below that I can remove them all together, and use a len() call instead. def get(self, x, y): \\\get the value at the offset for now, if invalid bounds, then return None\\\ if self.validIndex( x, y ): return self.__data[x][y] return None # maybe throw exception? Haven\'t learned about them yet. def set(self, x, y, value): \\\set the value at the offset for now, if invalid bounds, then return None\\\ if self.validIndex( x, y ): self.__data[x][y] = value # todo: else throw exception / error but doesn\'t need to halt program. Returns None any time I don't understand what you mean? In a stand alone test and in the game the .get() and set() are returning the value, except if the index is out of bounds. -- Jake
Re: [pygame] I'm getting BSOD while using PyGame.
The source is at: http://www.newmech.com/pics/ZombieHunt_v0.2-BSOD.zip If you want more feedback, post more code ( from the non numeric version, to keep it easy) Cheers claxo I attached the source of the version that always crashes on one computer, but never on the other. ( So maybe it's a driver issue? But I can get SDL on this computer working fine if I use c++ ( + libSDL ). And most games run fine. ( They sometimes crash, but they don't do a BSOD, they do a regular segfault/crash that the system stays intact. I've also been updating my graphics and bios drivers incase, but that didn't help. ) If there's something wrong with the way i'm init-ing video, or blitting, that could be the problem, I would think it's in ZombieHunt.py or Map.py. The other files don't do much, and I've used those 3 in other programs. ZombieHunt.py : initializes video, main game loop. Map.py : stores Array2D() of the map, and blits tiles. ( using static tile ID to rule out the .get() function causing problems ) fps.py : renders FPS to screen. Helpers.py : only has the load_image() function from the official tutorial Array2D.py : haven't updated with your changes yet, but it works. On Nov 10, 2007 8:34 PM, claxo [EMAIL PROTECTED] wrote: On 10 Nov 2007 at 15:30, Jake b wrote: I've started on a very basic game, right now all it does is blit tiles to the screen. I used a NumPy tutorial to create a 2D array to store tileID's for rendering. But running it, caused my computer to get a Blue Screen Of Death. The code was x = ones( ( 3, 4 ) ) I was surprised because I was running my game in windowed mode, if I called blit() witih an invalid value, or accessed an array out of bounds, I thought it would at worst crash to desktop. I have also tried the game Snowballz, ( it uses PyGame ) So my first guess was that it was NumPy that did it. I removed NumPy, creating my own basic 2D array class that seems to be working correctly stand-alone. I started to place it into my tile code, and I got the BSOD again. Now I know it's not NumPy. The wierd thing is even when it crashes, it seems to render the tileset at least once. Sometimes it had been running for a few seconds ( at 60 renders per second ), but once it was the very first render that crashed. A BSOD is strange. Checking basics: Are you sure your alternative code has loaded ? I mean, if you run from the cmd prompt, by example c:\python24\python.exe myprog.py all modules are reloaded, but if you are runing from inside an IDE maybe you need to restart the IDE. Make sure the dir and files have standart attribs, ie no ReadOnly , no Hide, etc. I remember a time when editing in IDE and running from command line ,when IDLE writes the sources but the interpreter keeps loading the prev compiled module. Really weird. No warning messages. Just in case try deleting the .pyc before run the alternate (non Numpy) code. I'm using SciTE, and running from a console. To check I wrote a script to delete all of the *.pyc files, then run c:\python25\python.exe It didn't fix anything. None of the files are readonly, system, hidden, etc. -- Jake
Re: [pygame] I'm getting BSOD while using PyGame.
On Nov 10, 2007 10:36 PM, Brian Fisher [EMAIL PROTECTED] wrote: On Nov 10, 2007 1:30 PM, Jake b [EMAIL PROTECTED] wrote: for rendering. But running it, caused my computer to get a Blue Screen Of Death. Blue Screen of Death on Windows XP means an error in kernel mode, always, no exception. No pygame or python module ships a driver or kernel mode component that I'm aware of. What this means is that the only way running a particular python + pygame project could cause a blue screen is by it making a call that makes a driver go do something, and it's the driver that crashes. For a game, this almost always means the video card driver - some other options would be sound card driver, virus protection program, bad memory, network driver. It's almost definitely video card, but if you look at the blue screen I just replied to claxo, and I elaborated on this. I've updated my BIOS and video driver and they didn't help. Or, instead of getting BSOD's i'm now getting a crash where nothing responds. ( Not a 100% cpu usage ) but keyboard, mouse, windowmanager, everything doesn't respond. Sometimes it even does wierd graphical artifacts, and even can on crash generate sounds when I was using no sound. I have the same AVG ( grisoft ) on both computers, the one that the game crashes, and the one that it doesn't. I can get an equivalent c++ program to blit tiles using libSDL to work fine on both computers. That's why I'm wondering could it have anything to do with a certain version of PyGame + Python? I have Python: 2.5.1, and PyGame: pygame-1.7.1release.win32-py2.5.exe before rebooting, you can often find the name of the driver that is faulting and then be sure about which component it is (look for drivername.sys near the top after The problem seems to be caused by the following file or on the very last line after a few asterixes) In the past I have seen where it says driver nv.dll or a specific message, but the BSOD's I was getting from this game would only say Stop: 0x0 ( I don't remember the exact hex offset, but thats the only info it gave. No driver listings, no event name ( like DIVIDE_BY_ZERO ) ), just Stop. Now it's not always getting a BSOD, but it is still completely freezing like a BSOD 100% of the time. I see my desktop but the only option is hitting the power. As far as what pygame thing could be triggering the driver to crash - are you making your surfaces with the HWSURFACE flag? Are you using OpenGL? If so, try not using either of those, it might turn into a I'm using the default arguments, I'm not passing any flags to the surface creation, so its a software surface. I am not using any OpenGL. segfault or a normal error. Are you playing music or sounds? Turn that off and test. Also, it's possible pygame stuff is only triggering I'm not using any sounds in the game I wrote. It did crash once with winamp playing, so after that I quit winamp on the next reboot, and it still crashes. ( Sometimes creating sounds at the crash ) things by being a busy and active game. If the problem is heat or bad memory related, desktop use may never trigger it. Because of the 'nice cpu boolean' It uses almost nothing, like 2% CPU usage. I don't think it can be heat since this was from a fresh start, after it had been off for hours. ( While it has no problem playing full 3D accelerated games ) Do other games give a Blue Screen? No. I sometimes get crashes in other games, but they crash to desktop, nothing is broken. I can re-run the game and everythings fine. That's the confusing part, libSDL with c++ works, much higher hardware accelerated games work, but a simple blit isn't working, and a full system crash at that. Thanks ( to everyone ) for the help -- Jake
Re: [pygame] ANN: pyglet 1.0beta1
On 11/13/07, Phil Hassey [EMAIL PROTECTED] wrote: - The game is pixel art based and only looks right at 640x480 OpenGL provides many ways to scale a 640x480 viewport up to a higher resolution, with or without aliasing (I suspect in this use-case you'd prefer the aliasing). - The game uses a lot of high-powered features and the game wishes to give the end user the option to play the game at a lower resolution if their GPU isn't up to handling it at 1600x1200 or whatever their desktop is set at It will be a happy day when a Python application is fill-limited, and not CPU bound! pyglet provides excellent windowing support, including full mouse and keyboard exclusivity... a game with fixed resolution smaller than the display will happily run inside a window. Alex.
Re: [pygame] I'm getting BSOD while using PyGame.
Try to shortcut all the fps - cpu caping in your code, see if it crash or freezes. Its seems to me that that all the restrictions are fighting. If doenst crash, we know the problem is in the caping. claxo On 12 Nov 2007 at 14:02, Jake b wrote: The source is at: http://www.newmech.com/pics/ZombieHunt_v0.2-BSOD.zip If you want more feedback, post more code ( from the non numeric version, to keep it easy) Cheers claxo
Re: [pygame] ANN: pyglet 1.0beta1
On Nov 12, 2007 1:24 PM, Alex Holkner [EMAIL PROTECTED] wrote: OpenGL provides many ways to scale a 640x480 viewport up to a higher resolution, with or without aliasing (I suspect in this use-case you'd prefer the aliasing). there's no way to get 640x480 pixel art to look right on a 1024x768 desktop unless you want to blackbox and draw at 62.5% scale. There may be a lot of 3d apps where resolution doesn't matter, but the bluriness of scaling 1.65 does kill small text and make crisp sharp lines look bad, and it makes pixel art distorted. It will be a happy day when a Python application is fill-limited, and not CPU bound! Congratulations Alex! Today is a happy day then! I do motion blur in my engine. My python games in development that use it are definitely fill-limited. Also, I want to target a wide range of computers, including my 5 year old laptop. On that machine, I need to turn off my motion blur, and still on those computers I only get 30fps with most of the time is in the draw + flip (a lot is in the flip meaning my game is waiting for GL to finish off it's command buffers) If I ended up scaling up the 800x600 game to the 1280x1024 desktop in fullscreen, it would take like 2.25 times as long to draw, and I would only get like 12fps, and dip into the unplayable range. Basically I respect not wanting to mess with people's desktops, but I think fullscreen with changed resolution is a far too powerful thing in terms of delivering a great game experience to not at least try to do it well try to solve the problems as best you can - I happen to think it works very well on pygame with an openGL display. The fact that currently it will never be an option in pyglet is a huge turn off to what otherwise seems a superior library. pyglet provides excellent windowing support, including full mouse and keyboard exclusivity... a game with fixed resolution smaller than the display will happily run inside a window. That sounds great - I'm sure it handles multi-monitor stuff beautifully as well - I think it's great that you made multi-monitor and multi-window part of the core feature set
Re: Re: [pygame] ANN: pyglet 1.0beta1
Stretched pixels, though. I
Re: Re: Re: [pygame] ANN: pyglet 1.0beta1
Ian Mallett [EMAIL PROTECTED] wrote: Stretched pixels, though. If you want your pixels to be square you can alter the glViewport. Richard
Re: Re: Re: [pygame] ANN: pyglet 1.0beta1
On Nov 12, 2007 3:35 PM, Richard Jones [EMAIL PROTECTED] wrote: Ian Mallett [EMAIL PROTECTED] wrote: Stretched pixels, though. If you want your pixels to be square you can alter the glViewport. I meant like larger ones.
Re: Re: [pygame] ANN: pyglet 1.0beta1
Brian Fisher [EMAIL PROTECTED] wrote: On Nov 12, 2007 1:24 PM, Alex Holkner [EMAIL PROTECTED] wrote: OpenGL provides many ways to scale a 640x480 viewport up to a higher resolution, with or without aliasing (I suspect in this use-case you'd prefer the aliasing). there's no way to get 640x480 pixel art to look right on a 1024x768 desktop unless you want to blackbox and draw at 62.5% scale. There may be a lot of 3d apps where resolution doesn't matter, but the bluriness of scaling 1.65 does kill small text and make crisp sharp lines look bad, and it makes pixel art distorted. With aliasing (GL_NEAREST texture env) the display will look exactly the same as if it was scaled by the monitor. No blurriness. Richard
Re: Re: [pygame] ANN: pyglet 1.0beta1
On Nov 12, 2007 3:29 PM, Richard Jones [EMAIL PROTECTED] wrote: be a lot of 3d apps where resolution doesn't matter, but the bluriness of scaling 1.65 does kill small text and make crisp sharp lines look bad, and it makes pixel art distorted. With aliasing (GL_NEAREST texture env) the display will look exactly the same as if it was scaled by the monitor. No blurriness. Fine, you can trade bluriness for having some of your source pixels be twice as long or as high as others. Nice to know you can pick in what way it looks bad, but I don't see how a nearest neighbor scale of 1.65:1 will look good in any meaningful way (i.e. I perfer the bluriness). ...and every monitor I have scales/stretches much better than my openGL drivers do - CRT's stretch and scale nearly perfectly so I assume you must just be thinking of LCD's, but my laptop and HDTV are better than the bilinear filter of my video cards.
Re: Re: [pygame] ANN: pyglet 1.0beta1
Richard Jones [EMAIL PROTECTED] said: With aliasing (GL_NEAREST texture env) the display will look exactly the same as if it was scaled by the monitor. No blurriness. If your rendering window is an exact multiple of the target resolution, sure - a 1280x960 window can provide the same visuals as a 640x480 display, at only a 4x fill rate hit. For 1280x1024 displays, though (which are somewhat more common), some of the source pixels will stretch out onto two display pixels, where some other source pixels stretch out onto three. -Dave LeCompte
Re: Re: Re: [pygame] ANN: pyglet 1.0beta1
Brian Fisher [EMAIL PROTECTED] wrote: On Nov 12, 2007 3:29 PM, Richard Jones [EMAIL PROTECTED] wrote: be a lot of 3d apps where resolution doesn't matter, but the bluriness of scaling 1.65 does kill small text and make crisp sharp lines look bad, and it makes pixel art distorted. With aliasing (GL_NEAREST texture env) the display will look exactly the same as if it was scaled by the monitor. No blurriness. Fine, you can trade bluriness for having some of your source pixels be twice as long or as high as others. Nice to know you can pick in what way it looks bad, but I don't see how a nearest neighbor scale of 1.65:1 will look good in any meaningful way (i.e. I perfer the bluriness). As I mentioned in my response to Ian if you want to scale while retaining aspect ratio you just alter the glViewport. Monitors rarely offer this option. I know my old CRT and 6-month-old LCD don't. I can ask the nvidia drivers to perform scaling up to the monitor resolution for me in software while retaining aspect ratio... ...and every monitor I have scales/stretches much better than my openGL drivers do - CRT's stretch and scale nearly perfectly so I assume you must just be thinking of LCD's, but my laptop and HDTV are better than the bilinear filter of my video cards. You are thinking of GL_LINEAR (commonly known as bilinear) scaling, not GL_NEAREST. Richard
Re: Re: Re: [pygame] ANN: pyglet 1.0beta1
Much as I like all the pyglet discussion, this is getting really off-topic from PyGame... I've created this page which summarises the issue in pyglet and the various options available to developers: http://groups.google.com/group/pyglet-users/web/issues-with-full-screen-resolution Cheers Alex.
[pygame] How to manage image source Rect()'s for units
I planned on having one image which had all the frames of the unit's animation. Then based on its direction / or state, I would modify the source rect's before blit. I tried using a pygame.sprite.RenderPlain(), but I couldn't make it use a source rect. What's the best way to handle this? Can I use a sprite Group with source rects? Maybe subclass .RenderPlain() ? I looked for the .RenderPlain() implementation: I searched the c:\python25 directory for files named *.py* containing RenderPlain, but it came up with nothing. -- Jake
