RE: [pygame] looking for classic video game clone repository?
Thanks for the link. That wasnt specifically the one I was looking for, but it is similar. But, I actually just found the lost site: http://www.retroremakes.com/. In includes classic arcade and computer games (Choplifter, etc.) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phil Howlett Sent: Wednesday, September 27, 2006 4:19 PM To: pygame-users@seul.org Subject: Re: [pygame] looking for classic video game clone repository? Was it http://www.classic-retro-games.com/ ?? At 06:08 AM 28/09/2006, you wrote: Was wondering if someone could help jog my memory I ran across a web site a few months ago that looked like a searchable catalog of downloadable classic video game clones. All of the classics were represented (Centipede, Dig-Dug, Defender, Rampart, etc.) with multiple clones hobby developers had submitted. This site was noteworthy to me because it looked like a number of submissions were made with pygame (other submissions were made with other languages). But, I cant seem to find that site. Have others heard of this site? What is it called? Could someone post the link? Thanks tons! -Scott
[pygame] looking for classic video game clone repository?
Was wondering if someone could help jog my memory I ran across a web site a few months ago that looked like a searchable catalog of downloadable classic video game clones. All of the classics were represented (Centipede, Dig-Dug, Defender, Rampart, etc.) with multiple clones hobby developers had submitted. This site was noteworthy to me because it looked like a number of submissions were made with pygame (other submissions were made with other languages). But, I cant seem to find that site. Have others heard of this site? What is it called? Could someone post the link? Thanks tons! -Scott
[pygame] 2D vector class
Ok, I learned a lot when I asked the question about Rects and my confusion about their bottom/left overlapping. So, here goes another on 2D vectors... I've got 2 simple games roughed out (about 600 lines each) with about 2000 lines worth of shared modules I've written. I have a somewhat full featured 2D vector class (supports adding, subtracting, scaling, rotation, normalizing, angle between, etc. that I use in both heavily to represent points, velocities, etc. After using it for awhile, I've wondered how others have approached creating a 2D vector class. Here's my philosophical questions, as the class I have works well, but I want to know how to make it better. My main goals are to keep it simple, let it interface cleanly with Pygame's use of tuples of 2 ints for 2D points, not be specifically tied to Pygame, and have it not be a performance hog. So, here's the issues that I'd love to hear feedback on: #1 - Do you store the vector components internally as self.x and self.y or as a tuple? Or subclass the vector class from a tuple? If you use self.x and self.y, what is an efficient way to pass this as a tuple to pygame functions? #2 - Do you store the values as ints (making it easier to pass to Pygame) or floats (more accurate vector math, but need to cast to int before passing to pygame functions that require a tuple of ints?). Or do you not even care and just let duck-typing do it stuff? So, after using my 2D vect class for awhile, I wasn't sure if I had taken the best approach originally. Currently, my vector class stores floats in self.x and self.y and I have 2 methods for returning tuples as follows: def AsTuple(self): return((self.x, self.y)) def AsIntTuple(self): '''Cast values to int. Useful for Pygame''' return((int(self.x), int(self.y))) The other motivation in sending this email out is I'd like to submit a semi-simple particle system module I have to the Cookbook, but it relies on my 2d vector class. So, I wanted to tighten up my vector class and submit both it and the particle system modules. Hopefully, then, other cookbook entries could use this vector class (and improve upon it, please!). Lofty goals? Maybe, but gotta start somewhere, right? Thanks, all for reading this far! -Scott
[pygame] Rects and they handle right and bottom borders
Ok, theory question about Rects... I understand how a rect works, but I'm interested in why it works the way it does to help flesh out my understanding... Originally, I was playing with code that looked something like this: r = pygame.display.get_surface().get_rect() If I would do r.width, I'd get 640. Makes sense since the display is 640 pixels wide. But, r.right returns 640. In my mind, a pixel with an x index of 640 is off the display since the pixels are numbered 0-639. My assumption is that r.right would return the index of the last pixel on the right edge of the rectangle (639). Apparently a wrong assumption. So, then I actually read the docs on Rect a bit closer: The area covered by a Rect does not include the right- and bottom-most edge of pixels. If one Rect's bottom border is another Rect's top border (i.e., rect1.bottom=rect2.top), the two meet exactly on the screen but do not overlap, and rect1.colliderect(rect2) returns false. Ok, that is obviously consistent with my observed results. So, I now understand how it works, but could anyone shed some light as to why it was done this way? Is it to mirror Python's other behaviors, such as range(3) or slicing's [0:3]? Does SDL simply do it this way? Something else? Thanks for indulging me on this hair splitting... -Scott
RE: [pygame] pygame website - request for suggestions
I've noticed a few bugs with the Pygame documentation on the site. I'm far from a pygame-pro so these may be deprecated features or me just misunderstanding things, not knowing where to look, etc., but I've noticed the following: #1 The Scrap topic link doesn't show up in the header on this page: http://www.pygame.org/docs/ But it will appear when you click any of the other topic links in the header (pygame, font, draw, etc.). #2 Googling for certain keywords, I can find the two links below (color constants), but I can't find any way to navigate to these pages from the main documentation link (http://www.pygame.org/docs/) http://www.pygame.org/docs/ref/pygame_color.html http://www.pygame.org/docs/ref/pygame_constants.html #3 There is some potential for odd formatting when a method's documentation contains a link to another method (ex: the docs for pygame.mixer.init refer to pygame.init, pygame.mixer.pre_init and pygame.mixer.quit). It looks like the method that is referred to gets its short description copied into the text with a smaller font after the method name. Good idea, but this can be difficult when reading along. Hard to tell what is plain text and what is the referenced method's short description. Can you put the short description in parenthesis or something to make it clear that the short description isn't meant to be read along with the sentence? Certain browser settings format the short description almost identically to the regular documentation (I usually use Opera and it is difficult to tell at a glance the text is different. IE does a bit better). This makes it even more difficult to differentiate between the two. FWIW, looking at the html source, these references are enclosed in tt tags with the short description getting a font size=-1. Hope that makes sense. Feel free to ask for clarification if necessary... Great site! Keep it up! I'd be lost w/out this site! -Scott Hey, It's been one year since I launched the new pygame website. I hope to have a bit of time during the next month to do some updates to it. So if anyone has: - bug reports - feature requests - etc To suggest, now's the time! If anyone makes a feature request that you think is great, please reply to their message and say so -- the more people want a feature the more likely I'll be to implement it.
