Re: [pygame] [Announce] Python bindings for the bitmask collision detection library
Hi. Bitmask as a separate module is a good idea. I think your pygame.mask is a good name. Then we can provide some pygame.sprite mixins, or methods to help there. - pygame.mask module. - move docs from the source to .doc file. - some unittests in the test/ directory. Ok, I can do this. - move your pygame example to examples/bitmask.py or maybe... bouncy_bitmask.py ? Sure, no problem. I have not even looked at the pygame source tree, so I don't know how you organize stuff. I will have a look. I'm not sure about a surface method. It might simplify things for some people though. However then it makes surface depend on the bitmask module (not necessarily bad). It is more complicated, but I can imagine it makes it easier to use for beginners. Anyway, I cannot really help with this part so I leave it up to you guys. Has it been tested on big endian machines? eg ppc macs? It looks to have checks in there for 64bit machines - has it been tested on 64bit machines too? Yes. The library is used in my game 'Airstrike', which has been tested on a lot of platforms: sparc, ppc, i386 and even some old amiga platform. So I think it works. I develop on ppc and i386. 'maskFromSurface' might be a constructor argument? This would be so common, that we should do our own implementation. Yes. It is also much faster in C than in Python. I can't really think of a good set of arguments to the constructor that allows for either (width,height) or a surface, though. Do you think it would be very different for different games? eg, using different alpha levels as 'empty'. 5% alpha might be considered to be gone by some games/sprites. If you think that's useful, an alpha_threshold argument might be appropriate. I think it's a good idea. It can default to 50%. As you suggest, there's lots of other uses for bitmasks, other than collision. Blitting surfaces masked with a bitmask might be a future application. Another future application might be to reduce over draw - by using the bitmask to show which pixels we have updated. A mask.setrange() method might be useful. So you can set a range of bits at once, quickly. Perhaps this can wait until the next release, I think collision detection is the main feature, and it may seem overly complicated if we add a lot of extra functions. But again, I think you can decide this best. I will start working on this and try to be on irc next wednesday. Regards, UIf
[pygame] How to use the current Desktop Wallpaper as pygame background
Please point me to solutions/code snippets because i doubt that i'm the first with this question: How to use the current Desktop Wallpaper as a background graphic for pygame ? Do i have to check wich OS/variant the user is running and then locate the current Desktop Wallpaper file in the users file system ? Like Linux/Gnome, Linux/KDE, Windows98, WinXP, MacOSX etc? or is there an elegant solution that works with every OS/Variant ? I don't care if i get the Desktop Wallpaper or a Screenshot of the Desktop with all the Icons on it... I want to make an action game where the user feel that he has to defend his very own Desktop. greetings, -Horst signature.asc Description: This is a digitally signed message part
Re: [pygame] PyGame Runtime
Will, first off I think it's wonderful that you're thinking so much of distribution. When it comes to the majorty of the downloadable game audience (the less technical part) I think having reasonable end-user distribution is a pre-requisite to the success of any game generation tool chain. To put another way, if a good distribution option was not there for tool x, distribution would have a signficantly increased failure rate, and the majority of game developers in the world would take tool x off of their list. However with your idea of a Pygame Runtime, I honestly think it would be a large step backwards, at least for the Mac and Win markets. The big reason why I say that is because the number one issue for distribution to be successful to the mass downloadable market is that when they find and run your link, it all just works. Basically most people will not put any work at all into figuring out why they can't run what they downloaded. They'll just go find and play one of the thousands of games that do just work. Also no distribution channel for downloadable games will take a game for inclusion if it doesn't just work for the vast majority of users. If there is a dependency that is required and not included - any at all - then it won't work for people without the dependency. And a runtime (that is not included) is a dependency. Also, when mentioning py2exe you said it will generate a large bundle of files - and then you are left with the tedious task of making an installer.. I can see how those might look like a negative at first glance (having lots of files then writing an installer) - but in terms of the final output of that process, it's very well suited to the windows downloadable market. The market is well established with end-users knowing how to: a) download and run something b) launch a program from the start menu or desktop. The installer gives you a single file to run that installs start menu shortcuts. It's all set. What the contents of the install directory look like is basically irrelevant. Also writing and building an installer is actually really easy (easier than py2exe in my opinion), and is so short and simple it doesn't have time to be tedious. It's usually just filling out a little script file (like 10 or so lines) Inno Setup is really awesome for windows installers: http://www.jrsoftware.org/isinfo.php ... all that being said, the one way I can see the runtime idea really working, is if the runtime was also a game browsing and downloading client, and then the download link for a game in that system was basically just the client. WildTangent and Steam are basically like this. I still would perfer distributing installers myself (I like that it would be more open) but I would be interested in submiting content into a system like that, and I can see it being successful. On 5/6/07, Will McGugan [EMAIL PROTECTED] wrote: Just posted an entry about a suggested 'PyGame Runtime'. I'd love to hear the opinion of the PyGame community on this one! http://www.willmcgugan.com/2007/05/06/pygame-runtime/
Re: [pygame] PyGame Runtime
Brian Fisher wrote: Will, first off I think it's wonderful that you're thinking so much of distribution. When it comes to the majorty of the downloadable game audience (the less technical part) I think having reasonable end-user distribution is a pre-requisite to the success of any game generation tool chain. To put another way, if a good distribution option was not there for tool x, distribution would have a signficantly increased failure rate, and the majority of game developers in the world would take tool x off of their list. However with your idea of a Pygame Runtime, I honestly think it would be a large step backwards, at least for the Mac and Win markets. The big reason why I say that is because the number one issue for distribution to be successful to the mass downloadable market is that when they find and run your link, it all just works. Basically most people will not put any work at all into figuring out why they can't run what they downloaded. They'll just go find and play one of the thousands of games that do just work. Also no distribution channel for downloadable games will take a game for inclusion if it doesn't just work for the vast majority of users. If there is a dependency that is required and not included - any at all - then it won't work for people without the dependency. And a runtime (that is not included) is a dependency. Surely it is better than the current situation where there all these great games on pygame.org that are only ever played by other PyGame coders. Personally I wouldn't mind a runtime, but I'll grant you that a lot of potential end users would baulk at having to download an extra dependancy - and we can't foist it on them like Microsoft. I know installers aren't that difficult to create. I've used Inno-setup myself, it's an excellent system - but its still a hurdle that most PyGame coders don't want to tackle unless they have something particularly impressive that they want to distribute. It is also more of a hassle if you want the game to run on multiple platforms. A runtime wouldn't preclude creating your own install package, coders would be free to chose one or both methods of distribution. How about a compromise where the game is attached to a small stub exe that checks for the presence of the runtime, and offers to download it if it isn't present? Although that does kind of defeat the cross-platform benefit. Will
Re: [pygame] PyGame Runtime
On 5/6/07, Will McGugan [EMAIL PROTECTED] wrote: [Runtime is step backwards] Surely it is better than the current situation where there all these great games on pygame.org that are only ever played by other PyGame coders. This assertion isn't continuing the argument - it's claiming some goal is good and presuming your proposal accomplishes that goal. I was arguing that the proposal wouldn't accomplish the goal you originally stated. In your blog you proposed a specific technical option for distribution in order to help pygame-based games launch it on the internet, and perhaps even profit from it. And in your last paragraph you implicitly suggested that your distribution proposal would make pygame-based games competitive in the Casual games market. My post was arguing that the distribution proposal you made (a seperate runtime install) wouldn't help significantly in getting pygame based games into the mass market hands on windows. I may have been a little extreme saying a runtime would be a step backwards, but my rationale in that is that if you've got some option that people are led to believe solves some problem, when it doesn't really solve that problem, then it's just distracting noise. And because there are already solutions that solve those problems (installers over packaged apps) it seems a step backwards, even if it does improve in other areas. Personally I wouldn't mind a runtime, but I'll grant you that a lot of potential end users would baulk at having to download an extra dependancy This comment seems to miss the point of what I was saying. It's not about minding a runtime, or people baulking at having to have an extra download. Most people won't mind the extra download either, even though they won't go do that extra download. It just comes down to that if things don't work, most people (in the downloadable market anyways) will not go figure out how to fix it. It just simply won't happen. In the PC downloadable market, you used to see this a lot with DirectX 9 vs. DirectX 8.1 (Win XP originally came with 8.1, although SP2 comes with 9.0). It killed distribution, so people determined to stick with 9.0 mitagated it with either included runtime installers and special windows with links to download and all that. That stuff worked pretty good, i.e. people didn't seem to mind the extra install terribly much But with a zip file renamed to an unrecognized extension? well you can't do any of that hand holding at all. It would ust look broken. And that would absolutely devastate your download to run rate on distribution. I'm talking taking it down by like 90+% I know installers aren't that difficult to create. I've used Inno-setup myself, it's an excellent system - but its still a hurdle that most PyGame coders don't want to tackle unless they have something particularly impressive that they want to distribute. It is also more of a hassle if you want the game to run on multiple platforms. I get the multiple platform thing, and I agree it would be great to be able to build a single package to work on all platforms - but I don't see the idea of a runtime being a great solution to the multiple platform thing. So does the runtime include pyOpenGL? Does it include pyOpenAL? The fmod wrapper the devs compiled themselves? the extension they wrote themselves? Lets say the runtime includes every extension you need - what about version of the runtime? If you need a newer python will the runtime auto update? If it does auto update, does it break the game that was tested only on 2.4? Basically how do you know the environment you tested on is the way it will run when distributed? Granted all of these problems can be solved with a runtime - but py2exe or py2app type approaches to packaging solve all these complexities well. A runtime wouldn't preclude creating your own install package, coders would be free to chose one or both methods of distribution. How about a compromise where the game is attached to a small stub exe that checks for the presence of the runtime, and offers to download it if it isn't present? Although that does kind of defeat the cross-platform benefit. That does sound like an improvement - but it is also a step in the direction of just packaging the whole thing as an executable with all it's dependencies in it.
Re: [pygame] PyGame Runtime
I agree with Brian. Slightly related to this topic: I've had good success with py2app and py2exe for OS X and Windows, respectively--is there a comparable python packaging system that works for a good portion of Linux distributions? (I'm NOT talking about rpm's, ebuilds, etc.) ~ Nathan
Re: [pygame] PyGame Runtime
Source code in a tar ball, with a setup.py, and a ./configure make. You can make binaries too... but source is preferred. On 5/7/07, Nathan [EMAIL PROTECTED] wrote: I agree with Brian. Slightly related to this topic: I've had good success with py2app and py2exe for OS X and Windows, respectively--is there a comparable python packaging system that works for a good portion of Linux distributions? (I'm NOT talking about rpm's, ebuilds, etc.) ~ Nathan
Re: [pygame] PyGame Runtime
On 5/6/07, Nathan [EMAIL PROTECTED] wrote: pis there a comparable python packaging system that works for a good portion of Linux distributions? (I'm NOT talking about rpm's, ebuilds, etc.) people have previously posted about pyinstaller to this list, and it's web page says it can package as executables for linux (I've never used it myself): http://pyinstaller.python-hosting.com/
Re: [pygame] PyGame Runtime EGGS
I like it.. I don't know crap about jars (which is what they compared it to).. But it seems to me it would be better compared to APT. . APT solved a lot of these same problems in Linux. . Just my 2 cents Dennis --- On Sun 05/06, Laura Creighton [EMAIL PROTECTED] wrote: From: Laura Creighton [mailto: [EMAIL PROTECTED] To: pygame-users@seul.org Date: Sun, 06 May 2007 22:04:29 +0200 Subject: Re: [pygame] PyGame Runtime Python eggs are supposed to be the way to go.see:http://blogs.nuxeo.com/sections/blogs/lennart_regebro/2006_04_13_easter-python-eggshttp://peak.telecommunity.com/DevCenter/PythonEggsbut not http://www.python-eggs.org/ which doesn't appear to have anythingto do with the topic at all.But I have never made one.Laura ___ Join Excite! - http://www.excite.com The most personalized portal on the Web!
Re: [pygame] PyGame Runtime
Will McGugan wrote: I know installers aren't that difficult to create. I've used Inno-setup myself, it's an excellent system - but its still a hurdle that most PyGame coders don't want to tackle So maybe what we want is an extension of py2exe that not only creates an executable but an installer as well? -- Greg
RE: [pygame] PyGame Runtime
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Ewing Sent: Monday, 7 May 2007 12:42 p.m. To: pygame-users@seul.org Subject: Re: [pygame] PyGame Runtime Will McGugan wrote: I know installers aren't that difficult to create. I've used Inno-setup myself, it's an excellent system - but its still a hurdle that most PyGame coders don't want to tackle So maybe what we want is an extension of py2exe that not only creates an executable but an installer as well? Or a separate Python module to create Windows installers, which py2exe could then use? BB The information contained in this transmission is confidential. It is intended for the named address only. If you are not the named address you may not copy, distribute or take any action in reliance upon this transmission
Re: [pygame] PyGame Runtime
Nathan wrote: is there a comparable python packaging system that works for a good portion of Linux distributions? (I'm NOT talking about rpm's, ebuilds, etc.) Someone needs to get all the Linux distributors, bang their heads together and make them come up with a single packaging system that works on all distributions. And MacOSX .app bundles would be a good thing to model it on. -- Greg
