Re: [pygame] C/C++ and Python
On Wed, Apr 22, 2009 at 4:39 AM, Knapp magick.c...@gmail.com wrote: On Wed, Apr 22, 2009 at 8:23 AM, René Dudfield ren...@gmail.com wrote:and have less errors in the end. I wish I did not have to type self so much in python!!! C++ is much better this way Using an editor like Geany, you type s then TAB, it inserts self. -- Jake
Re: [pygame] PyGame Website Rewrite
Hi, very detailed emails from Marcus and Nicholas... a few related points below. I'd be interested in knowing what jug, and orcun think of using Django? Also what they think of a cherrypy based stack? Also, what are the preferences of Lenard, Devon, pymike, and anyone else who is interested in contributing? Please state the level of commitment you're willing to make, and also which option(s) you'd be happy using. - The main author of cherrypy(Robert Brewer) said he'd help us with any major issues we had, and so did some other cherrypy mailing list people. The cherrypy mailing list is also more active than the pygame one, so I'm sure we won't have any issues with docs or help. - documentation is extensive for cherrypy(it's a 10 year old project, in it's third generation). - we would have to choose a stack. The stack Nicholas mentioned seems pretty common, cherrypy + sqlalchemy + genshi + formencode/formalchemy + pygame of course for imaging... and joysick control of the website. So that is the stack we would be chosing. - cherrypy code seems cleaner... as it's just python objects. class MySite(object): def index(self): return hello world! def news(self, id=None): if id is None: return main_news() else: return specific_news(id) index.exposed = True news.exposed = True This creates these urls by default: / /index /news /news/10 /news?id=10 - cherrypy has less code compared to django, and is changing less. - django is usually run using apache modpython or mod_wsgi, or even with cherrypy(or other wsgi server). They don't recommend using the bundled django webserver. Whereas cherrypy is considered one of, if not the best python web servers. With cherrypy you use the same webserver for development, and for production. - you can run cherrypy inside a pygame application. Cherrypy doesn't control the main loop if you don't want it to. - there are more wsgi components than there are pinax apps. Also pinax apps should theoretically be able to play with wsgi. I'm pretty sure you can use django apps as wsgi components now too. On Sat, Apr 25, 2009 at 3:51 PM, Nicholas Dudfield ndudfi...@gmail.comwrote: I do not know anything about cherrypy, so here're some relevant questions for both frameworks: * How good is the integration of a wiki solution and maybe bug tracking system without implementing it ourselves? * How good is the integration of other components, which might be necessary in the future? * How much effort has to be put into it to add new features? Is it just about adding/enabling a component or writing a whole bunch of code? * What is the key difference between cherrypy (denoted as HTTP framework) and Django (web framework)? I have a little bit of experience with CherryPy and a tiny tiny bit of experience with Django. Here is my 2.0 cents. A while back I read a considerable amount about python frameworks before choosing CherryPy I say I chose CherryPy but that wasn't really the case. That choice was made for me. I did however choose further components to extend CherryPy with after becoming frustrated with `raw` CherryPy and a `raw` DB2 api. Making pages by concatenating strings is horrible and very resistant to change. You really want a templating system of some sort where you can integrate designers changes nicely or have them do it themselves (concurrently) You also want to be able to apply any special features your editor has for editing html. Even PHP is better in this respect than `raw` CherryPy for anything beyond a `Hello World` toy site. Enter overwhelming array of choices. Then you have to find a way of integrating the templating system with CherryPy. You'll find you want an ORM/query builder soon enough as writing your own (again using string building, you just want a small simple one) proves to be distracting. Any time you want a feature requiring something beyond your home- baked lib you have to code something up and write tests for it. Form handling? Do you want to write a form validation library? No? Spend some time searching for a good one *with a future*. Pagination? Email? I literally copy/pasted then modified the code from Django for the latter two. In short, you end up writing an ad-hoc glue framework on top of CherryPy. With just one person working on it, you can get away without writing a heap of tests and documentation. With multiple people working on it you'd really need to to make sure everyone is on the same page. Choosing CherryPy won't just be a matter of choosing it and running with it, it'll also be a matter of choosing more components, how to integrate them and documenting it. An advantage of doing it this way, not to be understated, is that you'll learn how to use those components individually and can apply them elsewhere. From what I have read, each of the components in the Django
Re: [pygame] PyGame Website Rewrite
I doubt I'd be contributing in any form whatsoever if Django is used. I have no real interest in learning it. If Robert Brewer has personally promised assistance that would be a very good case for using CherryPy. As time permits I might be able to help somewhat if a CherryPy stack is used. I personally much prefer CherryPy + Co over what I have seen of Django but I doubt I'll be contributing much compared to others. Hi, very detailed emails from Marcus and Nicholas... a few related points below. I'd be interested in knowing what jug, and orcun think of using Django? Also what they think of a cherrypy based stack? Also, what are the preferences of Lenard, Devon, pymike, and anyone else who is interested in contributing? Please state the level of commitment you're willing to make, and also which option(s) you'd be happy using. - The main author of cherrypy(Robert Brewer) said he'd help us with any major issues we had, and so did some other cherrypy mailing list people. The cherrypy mailing list is also more active than the pygame one, so I'm sure we won't have any issues with docs or help. - documentation is extensive for cherrypy(it's a 10 year old project, in it's third generation). - we would have to choose a stack. The stack Nicholas mentioned seems pretty common, cherrypy + sqlalchemy + genshi + formencode/formalchemy + pygame of course for imaging... and joysick control of the website. So that is the stack we would be chosing. - cherrypy code seems cleaner... as it's just python objects. class MySite(object): def index(self): return hello world! def news(self, id=None): if id is None: return main_news() else: return specific_news(id) index.exposed = True news.exposed = True This creates these urls by default: / /index /news /news/10 /news?id=10 - cherrypy has less code compared to django, and is changing less. - django is usually run using apache modpython or mod_wsgi, or even with cherrypy(or other wsgi server). They don't recommend using the bundled django webserver. Whereas cherrypy is considered one of, if not the best python web servers. With cherrypy you use the same webserver for development, and for production. - you can run cherrypy inside a pygame application. Cherrypy doesn't control the main loop if you don't want it to. - there are more wsgi components than there are pinax apps. Also pinax apps should theoretically be able to play with wsgi. I'm pretty sure you can use django apps as wsgi components now too.
Re: [pygame] PyGame Website Rewrite
On, Fri Apr 24, 2009, Rene Dudfield wrote: [...] Also, is it possible to do this at google code instead? http://code.google.com/p/pygame/ Sounds reasonable - google already has the whole functionality for the project, Julian currently hosts privately. It might be good to use google's wiki there and a seperate website SVN branch. Especially since the final system could be adopted by other community-driven projects. Also lots of people already have google accounts on there, and it's not hosted on someones personal server. Keeping it separate from the main pygame svn makes sense, since it's probably going to be a separate group of people, and also it's fairly easy to allow access to it. After discussing certain things with Julian, something like this might make the most sense: SVN hosting on google. Trac (which I'd prefer over google's homebrewn software) on dev.pygame.org. Why that? First of all, one of the website requirements is to have a bug tracker and wiki integrated instead of having anything hosted on different domains as it is at the moment. dev.pygame.org could act as central platform for pygame-related development. Users can keep track of pygame projects, which are in a planning and early development state and the trac system running there can act as routing station to the different SVN repositories hosted elsewhere (google, pygame, ...). In the long term, this also allows us to have a development wiki and bug tracking already around and the only thing left to do would be to integrate them seamlessly into the final pygame.org website. For the current time, we could redirect dev.pygame.org to Julian's webserver, then, once trac is up and running on pygame.org (which should be relatively easy to be realised), let it point to the local trac. That way we have no dead URL mess and people do not need to visit various sites (and create different accounts) just to file bugs for (either) pygame project. We also do not have the data scattered ony google's wiki, pygame.org and wherever else. Regards Marcus pgpcQIJeqnXnQ.pgp Description: PGP signature
Re: [pygame] PyGame Website Rewrite
On, Sat Apr 25, 2009, Nicholas Dudfield wrote: I doubt I'd be contributing in any form whatsoever if Django is used. I have no real interest in learning it. If Robert Brewer has personally promised assistance that would be a very good case for using CherryPy. Well, I'd like to keep the decision those, who will do the major work on the whole website system, which probably will be Julian and Orcun. If they both say, Django is their preferred target system (and the GSoC proposals were written that way) as they have a lot of expertise, we should not insist on CherryPy :-). Regards Marcus pgpeybUYTDnYX.pgp Description: PGP signature
Re: [pygame] PyGame Website Rewrite
Marcus von Appen wrote: Well, I'd like to keep the decision those, who will do the major work on the whole website system, which probably will be Julian and Orcun. I am in complete agreeance. Happy programmers are motivated and programmers./ /
Re: [pygame] PyGame Website Rewrite
On, Sat Apr 25, 2009, Nicholas Dudfield wrote: I doubt I'd be contributing in any form whatsoever if Django is used. I have no real interest in learning it. If Robert Brewer has personally promised assistance that would be a very good case for using CherryPy. Well, I'd like to keep the decision those, who will do the major work on the whole website system, which probably will be Julian and Orcun. If they both say, Django is their preferred target system (and the GSoC proposals were written that way) as they have a lot of expertise, we should not insist on CherryPy :-). Regards Marcus Happy programmers are motivated and *productive* programmers I meant to write but I had a brain malfunction.
Re: [pygame] PyGame Website Rewrite
Hello, I'm kinda amazed about some points: 1) Did anyone read my concept? Some of the discussed ideas here I had before but no one cared. 2) I created a trac an you said nice! and created a Google project. 3) This project was an gsoc candidate and AFAIK all applicants wanted to use Django. At least 2 of them (Orcun and me) would like to do it even without google. Now you say let's do it with cherrypy because you don't know Django. Hm. I my view, both - Django and cherrypy - are mighty enough for our needs, thus its a relig. question of faith. But you asked so to do it. So, here we are! We have time and (only) want to do it with Django, cause we don't know cherrypy as you don't know Django. Maybe here are some php-experts why do it with php? 4) Even if you don't know Django, you can participate by helping to develop the concept, writing specific requirements, care about design, read the old code, transfer it and write new templates (Django templates are really easy to learn). If we use Trac the way things are going, there will be some work on adapting it by editing the Trac templates and style to make it fit into the whole page. Then, care about plugins that could be useful or necessary (auth, notification, feeds, irc-announcer, ...). Be sure you can help us even when using Django for the backend. Regards Jug PS, well, I'm a slow writer, so I agree with Marcus.
Re: [pygame] PyGame Website Rewrite
Marcus von Appen wrote: On, Sat Apr 25, 2009, Nicholas Dudfield wrote: I doubt I'd be contributing in any form whatsoever if Django is used. I have no real interest in learning it. If Robert Brewer has personally promised assistance that would be a very good case for using CherryPy. Well, I'd like to keep the decision those, who will do the major work on the whole website system, which probably will be Julian and Orcun. If they both say, Django is their preferred target system (and the GSoC proposals were written that way) as they have a lot of expertise, we should not insist on CherryPy :-). Regards Marcus In full: I doubt I'd be contributing in any form whatsoever if Django is used. I have no real interest in learning it. If Robert Brewer has personally promised assistance that would be a very good case for using CherryPy. *As time permits I might* be able to help somewhat if a CherryPy stack is used. I personally much prefer CherryPy + Co over what I have seen of Django *but I doubt I'll be contributing much compared to others.* I actually took time out of my day to argue the case for using Django.
Re: [pygame] PyGame Website Rewrite
There's one problem remaining. One of the few weaknesses of Django is that it does not support subdomains. Thus, pygame.org/dev would be much easier to handle. To concretize, please specify the structure again. What would Trac be used for? Replace the current wiki and add a ticket system for bug-tracing and more (enhancements, etc)? So, the rough structure would be Django - News - Flatpages - Projects Trac - Wiki - Ticket system - code browser - (maybe more?) I'm going to test the django-trac thing today. If we use now my Trac please try to keep the concept up to date and edit it with our discussion results. - Jug http://www.dict.cc/englisch-deutsch/weakness.html
Re: [pygame] PyGame Website Rewrite
Intresting, I just start to study Django, I think it is really a nice tools. -- From: jug j...@fantasymail.de Sent: Saturday, April 25, 2009 9:26 PM To: pygame-users@seul.org Subject: Re: [pygame] PyGame Website Rewrite There's one problem remaining. One of the few weaknesses of Django is that it does not support subdomains. Thus, pygame.org/dev would be much easier to handle. To concretize, please specify the structure again. What would Trac be used for? Replace the current wiki and add a ticket system for bug-tracing and more (enhancements, etc)? So, the rough structure would be Django - News - Flatpages - Projects Trac - Wiki - Ticket system - code browser - (maybe more?) I'm going to test the django-trac thing today. If we use now my Trac please try to keep the concept up to date and edit it with our discussion results. - Jug http://www.dict.cc/englisch-deutsch/weakness.html
Re: [pygame] PyGame Website Rewrite
jug wrote: snip / One of the few weaknesses of Django is that it does not support subdomains. Thus, pygame.org/dev would be much easier to handle. snip / Unless I misunderstood, everybody was saying that someone should create a subdomain with the server administrator tools and simply run Django from there. I don't think they want Django running in the top-level web directory and creating a dev subdomain. If you're saying that Django can't be confined to a single directory and that it must be run from the top-level web directory, I have nothing to add. Regards, Evan Kroske
Re: [pygame] Never seen this before
what does the super() function do? --- On Fri, 4/24/09, Tyler Laing trinio...@gmail.com wrote: From: Tyler Laing trinio...@gmail.com Subject: Re: [pygame] Never seen this before To: pygame-users@seul.org Date: Friday, April 24, 2009, 7:58 PM You get that kind of error when you use a recursive function, and it recurses down further than Python has room on the stack for. Typically, when you get this error, there's something wrong with your recursive function. What it appears to be doing is within your add function, its calling itself again. I think you might be wanting to call super(C, self).add(spr) where C is the class you created which has the add method. -Tyler On Fri, Apr 24, 2009 at 5:27 PM, Yanom Mobis ya...@rocketmail.com wrote: this code level1 = [(0,0), (20, 0), (40, 0), (60, 0), (80, 0), (100,0), (120,0), (140,0), (160,0), (180,0), (200,0), (220,0), (240,0)] #positions of enemies #yatta yatta def setenemies_lvl1(): # put enemies on screen. pygame.display.set_caption(Loading Level) #tell player it's loading for item in level1: #loop throug coords in level file: lvl1 enemies.add(random.choice((enemyblue.png, enemycyan.png, enemygrey.png, enemyyellow.png)), item, enemybullets) pygame.display.set_caption(PyStarFighter) #tell player it's done is causing this problem: File /usr/local/lib/python2.6/site-packages/pygame/sprite.py, line 325, in add self.add(spr) alot of the same message File /usr/local/lib/python2.6/site-packages/pygame/sprite.py, line 316, in add if isinstance(sprite, Sprite): RuntimeError: maximum recursion depth exceeded while calling a Python object -- Visit my blog at http://oddco.ca/zeroth/zblog
Re: [pygame] Never seen this before
the two files for the game are attached --- On Fri, 4/24/09, Brian Song unlucky...@gmail.com wrote: From: Brian Song unlucky...@gmail.com Subject: Re: [pygame] Never seen this before To: pygame-users@seul.org Date: Friday, April 24, 2009, 9:57 PM If the problems fixed, yay. If not, you should put up most/all your source so it's easier for people to see whats happening. #! /usr/bin/env python #main.py - main file for pystarfighter print(init...) #lvl level1 = [(0,0), (20, 0), (40, 0), (60, 0), (80, 0), (100,0), (120,0), (140,0), (160,0), (180,0), (200,0), (220,0), (240,0)] #positions of enemies #/lvl import pygame, spritemodule,random #import modules from pygame.locals import *# screen = pygame.display.set_mode((256,256)) pygame.display.set_caption(Loading) gameObjects = pygame.sprite.Group() #canisters bullets = pygame.sprite.Group() # enemybullets = pygame.sprite.Group()# enemies = pygame.sprite.Group() # clock=pygame.time.Clock() weaponheat = 0 spaceship = spritemodule.Player(spaceship.png) #create player object gameObjects.add(spaceship) # #colors blue = 0,0,255 red = 255, 0, 0 green = 0, 255, 0 black = 0,0,0 white = 255,255,255 #/colors spaceship.rect.left = 0 spaceship.rect.top = 236 pygame.display.set_caption(PyStarFighter) print(init complete) def setenemies_lvl1(): # put enemies on screen. pygame.display.set_caption(Loading Level) #tell player it's loading for item in level1: #loop throug coords in level file: lvl1 enemies.add(random.choice((enemyblue.png, enemycyan.png, enemygrey.png, enemyyellow.png)), item, enemybullets) pygame.display.set_caption(PyStarFighter) #tell player it's done def mainloop(): weaponheat = 0 while 1: # main game loop clock.tick(60) weaponheat = weaponheat - 1 if weaponheat 0: weaponheat = 0 #ensure the weaponheat doesn't fall below zero spaceship.speed = (0,0) key = pygame.key.get_pressed() #create a list of keys #keys if key[K_RIGHT] and spaceship.rect.left 240: spaceship.speed = (6,0) if key[K_LEFT] and spaceship.rect.left 0: spaceship.speed = (-6,0) if key[K_SPACE] and weaponheat == 0: #shoot weaponheat = 60 bullets.add(spritemodule.Bullet(bullet.png, (0, -10))) #/keys spaceship.rect= spaceship.rect.move(spaceship.speed) for event in pygame.event.get(): #cycle events if event.type == QUIT or event.type == KEYDOWN and event.key == K_ESCAPE: exit() for item in bullets: #loop through bullet canister if item.rect.left == 0 and item.rect.top == 0: item.rect.left = spaceship.rect.left #move the bullet to the spaceship item.rect.top = spaceship.rect.top# else: item.rect = item.rect.move(0,-6) #screen screen.fill(black) bullets.draw(screen) enemybullets.draw(screen) gameObjects.draw(screen) enemies.draw(screen) pygame.display.flip() setenemies_lvl1() #mainloop() import pygame class Basicsprite(pygame.sprite.Sprite): #create a sprite class def __init__(self, img): pygame.sprite.Sprite.__init__(self) self.image = pygame.image.load(img).convert_alpha() self.rect = self.image.get_rect() def resetrect(self): self.rect = self.image.get_rect() class Player(Basicsprite): #player ship def __init__(self, img): Basicsprite.__init__(self, img) def shoot(): pass class Bullet(Basicsprite): #bullet def __init__(self, img, speed): #speed is a tuple that describes the direction the bullet travels. Basicsprite.__init__(self, img) self.speed=speed class Enemy(Basicsprite): #enemy def __init__(self, img, initpos, bulletcanister): #bulletcanister- the sprite canister it puts the bullets in Basicsprite.__init__(self, img) self.rect.left = initpos[0] self.rect.top = initpos[1] def shoot(): #shoot a bullet self.bulletcanister.add(Bullet(bullet.png))
Re: [pygame] Never seen this before
Okay, I had assumed you had written your own python class, subclassing one of the Group classes, and had used .add within the overridden method. I've made that mistake myself. Looking at your code, I see the issue. For one, Group.add takes in a list of sprites. You are passing in three separate arguments, and Group.add is thinking they are each sprites. You should change enemies.add(random.choice((enemyblue.png, enemycyan.png, enemygrey.png, enemyyellow.png)), item, enemybullets) to enemies.add(Enemy(random.choice((enemyblue.png, enemycyan.png, enemygrey.png, enemyyellow.png)), item, enemybullets)) The super method can take a class and an object as parameters, and it will call the method on the superclass of the class given. It is the same as Basicsprite.__init__(self, img) For reference, here is the documentation about Group.add: http://www.pygame.org/docs/ref/sprite.html#Group.add -Tyler On Sat, Apr 25, 2009 at 6:34 AM, Yanom Mobis ya...@rocketmail.com wrote: the two files for the game are attached --- On *Fri, 4/24/09, Brian Song unlucky...@gmail.com* wrote: From: Brian Song unlucky...@gmail.com Subject: Re: [pygame] Never seen this before To: pygame-users@seul.org Date: Friday, April 24, 2009, 9:57 PM If the problems fixed, yay. If not, you should put up most/all your source so it's easier for people to see whats happening. -- Visit my blog at http://oddco.ca/zeroth/zblog
Re: [pygame] Never seen this before
On Sat, Apr 25, 2009 at 06:33:00AM -0700, Yanom Mobis wrote: what does the super() function do? It's a way to call the superclass version of the method you're overriding. (Technically, it's a built-in type, and not a function, but that's an irrelevant implementation detail). Read more about it: * http://www.python.org/download/releases/2.2/descrintro/#cooperation * http://fuhm.net/super-harmful/ Marius Gedminas -- Microsoft's entry in this cavalcade of horrors is Universal Plug and Play (UPnP). This is a protocol that allows [...] an end-user system to request a dynamic port-forwarding from the firewall to the box. Many network administrators will probably (rightly) recoil at letting applications on a Windows box dictate firewall policy. -- Anthony Baxter signature.asc Description: Digital signature
[pygame] Re: PyGame Website Rewrite
# need a numeric version? or save it as string? version = models.FloatField() the version should be a string beceause it allows for different kind of version formats like 1.0.4b On Apr 23, 8:35 pm, jug j...@fantasymail.de wrote: Hello, to organize the development process, I've set up a SVN-repo and a small Trac athttp://pygameweb.no-ip.org/trac/ You'll find there a first concept and you can take part in developing it by adding your ideas. Some of the point are completely to work out, so just have a look. If you have a complete concept for one of the points (eg the design) create a new wiki page and add a link. If you would like to participate in developing, add yourself to the list on the start page and provide some information like I did. I've done the setup on the quick so if there are any problems with Trac or you need more rights, please email me. Regards, Jug
Re: [pygame] Re: PyGame Website Rewrite
Hi # need a numeric version? or save it as string? version = models.FloatField() the version should be a string beceause it allows for different kind of version formats like 1.0.4 Right! I thought of sorting but sorting different projects by version is rubbish. Better by last update or so. I've just changed that ;)
Re: [pygame] Never seen this before
oops. I should add that to my list of dumb bugs i find in the code i write. Like this one: if key[K_RIGHT]: spaceship.speed = spaceship.speed+10 if key[K_RIGHT]: spaceship.speed = spaceship.speed-10 :) --- On Sat, 4/25/09, Tyler Laing trinio...@gmail.com wrote: From: Tyler Laing trinio...@gmail.com Subject: Re: [pygame] Never seen this before To: pygame-users@seul.org Date: Saturday, April 25, 2009, 9:12 AM Okay, I had assumed you had written your own python class, subclassing one of the Group classes, and had used .add within the overridden method. I've made that mistake myself. Looking at your code, I see the issue. For one, Group.add takes in a list of sprites. You are passing in three separate arguments, and Group.add is thinking they are each sprites. You should change enemies.add(random.choice((enemyblue.png, enemycyan.png, enemygrey.png, enemyyellow.png)), item, enemybullets) to enemies.add(Enemy(random.choice((enemyblue.png, enemycyan.png, enemygrey.png, enemyyellow.png)), item, enemybullets)) The super method can take a class and an object as parameters, and it will call the method on the superclass of the class given. It is the same as Basicsprite.__init__(self, img) For reference, here is the documentation about Group.add: http://www.pygame.org/docs/ref/sprite.html#Group.add -Tyler On Sat, Apr 25, 2009 at 6:34 AM, Yanom Mobis ya...@rocketmail.com wrote: the two files for the game are attached --- On Fri, 4/24/09, Brian Song unlucky...@gmail.com wrote: From: Brian Song unlucky...@gmail.com Subject: Re: [pygame] Never seen this before To: pygame-users@seul.org Date: Friday, April 24, 2009, 9:57 PM If the problems fixed, yay. If not, you should put up most/all your source so it's easier for people to see whats happening. -- Visit my blog at http://oddco.ca/zeroth/zblog
Re: [pygame] Never seen this before
Happens to everyone. It takes time(10 years or 10,000 hours) to get good at something. I'm at about year 6-7 and I find while I still make silly mistakes, I've become much better at catching them before or during testing. :) On Sat, Apr 25, 2009 at 8:03 AM, Yanom Mobis ya...@rocketmail.com wrote: oops. I should add that to my list of dumb bugs i find in the code i write. Like this one: if key[K_RIGHT]: spaceship.speed = spaceship.speed+10 if key[K_RIGHT]: spaceship.speed = spaceship.speed-10 :) --- On *Sat, 4/25/09, Tyler Laing trinio...@gmail.com* wrote: From: Tyler Laing trinio...@gmail.com Subject: Re: [pygame] Never seen this before To: pygame-users@seul.org Date: Saturday, April 25, 2009, 9:12 AM Okay, I had assumed you had written your own python class, subclassing one of the Group classes, and had used .add within the overridden method. I've made that mistake myself. Looking at your code, I see the issue. For one, Group.add takes in a list of sprites. You are passing in three separate arguments, and Group.add is thinking they are each sprites. You should change enemies.add(random.choice((enemyblue.png, enemycyan.png, enemygrey.png, enemyyellow.png)), item, enemybullets) to enemies.add(Enemy(random.choice((enemyblue.png, enemycyan.png, enemygrey.png, enemyyellow.png)), item, enemybullets)) The super method can take a class and an object as parameters, and it will call the method on the superclass of the class given. It is the same as Basicsprite.__init__(self, img) For reference, here is the documentation about Group.add: http://www.pygame.org/docs/ref/sprite.html#Group.add -Tyler On Sat, Apr 25, 2009 at 6:34 AM, Yanom Mobis ya...@rocketmail.comhttp://mc/compose?to=ya...@rocketmail.com wrote: the two files for the game are attached --- On *Fri, 4/24/09, Brian Song unlucky...@gmail.comhttp://mc/compose?to=unlucky...@gmail.com * wrote: From: Brian Song unlucky...@gmail.comhttp://mc/compose?to=unlucky...@gmail.com Subject: Re: [pygame] Never seen this before To: pygame-users@seul.org http://mc/compose?to=pygame-us...@seul.org Date: Friday, April 24, 2009, 9:57 PM If the problems fixed, yay.. If not, you should put up most/all your source so it's easier for people to see whats happening. -- Visit my blog at http://oddco.ca/zeroth/zblog -- Visit my blog at http://oddco.ca/zeroth/zblog
Re: [pygame] Never seen this before
On Sat, Apr 25, 2009 at 8:17 AM, Tyler Laing trinio...@gmail.com wrote: Happens to everyone. It takes time(10 years or 10,000 hours) to get good at something. I'm at about year 6-7 and I find while I still make silly mistakes, I've become much better at catching them before or during testing. :) I'm at year 2, but I'm ~4000 hours...I guess I'm obsessive. I still make mistakes, though, obviously.
Re: [pygame] C/C++ and Python
On Sat, Apr 25, 2009 at 8:40 AM, Jake b ninmonk...@gmail.com wrote: On Wed, Apr 22, 2009 at 4:39 AM, Knapp magick.c...@gmail.com wrote: On Wed, Apr 22, 2009 at 8:23 AM, René Dudfield ren...@gmail.com wrote:and have less errors in the end. I wish I did not have to type self so much in python!!! C++ is much better this way Using an editor like Geany, you type s then TAB, it inserts self. -- Jake I do use Geany, but it still looks like an explosion is a self factory. :-) -- Douglas E Knapp Why do we live?
Re: [pygame] C/C++ and Python
Using an editor like Geany, you type s then TAB, it inserts self. -- Jake BTW s tab does not insert self. on my machine. Why not? -- Douglas E Knapp Why do we live?
Re: [pygame] Never seen this before
On Sat, Apr 25, 2009 at 08:17:11AM -0700, Tyler Laing wrote: Happens to everyone. It takes time(10 years or 10,000 hours) to get good at something. I'm at about year 6-7 and I find while I still make silly mistakes, I've become much better at catching them before or during testing. :) Silly mistakes never go away. With experience you begin to expect them and check your assumptions more often. There have been countless times I've written unit tests for tiny functions that I couldn't possibly have written wrong, only to discover that I have in fact made a silly mistake. Marius Gedminas -- I'm unaware of anyone having implemented even a fraction of H.323 in Python. Doing so would require a special kind of dedication, and quite possibly a large amount of whiskey and prescription medication. -- Anthony Baxter signature.asc Description: Digital signature
Re: [pygame] C/C++ and Python
Edit your /programs/geany/data/snippets.conf On Sat, Apr 25, 2009 at 3:49 PM, Knapp magick.c...@gmail.com wrote: Using an editor like Geany, you type s then TAB, it inserts self. -- Jake BTW s tab does not insert self. on my machine. Why not? My 'python' section is: [Python] for=for i in xrange(%cursor%):\n\t doc=%cursor%\n elif=elif %cursor%:\n\t else=else:\n\t%cursor% if=if %cursor%:\n\t from=from %cursor% import \n main=if __name__ == '__main__':\n\t%cursor% class=class %cursor%(object):\n\n\tdef __init__(self):\n\t\t def=def %cursor%(self):\n\t get=def get_%cursor%(self): return self._\n set=def set_%cursor%(self): self._ = \n %dot%=self.%cursor% s=self.%cursor% try=try %cursor%:\n\t\nexcept ERROR:\n\t py=#!/usr/bin/env python\n#-*- coding:utf-8 -*-\n%cursor% while=while %cursor%:\n\t -- Jake
Re: [pygame] PyGame Website Rewrite
Marcus von Appen wrote: After discussing certain things with Julian, something like this might make the most sense: SVN hosting on google. Trac (which I'd prefer over google's homebrewn software) on dev.pygame.org. Why that? First of all, one of the website requirements is to have a bug tracker and wiki integrated instead of having anything hosted on different domains as it is at the moment. dev.pygame.org could act as central platform for pygame-related development. Users can keep track of pygame projects, which are in a planning and early development state and the trac system running there can act as routing station to the different SVN repositories hosted elsewhere (google, pygame, ...). In the long term, this also allows us to have a development wiki and bug tracking already around and the only thing left to do would be to integrate them seamlessly into the final pygame.org website. For the current time, we could redirect dev.pygame.org to Julian's webserver, then, once trac is up and running on pygame.org (which should be relatively easy to be realised), let it point to the local trac. That way we have no dead URL mess and people do not need to visit various sites (and create different accounts) just to file bugs for (either) pygame project. We also do not have the data scattered ony google's wiki, pygame.org and wherever else. Keeping the web site development on a separate site, google, seem appropriate for now. I have just been looking again at Trac and at first it looks like a good choice. The wiki has a clean markup that accepts Python code without mangling it. But I have two questions. One, how easy will it be to import the existing Pygame wiki pages into Trac? Two, can we really use the Trac with the Web SVN and Pygame SVN? (*) Lenard (*) I believe no to the first, yes to the second (http://trac.edgewall.org/wiki/TracInstall#OptionalRequirements).
Re: [pygame] PyGame Website Rewrite
All I have to add to this is that having real bug tracking integrated with the SVN is a huge plus and if possible, should be put into place as soon as possible. That is, having Trac up on dev.pygame.org before starting the web development work for use with both the website project and Pygame in general would be nice. I really dislike the Bugzilla we are currently using, and judging by the lack of activity on it, I imagine many others do too. Nirav On Sat, Apr 25, 2009 at 11:59 PM, Lenard Lindstrom le...@telus.net wrote: Marcus von Appen wrote: After discussing certain things with Julian, something like this might make the most sense: SVN hosting on google. Trac (which I'd prefer over google's homebrewn software) on dev.pygame.org. Why that? First of all, one of the website requirements is to have a bug tracker and wiki integrated instead of having anything hosted on different domains as it is at the moment. dev.pygame.org could act as central platform for pygame-related development. Users can keep track of pygame projects, which are in a planning and early development state and the trac system running there can act as routing station to the different SVN repositories hosted elsewhere (google, pygame, ...). In the long term, this also allows us to have a development wiki and bug tracking already around and the only thing left to do would be to integrate them seamlessly into the final pygame.org website. For the current time, we could redirect dev.pygame.org to Julian's webserver, then, once trac is up and running on pygame.org (which should be relatively easy to be realised), let it point to the local trac. That way we have no dead URL mess and people do not need to visit various sites (and create different accounts) just to file bugs for (either) pygame project. We also do not have the data scattered ony google's wiki, pygame.org and wherever else. Keeping the web site development on a separate site, google, seem appropriate for now. I have just been looking again at Trac and at first it looks like a good choice. The wiki has a clean markup that accepts Python code without mangling it. But I have two questions. One, how easy will it be to import the existing Pygame wiki pages into Trac? Two, can we really use the Trac with the Web SVN and Pygame SVN? (*) Lenard (*) I believe no to the first, yes to the second (http://trac.edgewall.org/wiki/TracInstall#OptionalRequirements).
Re: [pygame] PyGame Website Rewrite
I agree that a Pygame bug tracker on the Pygame site is a priority. Trac looks good for that. The wiki will be useful as well. But the Trac subversion features will be useless with a google SVN for the web site development. So we will have to use whatever google offers. But I believe we can set it up for Pygame's SVN. Lenard Nirav Patel wrote: All I have to add to this is that having real bug tracking integrated with the SVN is a huge plus and if possible, should be put into place as soon as possible. That is, having Trac up on dev.pygame.org before starting the web development work for use with both the website project and Pygame in general would be nice. I really dislike the Bugzilla we are currently using, and judging by the lack of activity on it, I imagine many others do too. Nirav On Sat, Apr 25, 2009 at 11:59 PM, Lenard Lindstrom le...@telus.net wrote: Marcus von Appen wrote: After discussing certain things with Julian, something like this might make the most sense: SVN hosting on google. Trac (which I'd prefer over google's homebrewn software) on dev.pygame.org. Why that? First of all, one of the website requirements is to have a bug tracker and wiki integrated instead of having anything hosted on different domains as it is at the moment. dev.pygame.org could act as central platform for pygame-related development. Users can keep track of pygame projects, which are in a planning and early development state and the trac system running there can act as routing station to the different SVN repositories hosted elsewhere (google, pygame, ...). In the long term, this also allows us to have a development wiki and bug tracking already around and the only thing left to do would be to integrate them seamlessly into the final pygame.org website. For the current time, we could redirect dev.pygame.org to Julian's webserver, then, once trac is up and running on pygame.org (which should be relatively easy to be realised), let it point to the local trac. That way we have no dead URL mess and people do not need to visit various sites (and create different accounts) just to file bugs for (either) pygame project. We also do not have the data scattered ony google's wiki, pygame.org and wherever else. Keeping the web site development on a separate site, google, seem appropriate for now. I have just been looking again at Trac and at first it looks like a good choice. The wiki has a clean markup that accepts Python code without mangling it. But I have two questions. One, how easy will it be to import the existing Pygame wiki pages into Trac? Two, can we really use the Trac with the Web SVN and Pygame SVN? (*) Lenard (*) I believe no to the first, yes to the second (http://trac.edgewall.org/wiki/TracInstall#OptionalRequirements).
