Re: [pygame] pymike!

IIRC he has a website as well where he keeps all his stuff. URL escapes me at the moment, but I'm sure it'll come up if you google for it. Hugo On Wed, Sep 2, 2009 at 4:56 PM, B W wrote: > What happened to the pymike tags on the pygame.org project pages? When > I click the pymike tag it only resu

Re: [pygame] is there a way to optimize this code?

On Mon, Aug 17, 2009 at 11:59 PM, Ian Mallett wrote: > On Mon, Aug 17, 2009 at 1:42 PM, Hugo Arts wrote: >> >> How about writing a fragment shader? > > Well, vertex shaders and fragment shaders go together.  Sometimes a geometry > shader can be added between them.  To

Re: [pygame] is there a way to optimize this code?

On Mon, Aug 17, 2009 at 8:47 PM, Ian Mallett wrote: > I just realized, solution two might actually be better.  It will start out > much faster, and it's speed will converge to the speed of solution 1 as the > number of particles increases.  If you really wanted to get fussy, particles > that have h

Re: [pygame] is there a way to optimize this code?

On Mon, Aug 17, 2009 at 6:32 PM, Ian Mallett wrote: > What I like about the OP's approach, and about the numpy version of it, is > that it's perfectly scalable to any number of particles.  The program as I > modified it runs ~30 fps--but it runs about 30fps whether you add random > particles 8 or 1

Re: [pygame] Re: is there a way to optimize this code?

hey Marco, welcome to the pygame list. One thing before I start: It's better to send a new e-mail rather then reply if your mail is not related to that discussion. This way clients like gmail can separate threads nicely. I downloaded the file and ran it on my ubuntu box, and it seems to work with

Re: [pygame] is there a way to optimize this code?

My gut says this is most definitely the fastest way to go for small numbers of snow flakes. I suspect there is a certain point at which the numpy approach by Ian wins out (especially if you can optimize that a little more like Ian suggests, though I don't know enough about numpy). Some good tips t

Re: [pygame] 7 failures and 1 error in test suite

On Thu, Jul 2, 2009 at 2:55 PM, wrote: > > Hi, > > On Thu, 2 Jul 2009 09:48:48 +1000, René Dudfield wrote: >> Cool, thanks for the testing. >> >> >> On Thu, Jul 2, 2009 at 9:19 AM, Lorenz Quack wrote: >>> Ok, so here goes my analysis of the failures in ColorTypeTest: >>> In src/color.c line 1435

Re: [pygame] Bliting clip semantics

you can blit something that is not on the screen or even half on the screen without problems. It will work as expected On Tue, Feb 17, 2009 at 8:55 AM, Daniel Mateos wrote: > Hey All, > > I was just wondering if i can count on Surface.blit dealing with stuff i > pass it that has co-ords greater t

Re: [pygame] Good code for text wrapping?

LaTeX support ;-) On Sun, Sep 21, 2008 at 9:18 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > awesome :) > > > yeah, maybe some text layout code would be a useful addition to > pygame.font ? Or even as a separate download. > > > > Shall we start by making an ultimate list of features, or use cas

Re: [pygame] [pygame ] Having trouble with RenderUpdate

using self.rect = image.get_rect() gets you a rect with the correct size. you can use self.rect.topleft = (100, 200) to set the position, that will save you some lines. saw this second e-mail only after replying to the first one. sorry. On Mon, Sep 15, 2008 at 9:16 AM, KKarasu <[EMAIL PROTECTED]>

Re: [pygame] having problem swith RenderUpdate

What you're doing seems alright. how exactly doesn't it work? What is the produced effect and how does it deviate from the desired effect? I think it will be helpful to us to see a more detailed code listing. On Sun, Sep 14, 2008 at 7:34 PM, KKarasu <[EMAIL PROTECTED]> wrote: > Hi there! > > Aft

Re: [pygame] Question - Comparing strings

Wait a second, I always thought it was called PascalCase, and camelCase is like that On Thu, Sep 4, 2008 at 1:36 PM, Casey Duncan <[EMAIL PROTECTED]> wrote: > On Sep 4, 2008, at 12:12 PM, Ian Mallett wrote: > >> On Thu, Sep 4, 2008 at 8:15 AM, kschnee <[EMAIL PROTECTED]> wrote: On a >> dissenting

Re: [pygame] Question - Comparing strings

On Thu, Sep 4, 2008 at 10:15 AM, kschnee <[EMAIL PROTECTED]> wrote: > >> if WordListFile == "default" or "default" or "Default" or "d" or "D": > > > > This does not do what you think it does. What you want is this: > > if word_list_file.lower() in ("default", "d"): > > By way of further explanatio

Re: [pygame] Re:

note that get_pressed checks if the key is down at the time of the call. If you press the key and release it between two loop iterations, this keypress will not be caught by get_pressed. This shouldn't be an issue though, unless you're game is not getting a lot of fps. Usually a key is pressed long

[pygame] Re:

I think the solution would be to utilize not only the KEYDOWN event but also the KEYUP event. when, for example, a right-arrow KEYDOWN event is generated, increase an attribute (call it speed) of the object to something like (5, 0). Then, every frame, add this speed to the objects position. When th

Re: [pygame] PyGameDB coming along well

well, damnit. I loved that name. How about "Flying py?" or maybe "Py in the sky?" Just throwing out some ideas here. On Wed, Aug 20, 2008 at 12:34 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote: > Yes, "Flying Circus" is a good name. So of course someone is already using > it: > > http://flying-c

Re: [pygame] PyGameDB coming along well

On Tue, Aug 19, 2008 at 10:39 AM, kschnee <[EMAIL PROTECTED]> wrote: > On Tue, 19 Aug 2008 07:49:16 -0700, James Paige <[EMAIL PROTECTED]> > wrote: >> That reminds me of something I read recently. Apparently the first ever >> computer program that can play Go with near-human skill was developed >>

Re: [pygame] Physics module status note

ah, I was under the impression that the OpenGL API also used radians. In that case I can't object any further. On Sat, Aug 16, 2008 at 6:39 AM, Marcus von Appen <[EMAIL PROTECTED]> wrote: > On, Sat Aug 16, 2008, Peter Gebauer wrote: > >> Hi there, Hugo! >> >> Yes, using radians in math-related sof

Re: [pygame] Physics module status note

most of python's math functions like asin en atan (from math) return their values in radians, and sin and tan take their arguments as radians. So using radians is more common than degrees. Conversion is also pretty trivial, using math.radians and math.degrees. Hugo On Fri, Aug 15, 2008 at 6:53 AM

Re: [pygame] Pygame, cwiid and ode - movement

you might want to post this on a wiimote development oriented mailing list/forum. This is not really a pygame-related question. At least include some additional details. Your question is really vague. Perhaps you will also benefit from reading this: http://www.catb.org/~esr/faqs/smart-questions.ht

Re: [pygame] I just got this email. [Bug 209967] Re: [needs-packaging] pygame 1.8 has been released. Please update package.

>Douglas_Knapp wrote on 2008-07-13: (permalink) > >That deb is great! can you do it 64 bit? is that you on the launchpad bug report? 'cause the email that got sent was a direct response to that message, you would get it if you're subscribed to the report. The package was sent by the same guy that

Re: [pygame] Another blitting surface to itself crash

On Sat, Aug 2, 2008 at 6:30 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: > There's another instance of blitting a surface to itself crashing on Windows > for a user, it's believed to be a 1.8.1 thing by the poster > http://pygame.motherhamster.org/bugzilla/show_bug.cgi?id=19 > > last time it came up

Re: [pygame] Perlin Noise Function

On Wed, Jul 30, 2008 at 6:09 PM, Knapp <[EMAIL PROTECTED]> wrote: > > I would argue that Perlin is a simple function and in no way comes close to > the complexity of a GUI. That said, I have always wished that Pygame had a > gui that was as good as the rest of it. I have found all the GUI's that I

Re: [pygame] AI Module (was: Perlin Noise Function)

On Wed, Jul 30, 2008 at 7:56 PM, kschnee <[EMAIL PROTECTED]> wrote: > > I was working with the assumption of this stuff being for a module outside > of Pygame. > Of course, I can have no objections of any kind to that. Your library. By all means go ahead and develop it. I might even be persuaded t

Re: [pygame] AI Module (was: Perlin Noise Function)

On Wed, Jul 30, 2008 at 6:20 PM, Knapp <[EMAIL PROTECTED]> wrote: > > That works unless you game is about space and which star out of 30,000 is > close. Then the idea of finding the distance to everything gets a bit slow. > To solve this you can take the position and divide by some distance that yo

Re: [pygame] AI Module (was: Perlin Noise Function)

> a function to find what is close to something (This is very doable) def close(something, other_things, distance): r = something.rect.inflate(distance, distance) return filter(lambda x: something.colliderect(x.rect), other_things) There you go, that's the first one. ;-) There is some tal

Re: [pygame] AI Module (was: Perlin Noise Function)

On Wed, Jul 30, 2008 at 2:54 PM, kschnee <[EMAIL PROTECTED]> wrote: > > I was playing recently with the A* pathfinding algorithm and made a > workable version of it: > http://kschnee.xepher.net/code/080721a_star_pathfinding.zip > http://kschnee.xepher.net/pics/080720a_star.jpg > > Other things that

Re: [pygame] Perlin Noise Function

On Wed, Jul 30, 2008 at 12:35 PM, Knapp <[EMAIL PROTECTED]> wrote: > > I agree that this is not a basic function but I don't see it as being less > basic than > pygame.transform.laplacian- > find > edges in a surface. > T

Re: [pygame] Perlin Noise Function

I'm not sure Perlin Noise would belong in the base pygame package. Though useful in some cases, it's not a critical/elementary function for game development. It might be a better idea to offer the functionality as an auxiliary library, or perhaps bundle it together with other procedural generation

Re: [pygame] Moving sprites.

Alright, create a sprite group with all your sprites in it, like so: group = pygame.sprite.RenderUpdates(self.ship1, self.ship2) you can add more sprites if you need them. You can also use group.add(sprite) to add a sprite to an existing group. That's basically all for setup. Now, in your renderi

Re: [pygame] printing option of wxwindow contains pygame window

I'm not an expert on wxwidgets/python combinations, and I discourage them precisely for reasons like these. That said, you could try blitting a ClientDC of the ScrolledWindow or the pygame window directly onto the Printing DC. I can't guarantuee that it will work though. On Thu, Jul 24, 2008 at 9

Re: [pygame] Surfaces must not be locked during blit

for text in page.texts: > > #draw text > > #lines > > for line in page.lines: > > self.Pygame.draw.line(logicalSurf, > [line.colline.x1,line.y1],[line.x2,line.y2],1) > > > > thanks, > > Sibtey > > > > > >

Re: [pygame] Surfaces must not be locked during blit

well, if pygame says this is a locking issue, then it is most likely a locking issue. If you say unlocking the surface did not fix the problem as you said, I don't have another solution with the current supplied information. We'll likely need to see some code before we can figure out the actual er

Re: [pygame] left-over pixels in pygame.draw.circle?

I thought of this myself as well, and I'm using it now. Thank you. On Wed, Jun 25, 2008 at 9:14 PM, Ian Mallett <[EMAIL PROTECTED]> wrote: > I always found this problem amusing. If you need a way around it, draw a > filled white circle, then a filled black circle inside of it. If the inside > n

[pygame] left-over pixels in pygame.draw.circle?

I've been getting strange results in pygame.draw.circle and pygame.draw.arc: if I specify a (non-zero) width for the circle/arc the resulting image is not drawn properly. A strange pattern of pixels remains its previous color on the target surface. This does not occur if I completely fill the circl

Re: [pygame] pyopengl sprite/particle performance

Your bottleneck might not be in your rendering code. I don't know wether PyOpenGL is even supposed to be much faster than pygame, but if rendering is not where your bottleneck is, switching will not help at all. I didn't look at the code, but in the profile it seems _collide_bullet is a frequently

Re: [pygame] Dirty Rect updating

Note that RenderUpdates or OrderUpdates are both a lot faster than what you are doing now. If you're clearing the whole screen to white and then drawing the background over it as well, you're still blitting to your whole screen twice. With RenderUpdates you can blit only what you need to, and that'

Re: [pygame] BUG: segfault when blitting surface to itself

On Fri, Apr 11, 2008 at 8:33 PM, Marcus von Appen <[EMAIL PROTECTED]> wrote: > On, Fri Apr 11, 2008, Hugo Arts wrote: > > > python version: 2.5.1 > > pygame version: 1.8 > > OS: Windows XP > > > > If you attempt to blit a surface to itself, python segfa

[pygame] BUG: segfault when blitting surface to itself

python version: 2.5.1 pygame version: 1.8 OS: Windows XP If you attempt to blit a surface to itself, python segfaults. Seems to occur only on windows (tested on XP and Ubuntu). I understand there is no reason to do this, but it would seem more appropriate to throw an exception or something like th