Re: [pygame] peer-to-peer networked games
Rendering engine is irrelevant... You could use pygame, OpenGL, PySoy or even Direct3D if you wanted. The trick is writing the network part, the gfx just has to represent that... On Wed, Nov 10, 2010 at 3:24 AM, Miriam English wrote: > Interesting. Thank you Gumm. > > I haven't tried ODE physics library for a while. It worked fine under > MSWindows, but I had tremendous problems compiling it under Linux. I should > have another look at it. I wonder why they don't use Bullet like Blender > does. Hmmm. > > While it seems pysoy isn't specifically aimed at peer-to-peer, there are > hints that it could be used that way. Otherwise it seems to use a > cloud-based server and ordinary clients, so would still end up with the same > old bottlenecks and limitations, I think. > > Thanks for the pointer, > >- Miriam > > B W wrote: > >> If you can work with OpenGL, might keep your eye on PySoy. >> >> http://www.pysoy.org/ >> >> Gumm >> >> On Sat, Nov 6, 2010 at 2:48 AM, Miriam English >> > m...@miriam-english.org>> wrote: >> >>Wow! Thanks Kris. >> >>I hadn't heard of this one. Croquet sounds very interesting. I >>didn't understand it all in my first quick read-through, but I'll >>look much more carefully at it after I've finished my story. I've >>built virtual worlds before and this seems like a great environment >>to work in. Fancy being able to edit source and have the >>modifications appear in realtime without stopping and reloading! >>Neat. Pity it's not python though. :) >> >>Yes, I've had a look at Minecraft and was very impressed with its >>cuteness, even though it looks very basic. I had no idea it was >>intended to let servers to share data like that. That's nearly p2p >>right there. All it takes is for every client machine to also be a >>server. (Well, not quite, but almost...) >> >>Cheers, >> >> - Miriam >> >> >>Kris Schnee wrote: >> >>On 2010.11.5 8:09 PM, Miriam English wrote: >> >>Okay, I've found some stuff that I hadn't heard of before >>that some of >>you folks might be interested in: >> >> >>http://en.wikipedia.org/wiki/Croquet_project >>The Croquet Project seems to be similar to that. The indie game >>Minecraft is apparently going to have servers linked so that a >>character can walk from one server's world to another. >> >>A question that Croquet brings up is how to spread out the >>computation between computers. There's a project called >>OpenSimulator that sets up independent servers for the game >>Second Life, but I believe that works on a more standard >>client/server arrangement. Croquet is set up so that the >>calculation is done on every machine, which is inefficient but >>ensures every machine does the same thing... at the cost of the >>system being as slow as the slowest PC, if I understand right. >>At the other end of the scale, with Minecraft it'd probably be >>possible for one server to let players easily get hoards of >>valuable items, then try to walk onto a higher-difficulty server >>with items intact. So for a game you'd have to think about which >>machine enforces the rules against cheaters, and the more >>centralized it is, the more it's like the client/server setup. >> >>If someone wants to test out building a Python P2P gaming >>system, don't assume it has to be for real-time 3D games! Why >>not try making a P2P text MU? >> >> >> >>-- If you don't have any failures then you're not trying hard >> enough. >> - Dr. Charles Elachi, director of NASA's Jet Propulsion Laboratory >>- >>Website: http://miriam-english.org >>Blog: http://miriam_e.livejournal.com >> >> >> > -- > If you don't have any failures then you're not trying hard enough. > - Dr. Charles Elachi, director of NASA's Jet Propulsion Laboratory > - > Website: http://miriam-english.org > Blog: http://miriam_e.livejournal.com >
Re: [pygame] Surface blitting not effective
Change the surface convert to convert_alpha() and filling will work again. Since you are just converting the best it can do are full surface alpha and/or colorkeys On Sun, Oct 10, 2010 at 7:21 AM, Julian Marchant wrote: > Ok, one major problem solved, and after much investigating I was able to > figure out why (I just wish you would have mentioned that I was blitting in > relation to the screen, when I should have been blitting in relation to the > surface I was blitting to ;) ). menu items are showing up. But the > transparency issue doesn't seem to be solved at all. Adjusting alpha seems > to adjust brightness, not transparency (i.e. smaller number make it closer > to black, higher values make it closer to the specified color). > > >
Re: [pygame] roguelike question
Just a quick look. In move_test.py, when you check for action 'd' - are you sure the one tiles bottom is really the same as the other's top - not adjacent? Perhaps try: new_tile.rect.top-tile.rect.bottom < 1 On Mon, Oct 4, 2010 at 1:05 PM, Michael Schultz wrote: > Hi, new to the list, but not the language. I'm completely at home with > Python :) Right now, I'm coding a roguelike game, and am having trouble > getting the map to update changes. I've got movement and collision > detection, but for whatever reason, the changes to the map are not being > updated. > > When the player is up against a "d" tile, and presses the key "d", the "d" > should be replaced with a "." tile, but nothing's happening. > > Here's the files: > > ===move_test.py > http://pastebin.com/fmz491K9 > > ===Actions.py > http://pastebin.com/TUm3mv3b > > ===Terrain.py > http://pastebin.com/SXR8LqyL > > ===Common.py > http://pastebin.com/YhN2Cszu > > ===Imp.py > http://pastebin.com/2g4Yz469 > > > I'm pretty sure the problem is in the first two, but I didn't want to miss > something. > I know I'm slightly crazy for trying this, but what am I doing wrong?? > (Thanks for the help, too!) > > ~Mike >
Re: [pygame] "Pyttle.net"?
I don't have the time computer with me to test anything right now. But if you care, I did make an irc bot using twisted once, that supports mods that run, so a lot of your functions could simply be mods. I can't recall how far we made it on the project, but we did run it during pyweek once and worked fairly well :) http://code.google.com/p/compobot/ <http://code.google.com/p/compobot/>In reference to your chat log, what I did was use an online "get_my_hostname" site and parsed the data, then you could simply test whether your host binds to that port or not... sock = socket.socket(...) try: sock.bind(...) print "we're good to go!" except: print "dang, we can't do it" On Wed, Sep 22, 2010 at 2:03 AM, Thiago Chaves wrote: > Short update: > > I'm posting a first draft version of "Pyttlebot" and I would just like to > post it here before I scrap the thing. Thanks to RB[0] I was able to give > consideration to the possibility of one not being able to host a game though > I'm on the workings of finding out what to do about it. I'm leaving it > running on irc.freenode.net #pyttle.net for the following 12 hours or so, > with possible interruptions if problems occur. > > As the next thing I'm gonna do is use a Pygame GUI library to create a > minimalist IRC client that automatically connects to irc.freenode.net and > joys #pyttle.net and supports some basic functionalities such as chatting > and private messages. I'll worry about the bot and protocol again once that > is done. > > What needs to change in the bot: > * Instead of the user informing the bot "I can host" or "I can't host", the > bot itself should attempt connection to the user's machine and verify if the > user can host, unless the user specifies a lack of desire for hosting a > game. > * Its code should look prettier than it looks now, seriously. If there's > any hope for me to get people using it for their own games. > * It should respond to channel messages directed at it, rather than having > the person wondering on how to use it. > * Accept registering of dedicated servers. The bot has registered dedicated > servers, then it doesn't need to wait for a hosting-capable user to show up, > but it should ask the dedicated server if there's a free game slot available > before announcing the game to the players. > > Alex, if you're interested in building the bot, could you check the code > (or visit it and test its behavior) and get a new one in the workings? You > can change the grammar / syntax of the bot, but make it easy to parse by the > client. > > I would say that if the bot accomplishes this much, and the client is able > to make these requests to the bot and react to a match announcement by > launching a game, then Milestone 1 has been achieved. =) > > If anyone is interested in trying it out the bot is on #pyttle.net at > irc.freenode.org. To get instructions from it, you need to enter a private > conversation and say something random. > > -Thiago > > PS: In case anyone is wondering why trying a connection is necessary, I'm > also posting a log from a conversation I had in #twisted. > > > On Mon, Sep 20, 2010 at 9:07 PM, RB[0] wrote: > >> Everything except the actual code and the "RB[0]'s design docs" wiki page >> on here is outdated, but: >> >> http://code.google.com/p/galaxymageredux/ >> >> Cheers, and good luck :) >> >> >> On Mon, Sep 20, 2010 at 1:02 PM, Thiago Chaves wrote: >> >>> Can you provide a link to your library, RB[0]? I googled Galaxymage but I >>> keep bumping into galaxymage.org, and the address is cybersquatted from >>> here. >>> >>> I understand what you said about the routing issues, and that's quite >>> true and I run into that problem quite often and shamefully enough, I >>> haven't considered that. >>> >>> I'm pushing on anyways and finishing a first draft of the first bot (to >>> which I won't give that much more thought if someone else is willing to take >>> the job) and then I'll get a minimalist client and network game going. But >>> thanks a lot for the input. =) >>> >>> -Thiago >>> >>> >>> On Mon, Sep 20, 2010 at 7:41 PM, RB[0] wrote: >>> >>>> Hmm, perhaps I should explain better. >>>> The users/hosts wouldn't interact on the master server, except to >>>> connect to game servers, start servers and possibly chat. >>>> The game servers would be programmed by the games using them, so either >>&g
Re: [pygame] "Pyttle.net"?
Everything except the actual code and the "RB[0]'s design docs" wiki page on here is outdated, but: http://code.google.com/p/galaxymageredux/ Cheers, and good luck :) On Mon, Sep 20, 2010 at 1:02 PM, Thiago Chaves wrote: > Can you provide a link to your library, RB[0]? I googled Galaxymage but I > keep bumping into galaxymage.org, and the address is cybersquatted from > here. > > I understand what you said about the routing issues, and that's quite true > and I run into that problem quite often and shamefully enough, I haven't > considered that. > > I'm pushing on anyways and finishing a first draft of the first bot (to > which I won't give that much more thought if someone else is willing to take > the job) and then I'll get a minimalist client and network game going. But > thanks a lot for the input. =) > > -Thiago > > > On Mon, Sep 20, 2010 at 7:41 PM, RB[0] wrote: > >> Hmm, perhaps I should explain better. >> The users/hosts wouldn't interact on the master server, except to connect >> to game servers, start servers and possibly chat. >> The game servers would be programmed by the games using them, so either >> one server = one game, or like in GMR, one game server hosts multiple >> games... >> >> >> On Mon, Sep 20, 2010 at 11:39 AM, RB[0] wrote: >> >>> Well, this is something we had an issue with in GMR. >>> Not everyone can "host" a game, if you have a router like mine is it is >>> quite nearly impossible to create a server that others can connect to. >>> The way we planned to do it in GMR, was to have people create their own >>> server, and register it with the master server. >>> The master server in turn would check to ensure the game server was >>> really visible, then load up it's data (game, version, max users/games, >>> password, etc.) and provide that to people wanting to use the service. >>> >>> You could do this via irc, but I think a simple PB solution would be >>> simpler and more extensible. But if you make this up and it takes off we'll >>> definitely at least support it in GMR :) >>> >>> >>> On Mon, Sep 20, 2010 at 12:37 AM, Thiago Chaves wrote: >>> >>>> Missing end of sentence here: a default bot could/should exist for use >>>> by developers with no interest in customizing it for their own game, or to >>>> be extended by developers who want to add other features specific to their >>>> game. >>>> >>>> >>>> On Mon, Sep 20, 2010 at 8:11 AM, Thiago Chaves wrote: >>>> >>>>> It's very cool to hear about two other people so soon after the initial >>>>> post interested in getting this going. =) >>>>> >>>>> For purposes of not commenting about how much I'd like to get a better >>>>> name for the thing everytime I mention it, I'm gonna use "Pyttle.net" on >>>>> the >>>>> email, but leave here stated that I'm not suggesting this as a name for >>>>> the >>>>> system. =P >>>>> >>>>> So, things I was thinking of: >>>>> >>>>> 0. Users have a collection of more than zero games that support getting >>>>> started by Pyttle.net / having matches started by. >>>>> 1. Chatting between users, emoting actions, registering and confirming >>>>> of usernames is handled by the chosen protocol and the chosen protocol's >>>>> servers. >>>>> 2. The client connects automatically to the chat server(s) and joins >>>>> channels according to the collection of Pyttle.net-capable games present >>>>> in >>>>> the user's machine. #fog-of-war-chess, #galaxymage, #ssof, for instance. >>>>> 3. Each game/channel has it's own bot running in there, which deals >>>>> with negotiation of matches, scorekeeping (if there's any interest in the >>>>> game for that), messages-of-the-day, etc. A default bot could/should. >>>>> 4. Once a match has been arranged, the bot informs all involved clients >>>>> that the match is gonna start, who are the players and in which IP's they >>>>> can be found. >>>>> 5. Once a client has been informed of a match, it takes care of >>>>> launching the game and it deals with the network connections and data on >>>>> its >>>>> own accord. >>>>> 6. Once a match is over, if there's interest by the developers to have >>>>> some scoreboard, the clients inform the results back to the bot, who logs >>>>> it >>>>> and whatever. >>>>> >>>>> I'm totally open to negotiating/discarding/changing any/all of these. I >>>>> want something like a game-agnostic "battle.net" to happen. =) >>>>> >>>>> Opinions? What is missing? What could be added? What is poorly >>>>> explained? >>>>> >>>>> -Thiago >>>>> >>>>> >>>>> On Sun, Sep 19, 2010 at 9:25 PM, Alex Nordlund < >>>>> deep.alexan...@gmail.com> wrote: >>>>> >>>>>> On Sun, Sep 19, 2010 at 7:22 PM, RB[0] wrote: >>>>>> > I've been reading Twisted documentation and this sounds like a >>>>>> > less-than-guru-level thing to build on top of the IRC protocol. >>>>>> >>>>>> I'd like to contribute to this project! >>>>>> >>>>>> I enjoy IRC and have been building bots that play games over IRC for a >>>>>> while. >>>>>> >>>>>> --- >>>>>> //Alex >>>>>> >>>>> >>>>> >>>> >>> >> >
Re: [pygame] "Pyttle.net"?
Hmm, perhaps I should explain better. The users/hosts wouldn't interact on the master server, except to connect to game servers, start servers and possibly chat. The game servers would be programmed by the games using them, so either one server = one game, or like in GMR, one game server hosts multiple games... On Mon, Sep 20, 2010 at 11:39 AM, RB[0] wrote: > Well, this is something we had an issue with in GMR. > Not everyone can "host" a game, if you have a router like mine is it is > quite nearly impossible to create a server that others can connect to. > The way we planned to do it in GMR, was to have people create their own > server, and register it with the master server. > The master server in turn would check to ensure the game server was really > visible, then load up it's data (game, version, max users/games, password, > etc.) and provide that to people wanting to use the service. > > You could do this via irc, but I think a simple PB solution would be > simpler and more extensible. But if you make this up and it takes off we'll > definitely at least support it in GMR :) > > > On Mon, Sep 20, 2010 at 12:37 AM, Thiago Chaves wrote: > >> Missing end of sentence here: a default bot could/should exist for use by >> developers with no interest in customizing it for their own game, or to be >> extended by developers who want to add other features specific to their >> game. >> >> >> On Mon, Sep 20, 2010 at 8:11 AM, Thiago Chaves wrote: >> >>> It's very cool to hear about two other people so soon after the initial >>> post interested in getting this going. =) >>> >>> For purposes of not commenting about how much I'd like to get a better >>> name for the thing everytime I mention it, I'm gonna use "Pyttle.net" on the >>> email, but leave here stated that I'm not suggesting this as a name for the >>> system. =P >>> >>> So, things I was thinking of: >>> >>> 0. Users have a collection of more than zero games that support getting >>> started by Pyttle.net / having matches started by. >>> 1. Chatting between users, emoting actions, registering and confirming of >>> usernames is handled by the chosen protocol and the chosen protocol's >>> servers. >>> 2. The client connects automatically to the chat server(s) and joins >>> channels according to the collection of Pyttle.net-capable games present in >>> the user's machine. #fog-of-war-chess, #galaxymage, #ssof, for instance. >>> 3. Each game/channel has it's own bot running in there, which deals with >>> negotiation of matches, scorekeeping (if there's any interest in the game >>> for that), messages-of-the-day, etc. A default bot could/should. >>> 4. Once a match has been arranged, the bot informs all involved clients >>> that the match is gonna start, who are the players and in which IP's they >>> can be found. >>> 5. Once a client has been informed of a match, it takes care of launching >>> the game and it deals with the network connections and data on its own >>> accord. >>> 6. Once a match is over, if there's interest by the developers to have >>> some scoreboard, the clients inform the results back to the bot, who logs it >>> and whatever. >>> >>> I'm totally open to negotiating/discarding/changing any/all of these. I >>> want something like a game-agnostic "battle.net" to happen. =) >>> >>> Opinions? What is missing? What could be added? What is poorly explained? >>> >>> -Thiago >>> >>> >>> On Sun, Sep 19, 2010 at 9:25 PM, Alex Nordlund >> > wrote: >>> >>>> On Sun, Sep 19, 2010 at 7:22 PM, RB[0] wrote: >>>> > I've been reading Twisted documentation and this sounds like a >>>> > less-than-guru-level thing to build on top of the IRC protocol. >>>> >>>> I'd like to contribute to this project! >>>> >>>> I enjoy IRC and have been building bots that play games over IRC for a >>>> while. >>>> >>>> --- >>>> //Alex >>>> >>> >>> >> >
Re: [pygame] "Pyttle.net"?
Well, this is something we had an issue with in GMR. Not everyone can "host" a game, if you have a router like mine is it is quite nearly impossible to create a server that others can connect to. The way we planned to do it in GMR, was to have people create their own server, and register it with the master server. The master server in turn would check to ensure the game server was really visible, then load up it's data (game, version, max users/games, password, etc.) and provide that to people wanting to use the service. You could do this via irc, but I think a simple PB solution would be simpler and more extensible. But if you make this up and it takes off we'll definitely at least support it in GMR :) On Mon, Sep 20, 2010 at 12:37 AM, Thiago Chaves wrote: > Missing end of sentence here: a default bot could/should exist for use by > developers with no interest in customizing it for their own game, or to be > extended by developers who want to add other features specific to their > game. > > > On Mon, Sep 20, 2010 at 8:11 AM, Thiago Chaves wrote: > >> It's very cool to hear about two other people so soon after the initial >> post interested in getting this going. =) >> >> For purposes of not commenting about how much I'd like to get a better >> name for the thing everytime I mention it, I'm gonna use "Pyttle.net" on the >> email, but leave here stated that I'm not suggesting this as a name for the >> system. =P >> >> So, things I was thinking of: >> >> 0. Users have a collection of more than zero games that support getting >> started by Pyttle.net / having matches started by. >> 1. Chatting between users, emoting actions, registering and confirming of >> usernames is handled by the chosen protocol and the chosen protocol's >> servers. >> 2. The client connects automatically to the chat server(s) and joins >> channels according to the collection of Pyttle.net-capable games present in >> the user's machine. #fog-of-war-chess, #galaxymage, #ssof, for instance. >> 3. Each game/channel has it's own bot running in there, which deals with >> negotiation of matches, scorekeeping (if there's any interest in the game >> for that), messages-of-the-day, etc. A default bot could/should. >> 4. Once a match has been arranged, the bot informs all involved clients >> that the match is gonna start, who are the players and in which IP's they >> can be found. >> 5. Once a client has been informed of a match, it takes care of launching >> the game and it deals with the network connections and data on its own >> accord. >> 6. Once a match is over, if there's interest by the developers to have >> some scoreboard, the clients inform the results back to the bot, who logs it >> and whatever. >> >> I'm totally open to negotiating/discarding/changing any/all of these. I >> want something like a game-agnostic "battle.net" to happen. =) >> >> Opinions? What is missing? What could be added? What is poorly explained? >> >> -Thiago >> >> >> On Sun, Sep 19, 2010 at 9:25 PM, Alex Nordlund >> wrote: >> >>> On Sun, Sep 19, 2010 at 7:22 PM, RB[0] wrote: >>> > I've been reading Twisted documentation and this sounds like a >>> > less-than-guru-level thing to build on top of the IRC protocol. >>> >>> I'd like to contribute to this project! >>> >>> I enjoy IRC and have been building bots that play games over IRC for a >>> while. >>> >>> --- >>> //Alex >>> >> >> >
Re: [pygame] "Pyttle.net"?
Cool, nice to hear that :D Indeed - it is actually a side-project for galaxymage that we are continuing, but perhaps we could fork that into something more generic and just implement GalaxyMage with it. If your interested just let me know, otherwise I can try and help with twisted if you like, since I've used both it's irc parts and the PB for our Pyweek entry. Cheers, Matt On Sun, Sep 19, 2010 at 1:19 PM, Thiago Chaves wrote: > It was actually your entry that inspired me to write about this, Matt. =) > > It doesn't need to be IRC, but my initial idea was to pick an existing chat > protocol for which servers and chat room names are freely available to > anyone. > > Anyways, through such thing one could skip the "building the UI for > inputting peer IP addresses, talking about connection errors, negotiating > matches, making a chat room for the gamers" part of building a network game. > > And as a bonus, that could result in an increase of network-capable pyweek > entries. I'd love to have my next entry for Pyweek be network-capable if I > can skip past through the "building the UI within a week" part. =P > > -Thiago > > > On Sun, Sep 19, 2010 at 9:11 PM, RB[0] wrote: > >> Actually that sounds similar to a project I'm considering starting. >> During Pyweek we made a networked game, and were going to have a master >> server where you can register your own servers, and other can find them. >> >> It would be fairly simple to create and other games could use it... >> I wasn't thinking about using irc though. >> >> But yes, definitely sounds feasible... >> >> Matt >> >> >> On Sun, Sep 19, 2010 at 12:20 PM, Thiago Chaves wrote: >> >>> Email vaguely related to my first one. >>> >>> How about coming up with a "Pyttle.net" client (and server) (and not with >>> that name), which would basically be an IRC chat that launches networked >>> games between people? Games that utilized it could register to the thing >>> locally so the chat knows which games you have that support it and the >>> client could launch the games with the appropriate command-line arguments to >>> get a game between people going. (or maybe "importing" the game and >>> launching it from withing the client, if there's a game skeleton provided) >>> >>> The server-side could also support assigning random matches and ladder >>> games. >>> >>> I've been reading Twisted documentation and this sounds like a >>> less-than-guru-level thing to build on top of the IRC protocol. >>> >>> Does it sound feasible? >>> >>> -Thiago >>> >> >> >
Re: [pygame] "Pyttle.net"?
Actually that sounds similar to a project I'm considering starting. During Pyweek we made a networked game, and were going to have a master server where you can register your own servers, and other can find them. It would be fairly simple to create and other games could use it... I wasn't thinking about using irc though. But yes, definitely sounds feasible... Matt On Sun, Sep 19, 2010 at 12:20 PM, Thiago Chaves wrote: > Email vaguely related to my first one. > > How about coming up with a "Pyttle.net" client (and server) (and not with > that name), which would basically be an IRC chat that launches networked > games between people? Games that utilized it could register to the thing > locally so the chat knows which games you have that support it and the > client could launch the games with the appropriate command-line arguments to > get a game between people going. (or maybe "importing" the game and > launching it from withing the client, if there's a game skeleton provided) > > The server-side could also support assigning random matches and ladder > games. > > I've been reading Twisted documentation and this sounds like a > less-than-guru-level thing to build on top of the IRC protocol. > > Does it sound feasible? > > -Thiago >
Re: [pygame] GSoC Article for PSF and my blog
There is a 2010 page as well, the link appears to have been fixed... I haven't been involved in GSOC before either, but this is the pygame mailing list so I don't think he is actually asking you personally Neilen, but the Pygame community. I believe you should speak with Marcus, he seems the most active in GSOC, but I dunno... On Thu, Sep 16, 2010 at 11:10 AM, Mike Driscoll wrote: > Hi Neilen, > > In the Development section on that link, it lists the following: "PyGame > has their own ideas page" (5th down). Of course, it links to the 2009 page > on PyGame's site: http://pygame.org/wiki/gsoc2009ideas > > Not sure how it got included on the 2010 wiki page though. Sorry to bother > you guys. > > - Mike > > > On Thu, Sep 16, 2010 at 9:17 AM, Neilen Marais wrote: > >> Hi Mike, >> >> On Thu, Sep 16, 2010 at 4:08 PM, Mike Driscoll >> wrote: >> > Hi, >> > >> > I am working on an article for the Python Software Foundation's blog, >> > http://pyfound.blogspot.com/, about the various Python projects that >> were >> > worked on during this year's Google Summer of Code program. They want me >> to >> > write up something about what projects were worked on and what the >> results >> > were. I found your project information here: >> > http://wiki.python.org/moin/SummerOfCode/2010 >> >> I'm not sure how you manage to find my project there, since I have no >> such project. I have never been involved with GSOC in any way, nor am >> I really qualified to be a mentor :) I have posted in/on various >> python formums/mailing lists though, so presumably it's a case of >> mistaken identity! >> >> Best regards >> Neilen >> > > > > -- > - > Mike Driscoll > > Blog: http://blog.pythonlibrary.org >
Re: [pygame] super surface... a surface made up of many smaller surfaces
The biggest problem with that is that pygame limits the size of any one surface - at least for me. I can't remember what it was but somewhere around 16k x 16k pixels? On Wed, Mar 10, 2010 at 7:19 AM, Nikhil Murthy wrote: > This is not in the least meant to be a serious solution for super surfaces, > it is just an idea I had and tried out for the fun of it. > > import pygame > > def supersurface(*surfaces): > """*(surface, rect) -> supersurface, *subsurfaces > > Takes surfaces with their rectangles and forms a surface made up of all > of them and the subsurfaces which represent the originals""" > left=min((rect.left for _, rect in surfaces)) > right=max((rect.right for _, rect in surfaces)) > top=min((rect.top for _, rect in surfaces)) > bottom=max((rect.bottom for _, rect in surfaces)) > surf=pygame.Surface((right-left, bottom-top)) > subs=[surf] > for surface, rect in surfaces: > tl=(rect.left-left, rect.top-top) > surf.blit(surface, tl) > sr=pygame.Rect(tl, rect.size) > subs.append(surf.subsurface(sr)) > return subs > > if __name__ == '__main__': > pygame.init() > screen=pygame.display.set_mode((600,600)) > surf1=pygame.Surface((300,300)) > rect1=surf1.get_rect() > surf1.fill((0,0,255)) > surf2=pygame.Surface((300,300)) > rect2=surf2.get_rect() > rect2.left=300 > surf2.fill((0,255,0)) > surf3=pygame.Surface((300,300)) > rect3=surf3.get_rect() > rect3.top=300 > surf3.fill((255,0,0)) > surf, surf1, surf2, surf3=supersurface((surf1, rect1), (surf2, rect2), > (surf3, rect3)) > clock=pygame.time.Clock() > fade=255 > while fade: > clock.tick(15) > fade-=1 > for event in pygame.event.get(): > if event.type==pygame.QUIT: > fade=0 > screen.blit(surf, (0,0)) > pygame.display.flip() > surf1.fill((0,0,fade)) > surf2.fill((0,fade,0)) > surf3.fill((fade,0,0)) > pygame.draw.circle(surf, (255-fade,255-fade,255-fade), (300,300), > 20) > > > > On Tue, Mar 9, 2010 at 3:39 PM, René Dudfield wrote: > >> On Sun, Mar 7, 2010 at 6:47 PM, B W wrote: >> > >> > >> > On Sat, Mar 6, 2010 at 11:44 AM, Kris Schnee >> wrote: >> >> >> >> On 3/5/2010 10:40 AM, René Dudfield wrote: >> >>> >> >>> However, sometimes we would like to operate on a whole bunch of >> >>> smaller surfaces stuck together. >> >> >> >> I've done several projects using a full-screen scrolling tilemap. That >> is, >> >> sprites walking around on a blanket of 2D tiles drawn from an array as >> big >> >> as 1000x1000 referencing a set of 50x50 tiles. That wasn't practical to >> do >> >> using a Pygame Surface, due to the size, so each frame the system >> figured >> >> out the range of all visible tiles (based on the POV character's >> location) >> >> and drew those. It wasn't very efficient, but it did work, and it's an >> >> example of a surface built from many actual Surface objects. (Will link >> to >> >> code if you want.) >> >> >> > I did something very similar with Gummworld. The supersurface was not a >> > single Pygame surface, rather a virtual surface made of a 2D array of >> > sprites each with its own image. The Pygame drawing surface was the >> visible >> > display; only I found that Group.draw()-ing all the terrain sprites and >> > allowing Pygame to automatically crop them was in larger cases more >> > efficient than cropping the drawing scope in Python. Still, it did >> indeed >> > waste memory having all those sprites, each with their own image, >> outside >> > the display area. The level design was rectangular, and if the map is >> > irregular then large portions of the supersurface could possibly have >> many >> > unused sprites; which led to a crude sparse map implementation, where an >> > array cell with a None value would be ignored. It's a simple paradigm in >> > which the special cases tend to center around conserving memory and CPU. >> > >> >> >> cool, that sounds good. >> >> > That initial attempt got me thinking about a room paradigm. A level is >> > analogous to a building or a floor with rooms connected by exits. Rooms >> > don't necessarily have walls, and exits are not necessarily visible. >> They >> > are just internal geographic and navigational elements, respectively. An >> > exit links two rooms. Exits can be visible objects such as a door or >> portal >> > or an invisible line on the ground. Using an exit changes the >> interactive >> > context from room A to room B. If you choose so, your room could scroll. >> > With some drawing savvy neighboring rooms could scroll seamlessly. The >> > player might not even notice that an exit was used and there was a room >> > change. >> > >> > Though the room paradigm seems elegant to me and potentially >> > memory-efficient, it presents its own significant challenges: resource >> > management (real-time loading and garbage cleanup); game hiccups from
Re: [pygame] Unprintable characters
well, you could filter by a list of allowed characters - string.printable for instance so: str(event.unicode) in string.printable: good might need to wrap that in a try:except block in case of weird keys though - not sure... On Sun, Feb 28, 2010 at 4:56 AM, Chris McCormick wrote: > Hi, > > Now that the key event returns the unicode character pressed, I want to > detect > when a user has pressed an unprintable unicode character (e.g. up arrrow > key). > Does anyone know the e.key or e.unicode ranges I need to filter on? > > Chris. > > --- > http://mccormick.cx >
Re: [pygame] www.pygame.org down ?
Says the server is being upgraded... On Wed, Jan 13, 2010 at 12:42 AM, Horst JENS wrote: > i can not reach www.pygame.org > > Is the website down or moved to another url ? > > -Horst > > -- > Horst JENS > horst.j...@spielend-programmieren.at > http://www.spielend-programmieren.at >
Re: [pygame] First / Third person shooter?
I see someone mentioned PYGGEL. Robocalypto is rather outdated and unclear - but if you want something simple to get going you probably can't beat it - I'd check out the examples/tutorials that come with it before the demo game first though... On Sat, Nov 28, 2009 at 1:29 AM, Ian Mallett wrote: > On Fri, Nov 27, 2009 at 7:05 PM, Vitor Bosshard wrote: > >> Do you have a link for that? Googling didn't turn up the python >> version you mention. >> > I started with the ones on pygame.org: > http://www.pygame.org/gamelets/games/nehe1-10.zip >
Re: [pygame] Font-Related Segfault
Why not just let Pygame load the font itself? On Mon, Nov 23, 2009 at 2:38 PM, Bryce Schroeder wrote: > (My apologies if this is a double-post. I didn't get a copy of the > message or see it in the archive, so I'm trying again.) > > I have a pygame program that worked in the past on both Linux and > Windows, but now results in a segfault, at least on Linux. (I can't > test it on Windows.) > The segfault occurs in this code: > > class Font(Resource): > > def pygame_font(self,size): > return pygame.font.Font(StringIO.StringIO(self.parts['font']), > size) # Segfaults here > > > self.parts['font'] is a string containing a truetype font loaded from > a file. I have checked that the string contains the file like it is > supposed too. Any suggestions? >
Re: [pygame] Need names and nationalities for AI playes in new sport-game
Do you want multiple from each country or only one? If you want a couple: Matthew Roe Wisconsin USA On Thu, Nov 12, 2009 at 3:37 PM, Frank Van Geirt wrote: > Frank Van Geirt - Belgium > > Regards > > > > Hi fellow pygame developers! > > I'm developing a sports game. It's a fictive sport played one-on-one, > on ice against another human player or against a rather advanced AI. > > As part of the game it is possible to create a career in the World > Series against 40 (or so) AI controlled players. > > I started to search the net to find inspiration for names and > nationalities to the AI-players. But then I thought it would be much > nicer to use the names and nationalities of pygame developers instead > of just using fictive names. > > All AI-players will have different skill levels wich is randomly set > in the begining of a new World Series career. In one career your named > character will be the best in the world, and in another it might be a > rookie in Division 4. > > The game will be released as Freeware for both Linux and Windows. The > source code will (as allways for my projects) be available once the > game is done. > > If you wan't your name to apear as a AI-player in the game, please > send me your name (first + last) and your nationality. > > Best Regards > /John Eriksson > http://arainyday.se > > >
Re: [pygame] Font not initializing?
I don't see pygame.init() or pygame.font.init() in there anywhere...
On Sat, Oct 24, 2009 at 7:57 PM, james carnell wrote:
> I'm new, but this is giving me problems. I'm on Ubuntu 9.04. I have tried
> copy pasting other source codes with the same result. Should I just make my
> own Font class from spites?
>
>
> import pygame
> ===
> def test():
> screen = pygame.display.set_mode((640, 480))
> background = pygame.Surface(screen.get_size())
> background = background.convert()
> background.fill((0, 0, 0))
>
> font = pygame.font.get_default_font()
> theFont = pygame.font.SysFont(font, 40)
> msg = theFont.render("Hello World!",1,(255, 0, 255))
>
> screen.blit(background, (0, 0))
> screen.blit(msg, (20, 100))
> pygame.display.flip()
> done = False
> while not done:
> for event in pygame.event.get():
> if event.type == pygame.QUIT:
> done = True
>
> test()
>
> /usr/lib/python2.6/dist-packages/pygame/sysfont.py:139: DeprecationWarning:
> os.popen3 is deprecated. Use the subprocess module.
> flin, flout, flerr = os.popen3('fc-list : file family style')
> Traceback (most recent call last):
> File "", line 1, in
> File "", line 8, in test
> File "/usr/lib/python2.6/dist-packages/pygame/sysfont.py", line 253, in
> SysFont
> font = pygame.font.Font(fontname, size)
> error: font not initialized
>
>
>
Re: [pygame] Memory leak...
Hmm, yeah, upgraded my pygame and it's fixed now... On Wed, Oct 14, 2009 at 1:09 PM, claudio canepa wrote: > > > On Wed, Oct 14, 2009 at 2:59 PM, RB[0] wrote: > >> I am getting a nasty mem leak when using pygame.image.tostring >> >> As shown here: >> >> import pygame >> from pygame.locals import * >> >> pygame.display.set_mode((100,100)) >> while 1: >> pygame.image.tostring(pygame.Surface((8,8)).convert_alpha(), "RGBA", >> 1) >> >> >> NOTE: run this in a console or something where you can crash it to close >> it ;) >> I am running windows Vista (SP1) - using the task manager to view the >> memory usage. >> I also am running Pygame 1.8.1 - is this fixed in 1.9.1? >> When I run this, the memory seems to jump and just keep growing, quite >> quickly... >> >> Has anyone else had this problem? >> > > in win XP, pygame 1.9.0rc3 theres no leak: memory usage tops at 12.5 MB > -- > claxo > > >
[pygame] Memory leak...
I am getting a nasty mem leak when using pygame.image.tostring As shown here: import pygame from pygame.locals import * pygame.display.set_mode((100,100)) while 1: pygame.image.tostring(pygame.Surface((8,8)).convert_alpha(), "RGBA", 1) NOTE: run this in a console or something where you can crash it to close it ;) I am running windows Vista (SP1) - using the task manager to view the memory usage. I also am running Pygame 1.8.1 - is this fixed in 1.9.1? When I run this, the memory seems to jump and just keep growing, quite quickly... Has anyone else had this problem?
Re: [pygame] First person shooter help
PYGGEL is still in active development, but we recently used it to create a FPS for pyweek :) http://pyweek.org/e/robo-solo/ http://code.google.com/p/pyggel/ On Mon, Oct 12, 2009 at 2:12 PM, Skizzaltix wrote: > Have you checked out PYGGEL? I'm not sure if it was ever completed, but > from what I heard, it's a great tool. Search for it on the Pygame site. > > > Horst JENS wrote: > >> Am Montag, den 15.06.2009, 18:08 +1000 schrieb Astan Chee: >> >> >>> Hi, >>> I am trying to understand and make a simple first person shooter game. I >>> >>> >> >> Hi Astan, >> if you found something, please be so kind and inform me, i'm very >> interested on that too. >> >> greetings, >>-Horst >> >> >> > >
Re: [pygame] Python IDE for windoz
Hmm, It doesn't lock up for me - window stays if you don't call pygame.quit - but that's it On Sat, Oct 10, 2009 at 2:44 PM, Ian Mallett wrote: > On Sat, Oct 10, 2009 at 12:14 PM, Patrick Mullen wrote: > >> The main reason I don't use IDLE is because I have had issues in the >> past with it's runner locking things up. > > A fair point. It seems to have a problem with PyGame--running PyGame code > with F5 locks it up on exit, or if there's a bug. I keep the directory with > the files in it open (which is good anyway) and just run the relevant code > with a double click. >
Re: [pygame] Python IDE for windoz
Most? people just don't like it - personally it's all I use, Windows or otherwise... On Sat, Oct 10, 2009 at 12:23 PM, Kris Schnee wrote: > What's wrong with the built-in editor, IDLE? >
Re: [pygame] duplicate images
Generally you don't need to duplicate images (really) unless you are modifying them separately - just use different commands for blitting... ie image = SomePygameImage screen.blit(image, (0,0)) screen.blit(image, (100,100)) Will draw the image in two completely different places... On Thu, Oct 8, 2009 at 1:56 PM, Thiago Petruccelli < thiagopetrucce...@gmail.com> wrote: > Hi! > > I am using windows(ugh) in the interface of my game, and then I made a > close button. My game structure load all images in the startup of the game; > but when I try to copy then, things don't work as I wanted... when I close a > window and open another (wich is supposed to have a copy of the close button > with his own properties), it happens that the close button appears in the > old place, not in the right place in the opened window. I tried to use de > copy command from the copy module, but it didn't work. It seems that python > thinks it's the same object; I want to make a duplicate of it. > > I saw an example of a game using various enemies(the same image), but the > author load an image for every new enemy on the screen (using > pygame.image.load) > > Someone knows how to do this duplicate? > -- > Thiago Henrique Petruccelli >
Re: [pygame] Depth Screenshot
I would suggest PIL - don't have the exact functions for it off the top of my head though... On Tue, Oct 6, 2009 at 9:43 PM, Ian Mallett wrote: > Hello, > > I'm trying to debug a weird FBO/depth problem, and it would be great to > have screenshots of the depth. My current method does not work: > > def ScreenSurf(rect=AUTO,type=RGB,framebuffer=0): > if rect == AUTO: > size = glGetFloatv(GL_VIEWPORT) > size = [int(round(size[2])),int(round(size[3]))] > rect = [0,0,size[0],size[1]] > glPixelStorei(GL_PACK_ROW_LENGTH,0) > glPixelStorei(GL_PACK_SKIP_ROWS,0) > glPixelStorei(GL_PACK_SKIP_PIXELS,0) > if type==RGBA: > glPixelStorei(GL_PACK_ALIGNMENT,4) > elif type==RGB: > glPixelStorei(GL_PACK_ALIGNMENT,1) > elif type==DEPTH: > glPixelStorei(GL_PACK_ALIGNMENT,2) > try: > data = > glReadPixels(rect[0],rect[1],rect[2],rect[3],type,GL_UNSIGNED_BYTE) > print len(data) > except: > previous = glGetIntegerv(GL_READ_BUFFER) > glReadBuffer(GL_COLOR_ATTACHMENT0_EXT+framebuffer) > data = > glReadPixels(rect[0],rect[1],rect[2],rect[3],type,GL_UNSIGNED_BYTE) > glReadBuffer(previous) > if type==RGBA: > return pygame.image.fromstring(data,(rect[2],rect[3]),'RGBA',1) > elif type==RGB: > return pygame.image.fromstring(data,(rect[2],rect[3]),'RGB',1) > elif type==DEPTH: > #What goes here? > > The surface that is returned is then saved (pygame.image.save()). > > The issue is that in the case of depth, data is of length x*y. In the case > of RGB color, it is 3*rect[2]*rect[3]. In the case of RGBA, it is > 4*rect[2]*rect[3]. PyGame doesn't know how to convert it (there's no > pygame.image.fromstring(data,size,'R',1), for instance). What's a decent > way to save the depth as an image? > > Thanks, > Ian >
Re: [pygame] pymike!
http://pymike.pynguins.com/ But it is down ATM On Wed, Sep 2, 2009 at 11:14 AM, Hugo Arts wrote: > 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 results in one entry. pymike is > > proliferous!! He had at least 30--no, 50--bazillion entries. His code > > is instructional and fun to read. Any way we can get the tags put > > back? (Sorry, pymike, if this turns into drudge work for you.) > > > > Gumm > > >
Re: [pygame] mouse.get_pos()?
Make sure you are pumping the event queue, either with pygame.event.get or pygame.event.pump On Mon, Aug 17, 2009 at 9:36 PM, Yanom Mobis wrote: > I made a simple script to print the output of pygame.mouse.get_pos() every > frame, but it keeps printing the same tuple, no matter where i move the > mouse. > >
Re: [pygame] Shutting down the video screen
Yes, you just destroy it then restart it, ie: screen = pygame.display.set_mode(size, flags) pygame.display.quit() screen = pygame.display.set_mode(size, flags) On Mon, Aug 17, 2009 at 5:17 PM, Peter Chant wrote: > On Friday 14 August 2009, René Dudfield wrote: > > hi, > > > > you can call eg pygame.display.quit() > > > > Similar question from myself. Any way of just temporarily hiding the > display > and then restoring it later? > > I.e. a hypothetical: > > pygame.display.hide() > > #Do some stuff > . > . > . > > pygame.display.unhide() > > ? > > Or do I quit and then re-initialise the display? > > Thanks, > > Pete > > > > -- > Peter Chant > http://www.petezilla.co.uk >
Re: [pygame] Numeric keypad
You need to specifically get teh keyboard keys: K_0 becomes K_KP0 etc. On Tue, Aug 11, 2009 at 8:16 PM, pierrelafran...@sympatico.ca < pierrelafran...@sympatico.ca> wrote: > Hi > I'm trying to get value from numeric keypad, but K_0 ... K_9 doesn't work. > Numeric value on alpha keybord works. > > Can I use numeric keypad ? > > ex: > if event.type == KEYDOWN and event.key == K_0 : >DoSomething() > > Thanks > > -- > Pierre Lafrance > -- > >
Re: [pygame] Improving pygame web docs
Hmm, I guess part of the problem for me is that it is fixed width in size - and I have a rather wide monitor, so I just see a lot of the texture on both sides, which is annoying. Slightly smaller circles (or rather larger, like 60 pixels maybe?) circles would be better I think - but mainly allow the site to be larger in width, I think... On Fri, Jul 31, 2009 at 10:28 PM, Brian Fisher wrote: > I really didn't notice the background myself, so I don't think it's a > problem. > > What does actually bug me though, is the project list down the right side. > I appreciate wanting to make the project listings a focus of the site, but > it's taking up space and distracting from the focus of a page where I told > you by clicking on things that what I want to do right now is read > documentation. Plus it makes stuff weirdly off center as I scroll down. > > > > On Fri, Jul 31, 2009 at 2:20 PM, Devon Scott-Tunkin > wrote: > >> >> "The background is too busy, IMHO" >> >> I thought it looked good, but I can see how it is busy with such a large >> texture repetition, although it doesn't seem to negatively effect me when >> using the site. The plain gradient was too boring for me, at least when it >> was the extreme colors it used to be. Perhaps I am too attached to the >> effect of layering two backgrounds over each other. Yay css :). >> >> Do you think larger or smaller circles would look better, or perhaps even >> more transparency? Or can you suggest a different texture, I thought circles >> were fun and reminded me of snake skin. Both perfect for pygame. >> >> Devon >> >> >> --- On Thu, 7/30/09, RB[0] wrote: >> >> > From: RB[0] >> > Subject: Re: [pygame] Improving pygame web docs >> > To: pygame-users@seul.org >> > Date: Thursday, July 30, 2009, 9:19 PM >> > The background is too busy, IMHO >> > And I agree with what greg wrote... >> > Otherwise, looking good :) >> > >> > On Thu, Jul 30, 2009 at 7:55 PM, >> > Greg Ewing >> > wrote: >> > >> > jug wrote: >> > >> > >> > >> > >> > http://pygameweb.no-ip.org/docs/surface.html >> > ist not really easy to read, but I don't know exactly >> > why. >> > >> > >> > >> > >> > It looks all right to me, except for one thing: Every >> > >> > link to the docs for a method embedded in the text >> > >> > seems to be followed by a comment in small print, e.g. >> > >> > in the paragraph about Surface.convert, >> > >> > >> > >> > ...arguments can be used, similar to the >> > >> > pygame.Surface - [pygame object for representing >> > >> > images] call... >> > >> > >> > >> > IMO these embedded comments are pointless and >> > >> > distracting and make the text hard to read. Just >> > >> > make the method name into a link and leave it at >> > >> > that. >> > >> > >> > >> > Also a minor suggestion would be to leave some >> > >> > space between the heading for a method and its >> > >> > call prototypes, and between the prototypes and the >> > >> > following text, e.g. instead of >> > >> > >> > >> > Surface.convert - change the pixel format of an image >> > >> > Surface.convert(Surface): return Surface >> > >> > Surface.convert(depth, flags=0): return Surface >> > >> > Surface.convert(masks, flags=0): return Surface >> > >> > Surface.convert(): return Surface >> > >> > Creates a new copy of the Surface with the pixel >> > format >> > >> > changed. The new pixel format can... >> > >> > >> > >> > space it out slightly: >> > >> > >> > >> > Surface.convert - change the pixel format of an image >> > >> > >> > >> > Surface.convert(Surface): return Surface >> > >> > Surface.convert(depth, flags=0): return Surface >> > >> > Surface.convert(masks, flags=0): return Surface >> > >> > Surface.convert(): return Surface >> > >> > >> > >> > Creates a new copy of the Surface with the pixel >> > format >> > >> > changed. The new pixel format can... >> > >> > >> > >> > Also generally leave space between paragraphs if >> > you're >> > >> > not going to indent the first line of each paragraph. >> > >> > Otherwise the text tends to look like one huge paragraph, >> > >> > which is not good for reading. >> > >> > >> > >> > -- >> > >> > Greg >> > >> > >> > >> > >> >> >> >> >
Re: [pygame] Improving pygame web docs
The background is too busy, IMHO And I agree with what greg wrote... Otherwise, looking good :) On Thu, Jul 30, 2009 at 7:55 PM, Greg Ewing wrote: > jug wrote: > > http://pygameweb.no-ip.org/docs/surface.html ist not really easy to read, >> but I don't know exactly why. >> > > It looks all right to me, except for one thing: Every > link to the docs for a method embedded in the text > seems to be followed by a comment in small print, e.g. > in the paragraph about Surface.convert, > > ...arguments can be used, similar to the > pygame.Surface - [pygame object for representing > images] call... > > IMO these embedded comments are pointless and > distracting and make the text hard to read. Just > make the method name into a link and leave it at > that. > > Also a minor suggestion would be to leave some > space between the heading for a method and its > call prototypes, and between the prototypes and the > following text, e.g. instead of > > Surface.convert - change the pixel format of an image >Surface.convert(Surface): return Surface >Surface.convert(depth, flags=0): return Surface >Surface.convert(masks, flags=0): return Surface >Surface.convert(): return Surface >Creates a new copy of the Surface with the pixel format >changed. The new pixel format can... > > space it out slightly: > > Surface.convert - change the pixel format of an image > >Surface.convert(Surface): return Surface >Surface.convert(depth, flags=0): return Surface >Surface.convert(masks, flags=0): return Surface >Surface.convert(): return Surface > >Creates a new copy of the Surface with the pixel format >changed. The new pixel format can... > > Also generally leave space between paragraphs if you're > not going to indent the first line of each paragraph. > Otherwise the text tends to look like one huge paragraph, > which is not good for reading. > > -- > Greg >
Re: [pygame] Alpha channels and per pixel alpha
try this:
image = pygame.image.load("image.png").convert_alpha()
screen.blit(image, (0,0))
See if it is alpha or not... :)
On Wed, Jun 10, 2009 at 6:03 PM, Bjorn Samuelsson wrote:
> Ok.
> Could you possibly give me some short instructions on how to make a
> simple image with alpha channel so maybe I can see what I'm doing wrong.
> This is how i do it: take a regular image in photoshop, add an alpha
> channel, save as a SuperPNG with the "alpha channels" box checked.
> I'm not really sure how to check if I have a "working" alpha channel or
> not. But when i reopen the image in photoshop the alpha channel is still
> there. I also tried a small application that gives out information about a
> given png-file and it said that the image is 32-bit RGB+alpha,
> non-interlaced.
>
> --
> From: geometr...@gmail.com
> Date: Wed, 10 Jun 2009 14:48:58 -0700
> Subject: Re: [pygame] Alpha channels and per pixel alpha
> To: pygame-users@seul.org
>
> The way to do it is with .convert_alpha()
> Check that your images really do have an alpha channel.
>
> --
> check out the rest of the Windows Live™. More than mail–Windows Live™ goes
> way beyond your inbox. More than
> messages
Re: [SPAM: 3.500] Re: [pygame] This one baffles me
Yeah, if you want to convert just the tabs at the start of a line, you would
need to do:
print open("myfile.py").read().replace("\n"+" "*4, "\t") or whichever line
ending you have on your system...
but actually I would do a 3 liner that is more helpful, IMO:
f = open("myfile.py", "rw")
f.write(f.read.replace("\n" + " "*4, "\t"))
f.close()
I think "rw" is what you want there, but I haven't worked with it in a
while, but basically that will just load your file, convert and then resave
it, so you don't have to c&p for the console...
On Sun, May 17, 2009 at 6:41 PM, Greg Ewing wrote:
> Casey Duncan wrote:
>
>> Here's the moral-equivalent one-liner in Python:
>>
>> print open("myfile.py").read().replace(" "*4, "\t")
>>
>
> Note that this is not exactly the right way to
> expand tabs, since it doesn't take account of
> the position in the line at which the block of
> spaces starts. But it's okay if all you care
> about is leading indentation.
>
> --
> Greg
>
Re: [pygame] App Store
Back on topic, I think this is a great idea, and would love to see this move forward - I definitely would put it to use :) On Wed, May 13, 2009 at 7:47 PM, Tyler Laing wrote: > We don't want to punish them at all. That is not proper community > management, and it hurts FOSS's reputation in general. Take a look at my > post here, on reputation: > http://www.oddco.ca/zeroth/zblog/2009/05/08/reputation/ > > Punishing people because of the platform they use, is an action best left > to Microsoft and other companies. We should be above it. > > I don't care if it was a joke. Such things can come back and haunt the > community in general. These mailing lists are open for all to see. > > -Tyler > > On Wed, May 13, 2009 at 5:41 PM, Ian Mallett wrote: > >> ...much... > > > > > -- > Visit my blog at http://oddco.ca/zeroth/zblog >
Re: [pygame] PyGame and SVG
There are pygame libraries on the pygame.org site for both SVG and OpenVG, though both are limited, and I think the SVG one is only for opengl rendering. http://www.pygame.org/project/962/ -- SVG lib http://www.pygame.org/project/964/ -- OpenVG These might be useful to you, if only as a reference :) On Wed, May 6, 2009 at 7:21 AM, Peter Gebauer < peter.geba...@stockholm.bostream.se> wrote: > Hi! > > I'm not sure, but maybe something like OpenVG would be useful? > http://www.khronos.org/openvg/ > > Once you have a OpenVG implementation for SDL/PyGame you have a complete > and free API to do vector graphics for games, UI's and what not with > (potentially) hardware acceleration specifically for vector graphics. > > Just FYI. :) > > /Peter > > On 2009-05-05 (Tue) 18:47, Daniel Jo wrote: > > I don't have very much time during the week, but I'll try to get it > working > > in Windows (XP) this weekend. As for OS X, I don't own a system running > OS > > X, so unfortunately there's little that I can do there. . . > > -Daniel > > > > On Tue, May 5, 2009 at 8:48 AM, Bo Jangeborg wrote: > > > > > Do you know if this will be made available for Windows and OS X too ? > > > > > > Bo) > > > > > > Daniel Jo skrev: > > > > > >> I was thinking about UIs today and recalled a post by Brad Wardel > about > > >> the UI in Galactic Civilizations. He mentioned how it would look > pretty much > > >> the same regardless of the resolution one runs the game at, due to the > use > > >> of SVG. Presumably, the UI is designed as vector drawings and at > runtime > > >> rendered to a texture whose size depends upon the current screen > resolution. > > >> > > >> I thought that this would be a great idea for PyGame, but then I found > > >> that the only implementation of SVG that exists for PyGame actually > uses > > >> Cairo. Personally, I think that using Cairo within PyGame is, at best, > > >> suboptimum. What you end up with is a whole lot of redundant library > that is > > >> doing exactly nothing. It would be much better to have a > implementation with > > >> relatively atomic dependencies. > > >> > > >> Fortunately, after a bit of googling I discovered SDL_svg. It appears > to > > >> require only libxml-2.0 and libSDL. Perfect. It also has a very small > API. > > >> Perfect. After a bit more research I managed to create my own Python > > >> bindings using Pyrex. Take a look: > > >> > > >> http://code.google.com/p/pygame-svg/ > > >> > > >> -Daniel > > >> > > >> > > > >> > > >> > > >> No virus found in this incoming message. > > >> Checked by AVG - www.avg.com Version: 8.5.325 / Virus Database: > > >> 270.12.15/2093 - Release Date: 05/02/09 14:23:00 > > >> > > >> > > >> > > > > > > >
Re: [pygame] Function problem
The line just before the error is missing and ending ) ;)
On Wed, Apr 29, 2009 at 4:45 PM, Yanom Mobis wrote:
> full code:
>
> #!/usr/bin/env python
> # This program is free software; you can redistribute it and/or
> modify
> # it under the terms of the GNU General Public License as published
> by
> # the Free Software Foundation; either version 2 of the License, or
> # (at your option) any later version.
> #
> # This program is distributed in the hope that it will be useful,
> # but WITHOUT ANY WARRANTY; without even the implied warranty of
> # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> # GNU General Public License for more details.
> #
> # You should have received a copy of the GNU General Public License
> # along with this program; if not, write to the Free Software
> # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
> # MA 02110-1301, USA.
>
> import random
>
> class Mage(object):
> def __init__(self, name, initmana, initlife):
> self.name = name
> self.mana = initmana
> self.life = initlife
> def __str__(self):
> '''ouput given when class is printed'''
> return "%s: %i life, %i mana" % (self.name, self.life, self.mana)
> def cast(target):
> for item in magi:
> if item.name == target: #if we've found the right target
> item.life = item.life-random.randrange(10, 30)
> foundone = True #found the target
> if not foundone: # if target not found
> print("Cannot find %s" % (target)
>
> def pymageinit():
> global magi
> magi = [Mage("Player",20, 200), Mage("Arcawen",20, 200)]
>
>
> def main():
> Mage.cast("Player")
> for item in magi:
> print(item)
> return 0
>
> if __name__ == '__main__':
> pymageinit()
> main()
>
> error:
>
> File "main.py", line 36
> def pymageinit():
> ^
> SyntaxError: invalid syntax
>
>
>
>
> --- On *Tue, 4/28/09, Tyler Laing * wrote:
>
>
> From: Tyler Laing
> Subject: Re: [pygame] Function problem
> To: pygame-users@seul.org
> Date: Tuesday, April 28, 2009, 6:46 PM
>
>
> You're going to need to show us the entire file, sorry Yanom. Can't tell
> anything from that one function. The error however, is not caused by that
> function, but by whatever comes before it. Maybe an unbalanced parenthesis?
>
> On Tue, Apr 28, 2009 at 4:45 PM, Yanom Mobis
> http://mc/compose?to=ya...@rocketmail.com>
> > wrote:
>
>> This error:
>>
>> File "main.py", line 36
>> def pymageinit():
>> ^
>> SyntaxError: invalid syntax
>>
>> is caused by this function:
>>
>> def pymageinit():
>> global magi
>> magi = [Mage("Player",20, 200), Mage("Arcawen",20, 200)]
>>
>>
>>
>> does anyone know what i'm doing wrong?
>>
>>
>
>
> --
> Visit my blog at http://oddco.ca/zeroth/zblog
>
>
>
Re: [pygame] multi-width aalines and aacircles
You could do a filled polygon and then an aa one around it... But I think then you'd be getting a lot slower... On Wed, Mar 25, 2009 at 1:44 PM, Lenard Lindstrom wrote: > The aa polygon is not filled, and the filled polygon does no aa. > > Lenard > > > René Dudfield wrote: > >> good idea. >> >> there's an aa-polygon in sdl gfx >> >> >> On Wed, Mar 25, 2009 at 5:38 PM, Greg Ewing >> wrote: >> >> >>> Lenard Lindstrom wrote: >>> >>> >>> Yes, but we still need an aaline algorithm with line width. >>> Find an aa polygon algorithm and then use it to >>> draw line-shaped polygons. >>> >>> >>> >> > > -- > Lenard Lindstrom > > >
Re: [pygame] Re: GSoC Proposal: Basic gui system
I don't think incorporating an existing gui into pygame would work. Whatever it is you decide to do - it will need to be close enough to pygame to be worth it (ie, integrated into event loop and such, to make it easy for new users), abstract enough to allow extendability into a wide range of needs, and powerful enough to look good and scale to full size applications. >From my experience, none of the current pgame guis come close to having all those attributes. Either they are so abstract that the user has to do almost everything, they are too powerful to easily extend, or they are just funky in their usage. But that is yet another decision. How will events be handled? WIll they be returned like pygame events, or handled with callbacks? Or both and confuse people/be un-pythonic? How will it be rendered? Will it simply be an object you send the screen to at the end of each loop and render then update the screen? Will it use dirty rects to make the gui fast, or not, so you can use flip? How many/what widgets do you want to include? You pointed out how you would take the best 2 or 3 - well that is it, there is so much variance, and no gui I have seen that would be abstract enough to be useable for this claims to be everything you might/will need. I think most likely you would have a ton of different people chiming in, and in the end you might get 2 or 3 highest rated, but none would get a majority and it would probably fall apart before it even started... I agree with Sky, it is simple to write basic widgets, but once you get into more advanced stuff it takes time, and lots of it, there are just so many things to do. It isn't particulartly hard, but time consuming, and difficult to do "right". I think though updating the pygame wiki with some of the newer gui's, with a good comparison would probably work better - but if you do take one and make it work, more pwoer to you, and I am sure a lot of people will be grateful... Good luck :) On Tue, Mar 24, 2009 at 3:11 PM, Jug wrote: > If you all think, a lot of people would use a built-in gui but it's > not worth the work, is there a chance to put one of the existing guis > into pygame? We could poll the users on the website and/or the mailing > list about the best pygame gui. Then maybe have a look on the best 2 > or 3, discuss some pros and cons and include one into pygame? Because > as I said before, one big problem of all of the existing guis is that > they are at least one more dependency. In addition, new users don't > have to test all guis and find the best but can have a look at > pygame.gui and invest more time to understand it. I'm really tired > from reading up on guis (used 2 and began to read about Albow). A > pygame.gui module would get much more support (bug fixes, new ideas/ > widgets, etc.) than now, too. > > Regards, > Jug >
Re: [pygame] multi-width aalines and aacircles
I guess for now people could use this: http://www.pygame.org/wiki/CairoPygame?parent=CookBook But would be slow LOL, and would probably want a wrapper to handle all the functions and converting and such... On Tue, Mar 24, 2009 at 10:53 AM, Marius Gedminas wrote: > On Tue, Mar 24, 2009 at 08:56:16AM -0600, John Krukoff wrote: > > > -Original Message- > > > From: owner-pygame-us...@seul.org [mailto:owner-pygame-us...@seul.org] > On > > > Behalf Of Lenard Lindstrom > > > Sent: Monday, March 23, 2009 6:07 PM > > > To: pygame-users@seul.org > > > Subject: Re: [pygame] multi-width aalines and aacircles > > > > > > None of the SDL_gfx functions has a line width argument that I could > see. > > > > Sure, but at least SDL_gfx gives you the tools you need to get there for > AA > > lines. A filled polygon, redraw the edges with an AA line, use some AA > > circles to draw caps, and viola! > > > > AA donuts would still be a pain, and require an offscreen buffer, which > is > > unfortunate. > > > > And, likely you'd ask for variable width AA bezier curves next, which > also > > isn't supported. That one may be because it's hard, though. > > How about full Cairo support while we're at it? > > ;-) > > Marius Gedminas > -- > Programs that write programs are the happiest programs in the world. >-- Andrew Hume > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iD8DBQFJyQIRkVdEXeem148RAmtEAJ9H72s8I/IeICsgmY4jtDJdVUFnuwCgkvuP > czNhblnhWY/SZTJ/LC1N1Fs= > =aG4D > -END PGP SIGNATURE- > >
Re: [pygame] multi-width aalines and aacircles
I agree - I have wanted the aalines for a while now (for my lib)... Just wondering why this hasn't already been done, I saw some discussion on it a while back (like last year or further) about it being supported in SDL already and pygame just didn't make use of the API or something... Is that even correct? Circles sound interesting as well... On Mon, Mar 23, 2009 at 11:32 AM, pymike wrote: > PyGame desperately needs multi-width aalines and aacircles. Are there any > plans to implement these during GSoC or the next PyGame release? > > It'd really open up possibilities for pretty apps, vector art, and even SVG > libraries. > > -- > - pymike > "Python eggs me on." >
Re: [pygame] multi-width aalines and aacircles
Erm, sorry, meant having a width for aalines, I know aalines are already there LOL On Mon, Mar 23, 2009 at 11:36 AM, RB[0] wrote: > I agree - I have wanted the aalines for a while now (for my lib)... > Just wondering why this hasn't already been done, I saw some discussion on > it a while back (like last year or further) about it being supported in SDL > already and pygame just didn't make use of the API or something... > Is that even correct? > Circles sound interesting as well... > > > On Mon, Mar 23, 2009 at 11:32 AM, pymike wrote: > >> PyGame desperately needs multi-width aalines and aacircles. Are there any >> plans to implement these during GSoC or the next PyGame release? >> >> It'd really open up possibilities for pretty apps, vector art, and even >> SVG libraries. >> >> -- >> - pymike >> "Python eggs me on." >> > >
Re: [pygame] GSoC Proposal: Basic gui system
Having written a few pygame guis, I agree with Marcus and Ian. But, having said that, it would be possible to make a powerful enough gui that is rather abstract, but still is useful, you just need to do it correctly. A basic gui that fits in with the event system (to get, suppress, and return), with app and widget classes that can handle every kind of input/rendering would suffice for the extensibility. Then you can add simple things like buttons/labels/etc. I am sure a lot of people would use it - which may be reason enough to do it. But personally I still don't think it will be worth it - simple widgets are trivial to write... Cheers On Sat, Mar 21, 2009 at 4:08 PM, Ian Mallett wrote: > On Sat, Mar 21, 2009 at 8:48 AM, Marcus von Appen wrote: > >> Which is why a GUI backend within pygame was never realised. There is no >> ultimate design approach and having just a bunch of abstract base >> classes for users to implement is not worth the work :-). > > I completely agree. Arguably, making a GUI from scratch can be time > consuming, but GUI's tend to differ a lot. For example, some games, such as > asteroids and other arcade games, need simple centered menus. My new image > filtering program has a GUI that emphasizes linking windows and other > stuff. It would be hard--in my view impossible--to generalize all the > possible needs down to a few classes and have it still be easier to use than > an improvised solution. > Ian >
Re: [pygame] Python - Pygame - PyOpenGL performance
Yes, from what I have seen the differences are negligible (the links I found stated that) a few fps or something. And the new opengl has support for more features, the old version only goes to like opengl 1.2 compatibility or something when I last checked. I would recommend you use the ctypes one over the old one even if doing immediate mode ;) On Tue, Mar 17, 2009 at 10:43 PM, Casey Duncan wrote: > With the emphasis these days on batch operations (VBOs, etc) and doing more > and more of the work on the video card itself via shaders, I seriously doubt > that the bottleneck of a well-written, modern PyOpenGL application will be > the ctypes overhead. The only time I could see that could be would be for > immediate mode usage, which is deprecated anyhow, for the simple reason that > per-vertex operations no longer mesh well with a modern graphics > architecture. > > If you are not writing a modern OpenGL app, then by all means, use the old > version. It's going to be a while I think before cards drop support OpenGL 2 > and earlier features. It will happen eventually though. > > There are significant maintenance advantages to ctypes over C-wrappers, > generated by SWIG or otherwise. It is difficult to make the latter work well > across platforms and python versions. If you've ever looked at the build > system for PyOpenGL 2.x, you'd understand what I mean. And this is coming > from somebody who enjoys writing C extensions, but for wrapping existing > APIs, ctypes is the state of the art. Like Python itself it trades execution > speed for development efficiency and better portability. > > PyOpenGL is more or less a one man project afaik, and let me tell you, > development efficiency rules when you're trying to move mountains yourself. > > -Casey > > > On Mar 17, 2009, at 7:37 PM, Richie Ward wrote: > > why did they not make 3.0 with swig? >> >> On Tue, Mar 17, 2009 at 12:26 PM, RB[0] wrote: >> >>> http://groups.google.com/group/pyglet-users/msg/832b15389fccd28d?pli=1 >>> >>> Hmm, this is a bit outdated, but I found a few other references that say >>> SWIG will generally be faster to run, though would have more overhead - >>> so I >>> dunno. >>> >>> HTH >>> >>> On Tue, Mar 17, 2009 at 7:17 AM, RB[0] wrote: >>> >>>> >>>> I saw saw tests for performance between the old C PyOpenGL and the new >>>> ctypes one... >>>> The older one was significantly faster from what I saw - but that is how >>>> it will always be - direct usage of a C lib is just like calling C >>>> functions >>>> and such - whereas ctypes you have to call a python function (which may >>>> call >>>> others) which will execute the C lib code... >>>> >>>> I'll see if I can't find the page somewhere... >>>> >>>> On Mon, Mar 16, 2009 at 3:44 PM, Brian Fisher < >>>> br...@hamsterrepublic.com> >>>> wrote: >>>> >>>>> >>>>> That's what PyOpenGL 2.0 was - a C extension instead of ctypes. (made >>>>> with SWIG) >>>>> >>>>> I actually still use PyOpenGL 2.0 for reasons other than performance >>>>> (py2exe packaging) - I had to build it myself on windows for Python >>>>> 2.5, you >>>>> can get at an installer for it here: >>>>> http://thorbrian.com/pyopengl/builds.php >>>>> >>>>> I've never performance tested the difference between it and 3.0 though >>>>> - >>>>> is somebody else could do that, I'd love to see the results >>>>> >>>>> On Mon, Mar 16, 2009 at 10:49 AM, Zack Schilling >>>>> wrote: >>>>> >>>>>> >>>>>> If someone did this and I could drop it in to my code, that would be >>>>>> very nice. But for right now, PyOpenGL is serving my needs just fine. >>>>>> I can >>>>>> use about 600 independently textured and animated sprites onscreen, >>>>>> scaled >>>>>> and rotated, without stressing a low-end system more than 40%. >>>>>> >>>>>> On Mar 16, 2009, at 1:00 PM, Forrest Voight wrote: >>>>>> >>>>>> Would writing a replacement for PyOpenGL in C instead of in Python >>>>>>> with ctypes help? I think it really would ... PyOpenGL is internally >>>>>>> pretty complex, sometimes when I get tracebacks the error is 5 or 6 >>>>>>> levels into PyOpenGL. Even a C library that only implemented the >>>>>>> common functions and relied on PyOpenGL for the constants and >>>>>>> functions that do complex things like handling strings would probably >>>>>>> help a lot. >>>>>>> >>>>>>> >>>>>>>> Another way to increase speed is to write an opengl rendering engine >>>>>>>> in C and call and make it available as a Python extension. This is >>>>>>>> a major speed boost, in particular for a large number of iterations. >>>>>>>> Iirc PyOpenGL bindings are generated, many times this is suboptimal >>>>>>>> code for what you're trying to do, writing the Python extension in C >>>>>>>> manually have been faster for me many times. This is indeed true >>>>>>>> if you put your iterations inside a C loop instead of calling the >>>>>>>> C function from Python many times. >>>>>>>> >>>>>>>> >>>>> >>>> >>> >>> >> >> >> -- >> Thanks, Richie Ward >> > >
Re: [pygame] Python - Pygame - PyOpenGL performance
http://groups.google.com/group/pyglet-users/msg/832b15389fccd28d?pli=1 Hmm, this is a bit outdated, but I found a few other references that say SWIG will generally be faster to run, though would have more overhead - so I dunno. HTH On Tue, Mar 17, 2009 at 7:17 AM, RB[0] wrote: > I saw saw tests for performance between the old C PyOpenGL and the new > ctypes one... > The older one was significantly faster from what I saw - but that is how it > will always be - direct usage of a C lib is just like calling C functions > and such - whereas ctypes you have to call a python function (which may call > others) which will execute the C lib code... > > I'll see if I can't find the page somewhere... > > > On Mon, Mar 16, 2009 at 3:44 PM, Brian Fisher > wrote: > >> That's what PyOpenGL 2.0 was - a C extension instead of ctypes. (made with >> SWIG) >> >> I actually still use PyOpenGL 2.0 for reasons other than performance >> (py2exe packaging) - I had to build it myself on windows for Python 2.5, you >> can get at an installer for it here: >> http://thorbrian.com/pyopengl/builds.php >> >> I've never performance tested the difference between it and 3.0 though - >> is somebody else could do that, I'd love to see the results >> >> On Mon, Mar 16, 2009 at 10:49 AM, Zack Schilling < >> zack.schill...@gmail.com> wrote: >> >>> If someone did this and I could drop it in to my code, that would be very >>> nice. But for right now, PyOpenGL is serving my needs just fine. I can use >>> about 600 independently textured and animated sprites onscreen, scaled and >>> rotated, without stressing a low-end system more than 40%. >>> >>> On Mar 16, 2009, at 1:00 PM, Forrest Voight wrote: >>> >>> Would writing a replacement for PyOpenGL in C instead of in Python >>>> with ctypes help? I think it really would ... PyOpenGL is internally >>>> pretty complex, sometimes when I get tracebacks the error is 5 or 6 >>>> levels into PyOpenGL. Even a C library that only implemented the >>>> common functions and relied on PyOpenGL for the constants and >>>> functions that do complex things like handling strings would probably >>>> help a lot. >>>> >>>> >>>>> Another way to increase speed is to write an opengl rendering engine >>>>> in C and call and make it available as a Python extension. This is >>>>> a major speed boost, in particular for a large number of iterations. >>>>> Iirc PyOpenGL bindings are generated, many times this is suboptimal >>>>> code for what you're trying to do, writing the Python extension in C >>>>> manually have been faster for me many times. This is indeed true >>>>> if you put your iterations inside a C loop instead of calling the >>>>> C function from Python many times. >>>>> >>>>> >> >
Re: [pygame] Python - Pygame - PyOpenGL performance
I saw saw tests for performance between the old C PyOpenGL and the new ctypes one... The older one was significantly faster from what I saw - but that is how it will always be - direct usage of a C lib is just like calling C functions and such - whereas ctypes you have to call a python function (which may call others) which will execute the C lib code... I'll see if I can't find the page somewhere... On Mon, Mar 16, 2009 at 3:44 PM, Brian Fisher wrote: > That's what PyOpenGL 2.0 was - a C extension instead of ctypes. (made with > SWIG) > > I actually still use PyOpenGL 2.0 for reasons other than performance > (py2exe packaging) - I had to build it myself on windows for Python 2.5, you > can get at an installer for it here: > http://thorbrian.com/pyopengl/builds.php > > I've never performance tested the difference between it and 3.0 though - is > somebody else could do that, I'd love to see the results > > On Mon, Mar 16, 2009 at 10:49 AM, Zack Schilling > wrote: > >> If someone did this and I could drop it in to my code, that would be very >> nice. But for right now, PyOpenGL is serving my needs just fine. I can use >> about 600 independently textured and animated sprites onscreen, scaled and >> rotated, without stressing a low-end system more than 40%. >> >> On Mar 16, 2009, at 1:00 PM, Forrest Voight wrote: >> >> Would writing a replacement for PyOpenGL in C instead of in Python >>> with ctypes help? I think it really would ... PyOpenGL is internally >>> pretty complex, sometimes when I get tracebacks the error is 5 or 6 >>> levels into PyOpenGL. Even a C library that only implemented the >>> common functions and relied on PyOpenGL for the constants and >>> functions that do complex things like handling strings would probably >>> help a lot. >>> >>> Another way to increase speed is to write an opengl rendering engine in C and call and make it available as a Python extension. This is a major speed boost, in particular for a large number of iterations. Iirc PyOpenGL bindings are generated, many times this is suboptimal code for what you're trying to do, writing the Python extension in C manually have been faster for me many times. This is indeed true if you put your iterations inside a C loop instead of calling the C function from Python many times. >
Re: [pygame] Python - Pygame - PyOpenGL performance
Hmm, how are you loading your textures - GL_NEAREST or are you using LINEAR or Mip mapped filtering? Otherwise, only thing I can think of is you might have a cruddy card that is dumping some odd functionality to your cpu instead of gpu? On Thu, Feb 26, 2009 at 1:17 PM, Zack Schilling wrote: > That was the first thing I tried. Using a dummy draw function that crunched > a few numbers instead of doing the OpenGL calls. That worked fine and let me > create thousands and thousands of sprites before the CPU tapped out. > > No I'm not using psyco or any other performance enhancer. > > -Zack > > > > On Feb 26, 2009, at 2:08 PM, RB[0] wrote: > > Well, most likely your main speed down is looping through all those >> sprites as it is - trying just looping through them and calling a dummy >> function instead of the opengl one - and see what happens - otherwise, that >> seems quite odd to me, I haven't run into that before (are you using psyco, >> perhaps?) >> >> On Thu, Feb 26, 2009 at 1:04 PM, Zack Schilling >> wrote: >> I know the PyOpenGL mailing list might be a better place to ask this >> question, but I've had a lot of luck talking to the experienced people here >> so I figured I'd try it first. >> >> I'm trying to migrate a game I created from using the Pygame / SDL >> software rendering to OpenGL. Before attempting the massive and complex >> conversion involved with moving the whole game, I decided to make a little >> test program while I learned OpenGL. >> >> In this test, I set up OpenGL to work in 2D and began loading images into >> texture objects and drawing textured quads as sprites. I created a little >> glSprite class to handle the drawing and translation. At first its draw >> routine looked like this: >> >> glPushMatrix() >> glTranslate(self.positionx,self.positiony,0) >> glBindTexture(GL_TEXTURE_2D, self.texture) >> glBegin(GL_QUADS) >> glTexCoord2f(0, 1) >> glVertex2f(0, 0) >> glTexCoord2f(1, 1) >> glVertex2f(w, 0) >> glTexCoord2f(1, 0) >> glVertex2f(w, h) >> glTexCoord2f(0, 0) >> glVertex2f(0, h) >> glEnd() >> glPopMatrix() >> >> Note: self.texture is a texture ID of a loaded OpenGL texture object. My >> sprite class keeps a dictionary cache and only loads the sprite's image into >> a texture if it needs to. >> >> I'd get maybe 200 identical sprites (same texture) onscreen and my CPU >> would hit 100% load from Python execution. I looked into what could be >> causing this and found out that it's probably function call overhead. That's >> 14 external library function calls per sprite draw. >> >> The next thing I tried was to create a display list at each sprite's >> initialization. Then my code looked like this: >> glPushMatrix() >> glTranslate(self.positionx,self.positiony,0) >> glCallList(self.displist) >> glPopMatrix() >> >> Well, that's nice, down to 4 calls per draw. I was able to push ~500 >> sprites per frame using this method before the CPU tapped out. I need more >> speed than this. My game logic uses 30-40% of the CPU alone and I'd like to >> push at least 1000 sprites. What can I do? I've looked into passing sprites >> as a matrix with vertex arrays, but forming a proper vertex array with numpy >> can sometimes be more trouble than it's worth. Plus, I can't swap out >> textures easily mid-draw, so it makes things much more complex than the >> simple way I'm doing things now. >> >> Is there any design pattern I could follow that will get me more speed >> without sending me off the deep end with complexity. >> >> Thanks, >> >> Zack >> >> >
Re: [pygame] Python - Pygame - PyOpenGL performance
Well, most likely your main speed down is looping through all those sprites as it is - trying just looping through them and calling a dummy function instead of the opengl one - and see what happens - otherwise, that seems quite odd to me, I haven't run into that before (are you using psyco, perhaps?) On Thu, Feb 26, 2009 at 1:04 PM, Zack Schilling wrote: > I know the PyOpenGL mailing list might be a better place to ask this > question, but I've had a lot of luck talking to the experienced people here > so I figured I'd try it first. > > I'm trying to migrate a game I created from using the Pygame / SDL software > rendering to OpenGL. Before attempting the massive and complex conversion > involved with moving the whole game, I decided to make a little test program > while I learned OpenGL. > > In this test, I set up OpenGL to work in 2D and began loading images into > texture objects and drawing textured quads as sprites. I created a little > glSprite class to handle the drawing and translation. At first its draw > routine looked like this: > >glPushMatrix() >glTranslate(self.positionx,self.positiony,0) >glBindTexture(GL_TEXTURE_2D, self.texture) >glBegin(GL_QUADS) >glTexCoord2f(0, 1) >glVertex2f(0, 0) >glTexCoord2f(1, 1) >glVertex2f(w, 0) >glTexCoord2f(1, 0) >glVertex2f(w, h) >glTexCoord2f(0, 0) >glVertex2f(0, h) >glEnd() >glPopMatrix() > > Note: self.texture is a texture ID of a loaded OpenGL texture object. My > sprite class keeps a dictionary cache and only loads the sprite's image into > a texture if it needs to. > > I'd get maybe 200 identical sprites (same texture) onscreen and my CPU > would hit 100% load from Python execution. I looked into what could be > causing this and found out that it's probably function call overhead. That's > 14 external library function calls per sprite draw. > > The next thing I tried was to create a display list at each sprite's > initialization. Then my code looked like this: >glPushMatrix() >glTranslate(self.positionx,self.positiony,0) >glCallList(self.displist) >glPopMatrix() > > Well, that's nice, down to 4 calls per draw. I was able to push ~500 > sprites per frame using this method before the CPU tapped out. I need more > speed than this. My game logic uses 30-40% of the CPU alone and I'd like to > push at least 1000 sprites. What can I do? I've looked into passing sprites > as a matrix with vertex arrays, but forming a proper vertex array with numpy > can sometimes be more trouble than it's worth. Plus, I can't swap out > textures easily mid-draw, so it makes things much more complex than the > simple way I'm doing things now. > > Is there any design pattern I could follow that will get me more speed > without sending me off the deep end with complexity. > > Thanks, > > Zack >
Re: [pygame] move problems
if key[K_UP] should work better :) On Tue, Feb 10, 2009 at 6:47 PM, Yanom Mobis wrote: > > this code is in my main game loop > > key = pygame.key.get_pressed() #create a key index > >if K_UP in key: #check if the up arrow is pressed >redcar.speed = (0, -2) >else: >redcar.speed = (0, 0) > >redcar.rect = redcar.rect.move(redcar.speed) #move redcar by speed > > but pressing the up arrow doesn't move the sprite. > > > > >
Re: [pygame] Re: Python path problem in vista?
It is an IDLE problem - I ran into the same thing on Ubuntu and XP, IDLE doesn't like the way they do it. A simple fix is to just put this line in: sys.path.insert(0, "lib") Instead of all that try/except nonsense. The above line works just as well, and I have never had a problem with it failing anywhere. I have actually used that stuff in my teams entry for pyweek ever sense the skellington was released :) HTH :) On Tue, Feb 10, 2009 at 11:40 AM, Brian Fisher wrote: > I can reproduce the problem (on vista), but it looks like an idle problem, > not really a vista problem > > when running the script, "__file__" is "C:\Python25\Lib\idlelib\idle.pyw" > > so "libdir" becomes "C:\Python25\Lib\idlelib\lib" > > > > > On Tue, Feb 10, 2009 at 2:48 AM, Thiago Chaves wrote: > >> Can anyone in the list also reply if they do NOT get problems running >> programs with skellington-compliant structure on Vista? So far I've >> got only one person informing of problems executing the program and >> I'd like to hear if that's widespread or not. >> >> -Thiago >> >> On Sun, Feb 8, 2009 at 10:02 PM, Thiago Chaves >> wrote: >> > Hi, >> > >> > recently I was informed that my most recent project is not running >> > properly in Vista. I'm using the skellington structure suggested by >> > Pyweek administration and I'm wondering if that's somehow related. >> > >> > File structure for the project (as far as it is relevant to this post): >> > ssof/run_game.py >> > ssof/lib/main.py >> > >> > run_game.py's contents: >> > >> > >> > #! /usr/bin/env python >> > >> > import sys >> > import os >> > >> > >> > try: >> >__file__ >> > except NameError: >> >pass >> > else: >> >libdir = os.path.abspath(os.path.join(os.path.dirname(__file__), >> 'lib')) >> >sys.path.insert(0, libdir) >> > >> > import main >> > main.main() >> > ___ >> > >> > User feedback: >> > >> > Alright then, >> > Open fully-updated Windows Vista. Open IDLE. Python version number is >> > 2.5.2. Open run_game.py. Hit F5 (runs the script). >> > Traceback (most recent call last): >> > File "C:\Users\Andy >> > Hanson\Desktop\ssof-2009-01-31-fixed\ssof_alpha4\run_game.py", line >> > 15, in >> > import main >> > ImportError: No module named main >> > >> > This is certainly a very simple problem! >> > >> > >> > >> > Any thoughts? What am I doing wrong here? >> > >> > (I'm attaching run_game.py just in case the formatting gets messed up) >> > >> > -Thiago >> > >> > >
Re: [pygame] pygame.display.set_mode() and OpenGL
My guess would be that it needs to create a new context when you resize... On Thu, Jan 29, 2009 at 3:11 PM, Ian Mallett wrote: > Wow, that's going to be annoying. Oh well--at least the "stuff" doesn't > take too long to remake. Any particular reason for this bug? Something to > fix in PyGame? >
