Re: [pygame] pygame website - request for suggestions
I find pygame has no big change many years,I hope it increase more features,such as alpha render,additive render,These is very useful to make a cooI game screen,On 7/12/06, René Dudfield [EMAIL PROTECTED] wrote: Weird.I think that person just copied in a link to a DSL provider,and to lance-tech which is Phils company (I think).I've removed the links for now, but left the image.I'm not sure howto email the owner though. On 7/12/06, spotter . [EMAIL PROTECTED] wrote: Hey, I suppose one improvement in the website is to add some spamming control. Just a few minutes ago, I saw this game that looked new, so when I clicked it it took me to http://www.pygame.org/projects/22/266/?release_id=411 It looks like someone tried to spam some links, cause the description of the game doesnt seem to go with the picture and the links lead to random websites. great site otherwise, thanks for all your hardwork! I would be really lost without it. -spotter.-- http://www.flyaflya.com powered by pygame+python
[pygame] PyWeek
Is pyweek a twice-a-year thing? I noticed the first one was in July, and the second was in January, so that means the next one should be coming up soon, right? I blew it in the last pyweek and didn't come up with anything close to a finished game. I want another chance! So does anyone know when the next one starts? It'd be cool if it started near the end of August or later, as I'll be back in school and I can recruit an elite team of freshman CS majors to work with me :) Anyway, if anyone (Richard ;) ) has any info about when the next PyWeek will be, please tell me! I joined the PyWeek google groups announcement list and there are no posts on it right now. So what do you guys think, is it too soon for another PyWeek? -Luke
[pygame] Pyweek-oops
Hmm, I was going off of the post dates of the pyweek announcements on Pygame.org, not on the actual dates of the competitions. My bad! So since the last one was in April, this upcoming one would be around October then?
Re: [pygame] Subtle Memory Bug
James Hofmann wrote: I'd agree. I've been in similar situations before. What's really wanted(once the problem is discovered) are these two properties: 1. references to list locations, rather than specific items 2. can step backwards when size/ordering changes I tend to use a while loop and counter for those purposes. So, like this? foo = [instance, instance, etc.] n = 0 while n len(foo): foo[n].DoStuff() ## Might result in deleting foo[n] n += 1 I think I've done something like that before, but I don't remember whether len(foo) gets evaluated anew each time. I may have had to say: n = 0 done = False while not done: DoStuff() if n = len(foo): done = True This issue is relevant to my AI code, if I ever really sit down and work on it. I'd been using a big dictionary of neuron-like objects and cycling through them each turn, giving each of them links containing ID numbers used to access other units. Instead I might eliminate the ID numbers altogether and give the units direct references to each other, eg.: scint.LinkTo( otherscint ) as opposed to: scint.LinkTo( otherscint.ID ) Kris
Re: [pygame] Subtle Memory Bug
Kris Schnee wrote: Bob Ippolito wrote: It's probably not the uniqueness of ID numbers that's breaking his code, it's the fact that he has two different generations in the same data structure. That's simply not how you should do what he's trying to do. So, maybe have a tribes_this_turn dictionary and a next_turn_tribes dictionary, with tribes getting copied into the next only if they haven't been flagged as gone? It'd be tricky because what if tribes A and B merge one turn, and in the same turn C tries to interact with them? I guess the tribe that A/B become wouldn't exist till next turn, but then there's the possibility that C will attack and destroy A on the same turn that A has been absorbed into B. The way this is typically handled is to separate actions from effects. For example, simple physical modelling systems will update the velocity and position of all objects before considering collisions and other forces that affect acceleration. In your case, say each tribe has some hit points. Your run loop could look like: for each tribe: attack other tribes, decreasing their hit points flag intent to merge with another tribe remove any tribe with hit points 0 for each pair of tribe intending to merge: merge the tribes As with a physical system, if your constraints / actions are more complex than this, you may want to solve a linear system or integrate a non-linear system to determine the simultaneous effect of all actions. [This comment is orthagonal to the idea of using separate vectors for current and next generations, which I am also in favour of.] Alex.
Re: [pygame] pygame website - request for suggestions
On Wed, 2006-07-12 at 16:48 +0800, flyaflya wrote: I find pygame has no big change many years,I hope it increase more features,such as alpha render,additive render,These is very useful to make a cooI game screen, The SDL library has also been slow with new features lately. Work has begun on an all new version, with support for things like multiple windows. When that is released there should be a new Pygame also with lots of new features. http://www.libsdl.org/news.php
Re: [pygame] pygame.scrap bitmap stuff
On Jul 12, 2006, at 8:34 PM, andrew baker wrote: What's a scrap? http://www.pygame.org/docs/ref/scrap.html -bob
Re: [pygame] pygame.scrap bitmap stuff
Sounds good! Nice one. Is libtiff linked to imageext on macosx? If so, I think there is a save as tiff function in there which I could add. I think I could make it save to bmp in memory fairly easily. I'll need to change the save signature to take a name hint(like load does). eg. f = someStringIOclass() surf.save(f, bla.bmp) On 7/13/06, Bob Ippolito [EMAIL PROTECTED] wrote: I went ahead and implemented (read: prototyped) scrap bitmap support for Mac OS X, but the implementation is terribly inefficient. Pygame surfaces aren't terribly accessible from Python outside of surfarray (which I didn't want to depend on). Going from a Surface to the pasteboard is particularly painful in this implementation: 1. Surface to PNG (on disk!) 2. NSImage from on-disk PNG 3. NSImage to TIFF 4. TIFF to pasteboard The absolute fastest route (which doesn't exist in pygame) would be: 1. Surface to TIFF (in memory) 2. TIFF to pasteboard pygame doesn't have any TIFF writing capability at all, a compromise here would to at least avoid hitting the disk and zlib: 1. Surface to BMP (in memory) 2. BMP to NSImage 3. NSImage to TIFF 4. TIFF to pasteboard Unfortunately this also isn't currently possible because pygame doesn't support BMP writing anymore (or so it seems from a quick look at the code) and it definitely won't do it to memory instead of disk. Cocoa does not support TGA. Going the other way is also gnarly, but mostly because I didn't want to think more than I had to: 1. pasteboard to NSImage 2. NSImage to TIFF 3. TIFF to NSBitmapImageRep 4. NSBitmapImageRep to BMP (in memory) 5. Surface from BMP Getting a NSBitmapImageRep directly from the NSImage (steps 2+3 combined) is definitely possible without going between TIFF, but I was too lazy to think about what that would do for vector graphics (e.g. PDF on the pasteboard) and screen representations. It's not necessarily true that NSImage will have a NSBitmapImageRep cached already. Going from NSBitmapImageRep to a Surface without hitting BMP is possible, but there's a bunch of formats the NSBitmapImageRep could be in and I didn't want to think about that either :) In any case, pygame.scrap is 100% implemented on Mac OS X, and it's kinda fun to play with. An easy way to test is to take a partial screen cap to the pasteboard (shift-ctrl-cmd-4) and blit it in your pygame app. You should be able to bring in anything from the pasteboard that NSImage can load: icons, jpeg, png, pdf (!), tiff, etc. -bob
Re: [pygame] pygame.scrap bitmap stuff
Oh, a clipboard, lovely.Thanks!On 7/12/06, René Dudfield [EMAIL PROTECTED] wrote: Sounds good!Nice one.Is libtiff linked to imageext on macosx?If so, I think there is asave as tiff function in there which I could add.I think I could make it save to bmp in memory fairly easily.I'll need to change the save signature to take a name hint(like load does).eg.f = someStringIOclass()surf.save(f, bla.bmp)On 7/13/06, Bob Ippolito [EMAIL PROTECTED] wrote: I went ahead and implemented (read: prototyped) scrap bitmap support for Mac OS X, but the implementation is terribly inefficient. Pygame surfaces aren't terribly accessible from Python outside of surfarray (which I didn't want to depend on). Going from a Surface to the pasteboard is particularly painful in this implementation: 1. Surface to PNG (on disk!) 2. NSImage from on-disk PNG 3. NSImage to TIFF 4. TIFF to pasteboard The absolute fastest route (which doesn't exist in pygame) would be: 1. Surface to TIFF (in memory) 2. TIFF to pasteboard pygame doesn't have any TIFF writing capability at all, a compromise here would to at least avoid hitting the disk and zlib: 1. Surface to BMP (in memory) 2. BMP to NSImage 3. NSImage to TIFF 4. TIFF to pasteboard Unfortunately this also isn't currently possible because pygame doesn't support BMP writing anymore (or so it seems from a quick look at the code) and it definitely won't do it to memory instead of disk. Cocoa does not support TGA. Going the other way is also gnarly, but mostly because I didn't want to think more than I had to: 1. pasteboard to NSImage 2. NSImage to TIFF 3. TIFF to NSBitmapImageRep 4. NSBitmapImageRep to BMP (in memory) 5. Surface from BMP Getting a NSBitmapImageRep directly from the NSImage (steps 2+3 combined) is definitely possible without going between TIFF, but I was too lazy to think about what that would do for vector graphics (e.g. PDF on the pasteboard) and screen representations. It's not necessarily true that NSImage will have a NSBitmapImageRep cached already. Going from NSBitmapImageRep to a Surface without hitting BMP is possible, but there's a bunch of formats the NSBitmapImageRep could be in and I didn't want to think about that either :) In any case, pygame.scrap is 100% implemented on Mac OS X, and it's kinda fun to play with. An easy way to test is to take a partial screen cap to the pasteboard (shift-ctrl-cmd-4) and blit it in your pygame app. You should be able to bring in anything from the pasteboard that NSImage can load: icons, jpeg, png, pdf (!), tiff, etc. -bob -- Andrew Ulysses Bakerfailrate
Re: [pygame] pygame.scrap bitmap stuff
Just libpng and libjpg like everywhere else.. there's no code in imageext that knows how to do TIFF, so I don't see why it should link to libtiff. That said, it *could* link to libtiff if we added that functionality. I don't have any problem adding that dependency. -bob On Jul 12, 2006, at 8:51 PM, René Dudfield wrote: Sounds good! Nice one. Is libtiff linked to imageext on macosx? If so, I think there is a save as tiff function in there which I could add. I think I could make it save to bmp in memory fairly easily. I'll need to change the save signature to take a name hint(like load does). eg. f = someStringIOclass() surf.save(f, bla.bmp) On 7/13/06, Bob Ippolito [EMAIL PROTECTED] wrote: I went ahead and implemented (read: prototyped) scrap bitmap support for Mac OS X, but the implementation is terribly inefficient. Pygame surfaces aren't terribly accessible from Python outside of surfarray (which I didn't want to depend on). Going from a Surface to the pasteboard is particularly painful in this implementation: 1. Surface to PNG (on disk!) 2. NSImage from on-disk PNG 3. NSImage to TIFF 4. TIFF to pasteboard The absolute fastest route (which doesn't exist in pygame) would be: 1. Surface to TIFF (in memory) 2. TIFF to pasteboard pygame doesn't have any TIFF writing capability at all, a compromise here would to at least avoid hitting the disk and zlib: 1. Surface to BMP (in memory) 2. BMP to NSImage 3. NSImage to TIFF 4. TIFF to pasteboard Unfortunately this also isn't currently possible because pygame doesn't support BMP writing anymore (or so it seems from a quick look at the code) and it definitely won't do it to memory instead of disk. Cocoa does not support TGA. Going the other way is also gnarly, but mostly because I didn't want to think more than I had to: 1. pasteboard to NSImage 2. NSImage to TIFF 3. TIFF to NSBitmapImageRep 4. NSBitmapImageRep to BMP (in memory) 5. Surface from BMP Getting a NSBitmapImageRep directly from the NSImage (steps 2+3 combined) is definitely possible without going between TIFF, but I was too lazy to think about what that would do for vector graphics (e.g. PDF on the pasteboard) and screen representations. It's not necessarily true that NSImage will have a NSBitmapImageRep cached already. Going from NSBitmapImageRep to a Surface without hitting BMP is possible, but there's a bunch of formats the NSBitmapImageRep could be in and I didn't want to think about that either :) In any case, pygame.scrap is 100% implemented on Mac OS X, and it's kinda fun to play with. An easy way to test is to take a partial screen cap to the pasteboard (shift-ctrl-cmd-4) and blit it in your pygame app. You should be able to bring in anything from the pasteboard that NSImage can load: icons, jpeg, png, pdf (!), tiff, etc. -bob
