Re: [pygame] On the Posting of Projects
On 12/11/07, Patrick Mullen <[EMAIL PROTECTED]> wrote: > Good advice, however I feel that the people who would most benefit > from it may not be listening here. I'm afraid you're probably right. > On an unrelated website note, I would like to be able to remain logged > in to the web site. It didn't used to be a problem when I would only > log in every month or so, but lately I have wanted to comment more > often. Could this be added Phil Hassey? Maybe releases without a screenshot shouldn't show the "NO SCREENSHOT" screenshot. Seems silly. Ian
[pygame] help with subsurfaces
- new to pygame/python - have a .png that contains all player avatars - trying to load only a one avatar from that image based on a known size and position Question: What is best way to get a portion of an larger image and display it on the screen. Do I use subsurfaces, or blit, or what is best way? Thanks, Greg
Re: [pygame] help with subsurfaces
On Dec 12, 2007 1:10 PM, Dan Krol <[EMAIL PROTECTED]> wrote: > I need to do something similar, but I think I did it by just blitting > the subsection of the original surface I needed when it's time to draw > (and no other times). Doesn't this not use extra memory as well? Any > reason this is a bad idea? > For organizational purposes, it may at some point be very unclear what this means: screen.blit(source.subsurface([30,60,100,15]),[30,60]) Whereas this might make more sense: screen.blit(player_head,[30,60]) Also, the little bit of memory used in predefining a subsurface is going to gain some performance increase, which in blitting you really need as much as you can get. Also, if you are meaning you do things thusly: screen.blit(source,[30,60],[30,60,100,15]) this probably is as fast and as memory concious, but to me is even more confusing because the area defined belongs to the source but comes AFTER the coordinates. I would forget what that rect is associated with. But if it works for you, then do it that way :)
Re: [pygame] help with subsurfaces
On Dec 12, 2007 12:37 PM, Greg <[EMAIL PROTECTED]> wrote:
> - new to pygame/python
> - have a .png that contains all player avatars
> - trying to load only a one avatar from that image based on a known size
> and position
>
> Question: What is best way to get a portion of an larger image and
> display it on the screen. Do I use subsurfaces, or blit, or what is best
> way? Thanks,
>
> Greg
>
Using a subsurface is the best way, as it shares pixel data so doesn't
use as much memory as creating another surface would. If you plan on
modifying the pixels, now or at a later time, and don't want those
modifications to be stored on the avatar sheet surface, you can always
make a copy of the subsurface.
base = pygame.image.load("base.png")
avatar1 = base.subsurface(known_rect)
Then display avatar1 as you usually would display a surface, with
screen.blit(avatar1).
Also, if you use a colorkey, you can set the colorkey on the base and
not worry about it for the subsurfaces.
Re: [pygame] help with subsurfaces
I need to do something similar, but I think I did it by just blitting the subsection of the original surface I needed when it's time to draw (and no other times). Doesn't this not use extra memory as well? Any reason this is a bad idea?
Re: [pygame] On the Posting of Projects
Ian Mallett wrote: There have recently been several releases on pygame.org by several users that have little description, no screenshots, no download links, etc. That makes no sense. What's the point of listing your project if there's no way for anyone to get it? I'd regard these as spam and get rid of them. -- Greg
Re: [pygame] On the Posting of Projects
On, Wed Dec 12, 2007, Patrick Mullen wrote: > Good advice, however I feel that the people who would most benefit > from it may not be listening here. Also, even though it's linked on > the front page, I always seem to forget about the cookbook. Thanks > for the reminder. The next time I do something I feel is > clever/useful, maybe I'll put it there, since an actual distributable > project is so rare! > > I would also like to add that people who have nothing yet to show of > their project has no business posting. It's called a release, maybe > if there were a pre-release section it would be different. If you cry > wolf by "announcing" a release, people may skip over the next release > which actually has something to say. > > Are there any moderator abilities to go through and remove some of the > spam? Possibly with a warning first? It seems that you haven't read the news on pygame.org. I ran a small cleanup a few weeks ago, removing gazillons of dead or incomplete projects, which were silent for several months. I do not see any new projects besides one (zak) at the moment, which are empty. If you have seen one, feel free to tell me and I'll put it on my list for the cleanup session. Regards Marcus pgpaR44UMHUy4.pgp Description: PGP signature
Re: [pygame] Mac OS X 10.5, Leopard Support
I was wondering about all the Leopard support questions recently, wouldn't the python 2.4 packages here: http://pythonmac.org/packages/py24-fat/index.html all work on leopard? I know it's not python 2.5, and not the system python, but it shouldn't have any of the pyobjc problems (cause of the pyObjc 1.4 package on the site above) On Dec 10, 2007 4:11 AM, Olle Olsson <[EMAIL PROTECTED]> wrote: > > Hello. > > What's the statup of PyGame for Leopard? > > Compiling with Macports or Fink doesn't work due to the dependancy on PyObjC. > > PyObjC got re-written for Leopard and is now v2.0. It is included with the OS > version > of Python (v1.4 simply won't compile under Leopard). The OS Python version > ofcourse > lacks other stuff that pygame needs like numeric and SDL. > > One strange detail is that PyObjC's sourceforge page hasn't been updated to > reflect the > v2.0 re-write. Maybe that's why the fink people can't the pygame build work > for leopard. > > Anyways, if any of you guys got pygame running under leopard, please tell how. > > If you know anything that might help on the matter, please also tell :) > > _ > Spara, redigera och organisera dina foton enkelt med Photo Gallery! > http://get.live.com/photogallery/overview
Re: [pygame] Mac OS X 10.5, Leopard Support
On Dec 12, 2007 8:39 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: > I was wondering about all the Leopard support questions recently, > wouldn't the python 2.4 packages here: > http://pythonmac.org/packages/py24-fat/index.html > all work on leopard? Not in the case of PyObjC. The PyObjC people very bluntly told me that PyObjC isn't for Leopard, period. I really don't know much more than that. I'm going to go ahead and take myself off this list. Thanks for any help and hints people have given me over the years. It appears that pygame-on-leopard is not a priority, and I've converted all my active projects to use pyglet (which I really like), and I'm having fun learning OpenGL as a side-benefit of that switch. Later! ~ Nathan
Re: [pygame] help with subsurfaces
Patrick Mullen wrote: On Dec 12, 2007 1:10 PM, Dan Krol <[EMAIL PROTECTED]> wrote: I need to do something similar, but I think I did it by just blitting the subsection of the original surface I needed when it's time to draw (and no other times). Doesn't this not use extra memory as well? Any reason this is a bad idea? screen.blit(source,[30,60],[30,60,100,15]) this probably is as fast and as memory concious, but to me is even more confusing because the area defined belongs to the source but comes AFTER the coordinates. I would forget what that rect is associated with. What I had been doing was similar to this way. I loaded one big image containing all animation frames for a character, then defined a bunch of Rects marking each animation frame, taking into account that a source image might have "padding" around the edges or between frames. The key part of code is below. The full code is in the "nixie" module that should be in the "Shining Sea Source" ZIP at . """Define a set of rectangles (Rects) representing chunks of the sprite sheet for different animation frames. Once this is done, you can say "switch to frame 4" and know that it's, say, "jump." """ self.animation_frames = [] for row in range(self.frames_how_many_rows): y1 = (row * self.framesize[1]) + (row * self.frames_padding) + self.frames_outer_padding height = self.framesize[1] for frame in range(self.frames_per_row): x1 = (frame * self.framesize[0]) + (frame * self.frames_padding) + self.frames_outer_padding width = self.framesize[0] ## Drum_Roll() self.animation_frames.append( pygame.rect.Rect(x1,y1,width,height) ) self.highest_animation_frame = len(self.animation_frames) - 1
