[pygame]
unsubscribe pygame-users
[pygame] unsubscribe pygame-users
unsubscribe pygame-users
Re: [pygame] growing out of idle ide
I really like geany http://www.geany.org/ it's a very lightweight ide for anything with a clean, ituitive user interface. I've used it for my python and c projects. On Tue, Aug 16, 2011 at 9:58 AM, Mac Ryan wrote: > > > I don't particularly like Eclipse... seems pretty bloated especially > > > for Python. For a Java developer I'm sure it's great but I don't > > > get a happy feeling when I start it up, and for us game programmers > > > it's all about the happy. > > It is bloated, yet - after having tried a lot of various IDE's - I > still think it's the best free (as in freedom) choice if you care for > debugging, git integration, plugins for other syntax (yaml, json...), > etc... True: it takes 20 seconds to fire up, but then [at least for me] > it's open the best part of the day and it's snappy enough even on my 5 > years old laptop. > > > > Is anybody particularly enthusiastic about their IDE? Anybody use a > > > black-on-white or similar color scheme? > > I recently tried Ninja (http://ninja-ide.org/) it's specifically > designed for python, light, and supports color schemes. Current stable > version is 1.1 with version 2.0beta coming out 23/9. Personally I found > it still too rudimental to win over gedit with the appropriate plugins, > but nevertheless I liked the approach the devs have chosen, and look > forward to see what version 2.0 will bring up. > > /mac >
Re: [pygame] Making animation.
You could do some of those effects as a normal animation. But I think what you're really looking for is "particle effects", especially for smoke, fire, water splashes, etc. there's tons of information on this on the internet and a few python 3rd party libraries. Basically you need to draw lots of tiny sprites that "emit" from a location and have a physics algorithm to make them move like the effect you want for a certain lifespan and that use different alpha values and blend modes to make them look like the effect you want when piled on top of each other. Devon On Fri, May 27, 2011 at 12:53 PM, BIAGINI Nathan wrote: > I am wondering how can i make some effetcs in my pygame 2d game. I mean per > effects an explosion, a fog, fire, water etc... Its made as normal > animation? ( several images ) or i have to use pyopengl and some rendering > function or i dont know what... ( dont know how pyopengl works ). > > Thanks.
Re: [pygame] Re: (pyopengl) GLSL fragment shader with arrays uniform cause sporadic screen blinking
You may want to check out http://www.opengl.org/wiki/GLSL_Uniform#Implementation_limits . You can check the uniform limits of your video card with glGetIntegerv(GL_MAX_FRAGMENT_UNIFORM_COMPONENTS, yourReturnVar) On Fri, Feb 11, 2011 at 4:31 PM, amdlintuxo wrote: > THE PROBLEM IS SOLVED by decreasing array elements at stage of > declaration in shader from 100 down to 20. > > > > On Feb 12, 1:09 am, Devon Scott-Tunkin > wrote: > > Thehttp://bpaste.net/show/13617/is not the same because the glsl > compiler > > will usually compile out (make inactive) all of your uniforms since you > > aren't referencing them in the shader. I often find this very annoying > for > > testing. > All time forgot this, thanks for clarification. > > > I've often had problems with arrays in glsl, and never got them to > > work correctly in os x. You could try using a 1D texture lookup if the > > arrays are the problem. > Unfortunately i don't know how to implement my desires other way, so > for now i will go with arrays, but keep you advice in my mind. > Thanks. > > > > I don't really understand what you are trying to do in your pixel shader, > > you could get rid of all of the else's and just put gl_FragColor at the > end > > of main and it would have the same effect. Your loop just changes the > final > > uv, so in effect you don't even need a for loop because your code will > > always just make the end color by using imax-1. Everything else gets > > overwritten. > I am not strong in programming. First my task was is to get it working > fine, the next stage will optimize code and make it looks better. > The reason i have chose this way - i am not sure if i will stuck in > future and have to change the whole render method(shader) or not. It > happens several times. > Thanks for advices, as now it works as i would expected i will make > shader looks better following you comments and post it here. >
Re: [pygame] (pyopengl) GLSL fragment shader with arrays uniform cause sporadic screen blinking
My laptop also has a 945gm so I can't test this until I get to my desktop (although glsl shaders will work on os x with a 945gm, intel only supports arb shaders in windows opengl). The http://bpaste.net/show/13617/ is not the same because the glsl compiler will usually compile out (make inactive) all of your uniforms since you aren't referencing them in the shader. I often find this very annoying for testing. I've often had problems with arrays in glsl, and never got them to work correctly in os x. You could try using a 1D texture lookup if the arrays are the problem. I don't really understand what you are trying to do in your pixel shader, you could get rid of all of the else's and just put gl_FragColor at the end of main and it would have the same effect. Your loop just changes the final uv, so in effect you don't even need a for loop because your code will always just make the end color by using imax-1. Everything else gets overwritten. Devon On Fri, Feb 11, 2011 at 12:37 PM, amdlintuxo wrote: > Hi all. > > Strange sporadic screen blinking when using array uniform variables in > fragment shader. > Unfortunately i have only one HW config to test this(maybe the problem > is in my HW) > > The strange is: > The problem occurs with shader > http://bpaste.net/show/13616/ > even if i pass empty arrays into it (imax = 0), so actually shader > should do any distortion work. > > And the problem DOES NOT occur with shader > http://bpaste.net/show/13617/ > > So it has to be something in my shader, but i was thought that code > http://bpaste.net/show/13617/ is the same as (http://bpaste.net/show/ > 13616/ + if imax = 0) > But why screen blinking occurs? Actually without uniform arrays, by > passing only simple uniform shader works great. > > Full code is here: > http://bpaste.net/show/13615/ > > Could some one test the full code or provide the idea what can cause > sporadic screen blinking. > Looking forwards for you support, i have nothing left to try to > resolve this problem, struggling third day, no luck. Maybe this > blinking is my HW config problem. >
Re: [pygame] New Apple and MS stores. Pygame support?
Well Apple flip-flopped in the summer so now their guidelines seem to suggest you could "theoretically" develop an iOS app in python.But as always, expect Apple to change their minds on a dime and be very selective about what their vague guidelines actually mean. “… Based on their [our developers] input, today we are making some important changes to our iOS Developer Program license in sections 3.3.1, 3.3.2 and 3.3.9 *to relax some restrictions* we put in place earlier this year. In particular, *we are relaxing all restrictions on the development tools used to create iOS apps*, as long as the resulting apps do not download any code. This should give developers the flexibility they want, while preserving the security we need.” 3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. 3.3.2 — An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple's built-in WebKit framework. -Devon On Tue, Oct 26, 2010 at 12:53 AM, Bill Coderre wrote: > OK, so based on my own reading of the guidelines, and based ONLY on the > languages of implementation, here's what I think is the case: > > For iOS apps (iPhone, iPod Touch, iPad): The app you submit to Apple must > have been written in Objective-C and use the standard iOS APIs. Note that > you could write your app in Python, then use a hypothetical Python-to-ObjC > converter, and that MIGHT be acceptable. There are apps in the store right > now that contain Lua, and some that were originally written in Adobe Flash > (yick) and then converted. BUT, I don't know of any way to convert Python to > Objective-C. It'd be a pretty massive undertaking, and since the iPhone is > not exactly a speedy CPU, if the resultant app was too slow (which is more > than possible), Apple would not accept it into the store. > > But Apple just announced a new "Mac App Store," which has very different > requirements. First off, apps MAY be written (and shipped) in Python, as > long as it is 100% compatible with the Python that is installed as part of > Mac OS X 10.6.latest. (Unfortunately, Apple has just announced that they are > "deprecating" Java, so no App-store apps using Java will be accepted.) > > Note that on neither platform may you download code over the internet and > run it, or allow the user to type in code, and then run it. (It's a security > issue, because Apple will digitally sign your code, and if the checksum > fails, you're busted.) > > This means that you have to have a single "bundle-style" application > program that launches when you double-click it. To Unix geeks, a > "bundle-style application" is a directory with the extension ".app", and the > directory contains various files and directories in a defined structure. > (The executable has to be in a certain spot, the text and graphics in > certain other spots, and any add-on libraries (PyGame) have to be either > hard-compiled in, or linked as "framework" libraries in yet another certain > location.) > > The take-away, though, is that for Mac "apps," only thing you can rely on > is Python being installed. Not X-Windows, not PyGame, not even non-standard > fonts. Everything other than Python, you have to wrap up and put inside your > bundle. And if you can wrap it up, you can use it. > > I don't know of any app that has been done in that format, but it's not > impossible to do. Making a "hello world" python app meet these criteria > wound probably take an hour. Adding PyGame might be a few evening project, > or it might require a custom wrapper (many days of C coding), I don't know. > > Note also, and this is most important: This "Mac App Store" is NOT going to > be the ONLY way to distribute apps. It is a NEW way, and stuff that's in the > store will certainly get a lot of attention, so if you were to get an app in > there, it's pretty likely you'd have a lot of new friends, or paying > customers. But all the existing ways of distributing apps are still allowed. > > Also: The Mac App Store is very tightly controlled by Apple, and by Apple's > lawyers, and there are like 100 more criteria specified, so if you're > interested, you need to research carefully. If you want to submit to the > store, you have to sign a pretty beefy license agreement, and pay $99/year > for the "provisioning profiles" (digital signature certificates). And, of > course, if Apple catches you trying to hack their system, you can be certain > that your apps will be removed, and your license will be revoked. > > The deal on pricing is simple: You pick the price, and you get paid 70% of > it. Apple keeps 30%, and Apple handles the billing and pays the host-side > bandwidth. (If your app is free, Apple still pays for the hosting.) > > > > On Oct 25, 2010,
Re: [pygame] Faster OBJ loader
It should be noted that display lists are deprecated (but for all intents and purposes still there) in the anti-fixed function opengl 3.1+ (and perhaps completely unavailable in open gl es 2.0?). So learning vbos is probably a good idea, and like display lists it also means you aren't passing vertex arrays over the graphics bus on every draw call because the vertex arrays are stored on the graphics card. The advantage of vbos over display lists is you can store static or dynamic data, the disadvantage is you can only store certain kinds of data and not operations, so on some cards display lists are still faster than vbos. Devon On Tue, Sep 28, 2010 at 1:05 PM, Ian Mallett wrote: > On Mon, Sep 27, 2010 at 8:05 PM, Christopher Night > wrote: > >> Thanks for the response! Assuming that rendering means what I think it >> means (actually drawing the thing on the screen, right?), >> > Absolutely. > >> I was able to improve the rendering performance significantly using vertex >> arrays in the test I did a few months ago. I was still using a display list >> as well, but I greatly reduced the number of GL commands within the display >> list. The trick was to triangulate all the faces, and render all the faces >> for a given material using a single call to glDrawArrays(GL_TRIANGLES...). I >> realize this is hardware-dependent, but the speedup was dramatic on 2 out of >> 2 systems that I've tried. Maybe it's not the vertex arrays that matter, and >> triangulating all the faces and using a single call to glBegin(GL_TRIANGLES) >> would yield the same speedup. Either way, it's worth looking into I >> think >> > You must not be using the calls as you think you are, then. Graphics cards > have a "graphics bus" that handles data transfer to and from the card. > Unfortunately, this graphics bus is slower than either the CPU or the GPU > themselves. > > Fixed function (glVertex3f(...), glNormal3f(...), etc.) sends the data to > the card on each call. So, if you have 900 such calls, you send 900 state > changes to OpenGL across the graphics bus each time the data is drawn. This > can get slow. > > Vertex arrays work similarly, except the data is stored as an array, and > the equivalent of the 900 fixed function calls are sent across the graphics > bus each frame. Although this batched approach is faster than fixed > function, all the data is still transferred to the card each time the data > is drawn. > > Display lists work by caching operations on the graphics card. You can > specify nearly anything "inside" a display list, including fixed function > (and I think) vertex arrays. To use display lists, you wrap the drawing > code in glGenLists()/glNewList() and glEndList() calls. The code inside, > after being transferred to the GPU, is stored for later use. Later, you can > call glCallLists(), with the appropriate list argument. The list's NUMBER > is transferred to the GPU, and the relevant set of cached operations is > executed. The practical upshot of all this is that each time you draw the > object, you pass a single number to the graphics card, and the appropriate > cached operations are executed. This is the way the Wiki .obj loader > works. > > Vertex Buffer Objects are a more advanced topic, but they work by caching > vertex arrays on the GPU. > >> Improved loading performance comes from the fact that these arrays can be >> pickled, so you don't have to read them directly from the OBJ file after the >> first time. You only need to distribute the pickled OBJ/MTL files with your >> actual game. Psyco or C might be just as good, but this solution was pretty >> simple, and reduces the (subsequent) load times to almost nothing. >> > This is actually a fantastic idea; I love it! > >> -Christopher >> > Ian >
Re: [pygame] 127.5
Practical graphical applications often use textures to store data as well. Deferred renderers store all the geometry data in a gbuffer texture for example. For screen space ambient occlusion and many other screen space lighting techniques people often render a float linear depth in one channel and the per pixel normal in the remaining channels. When you start wanting per pixel 3d vectors of any kind its nice to have 32-bit precision available. -Devon On Fri, Jul 30, 2010 at 9:25 AM, Luke Paireepinart wrote: > On Fri, Jul 30, 2010 at 9:10 AM, Ian Mallett wrote: > > The problem: > > Because of this, I need a surface filled with the color 127.5. > Obviously, > > more than 8 bits per channel are required. To update the texture, I'm > using > > GL_RGBA32F_ARB, which allocates 32 bits per channel. Unfortunately, the > > base image created by PyGame has a value of 127 ≈ -0.00196 velocity. In > > practice, this leads to "drift" in the simulation. Can something be done > to > > send a 32 bit per channel surface filled with 127.5 values to the OpenGL? > > > Is it really 32 bits _per channel_ and not total? > I've never heard of that much bit depth before, why would that > possibly be necessary? I mean for practical applications, not using > textures to store data so you can use shaders to run your sim :P > -Luke >
Re: [pygame] Pygame vs XNA
Granted, you CAN use python (or any .net language, F# anyone?) with XNA if you just want to build for windows... I On Mon, Jul 26, 2010 at 11:02 AM, Devon Scott-Tunkin < devon.scotttun...@gmail.com> wrote: > XNA provides a lot of built-in functionality for 3D games. None of it is > very advanced, ie. vector math, hlsl shader loading, cameras and lights, > bounding sphere and aabbox collisions, fbx and .x model loading... but it is > easier and quicker to get going with 3D with XNA than with pygame + opengl > or directx. XNA also has xbox 360, zune, silverlight and windows mobile 7 > support which PyGame doesn't. If you want 2D I would say the apis provide > similar functionality with PyGame having some more advanced raster > functionality and XNA having better video hardware acceleration and sprite > batching. PyGame has the advantage of being open source and cross-platform > to other oses and non-microsoft portable devices, and probably supports > older computer hardware better. Also python is way more fun and less of a > headache to use than C#, although it will be considerably slower than C# in > some areas (Since the heavy drawing stuff is in the C SDL binary for pygame > it shouldn't be a huge issue though). > > Devon > > On Mon, Jul 26, 2010 at 9:16 AM, Thadeus Burgess wrote: > >> Having "Develop XNA games as a hobby and deploy them to the Windows >> Game network" on your resume is much more appealing to an employer. >> >> It really depends on what platform you want to develop for. If you >> want cross-platform, use pygame >> . If all you care about is windows/xbox, then use XNA. >> -- >> Thadeus >> >> >> >> >> >> On Mon, Jul 26, 2010 at 4:12 AM, René Dudfield wrote: >> > hi, >> > >> > there's a free book here: >> > http://inventwithpython.com/ >> > >> > Otherwise there's lots of examples and tutorials that come with pygame. >> > >> > cheers, >> > >> > On Mon, Jul 26, 2010 at 9:36 AM, Hokan LUNDBERG wrote: >> >> >> >> Hi! >> >> >> >> What would you say are the advantages and disadvantages of Pygame >> compared >> >> with XNA? >> >> >> >> I found a good book (*) on XNA in PDF for free. Is there something >> similar >> >> for Pygame? >> >> >> >> Regards, >> >> Hokan >> >> >> >> >> >> (*) >> >> >> http://www.lulu.com/items/volume_66/7658000/7658212/1/print/CBennettXNA2D31.pdf >> > >> > >> > >
Re: [pygame] Pygame vs XNA
XNA provides a lot of built-in functionality for 3D games. None of it is very advanced, ie. vector math, hlsl shader loading, cameras and lights, bounding sphere and aabbox collisions, fbx and .x model loading... but it is easier and quicker to get going with 3D with XNA than with pygame + opengl or directx. XNA also has xbox 360, zune, silverlight and windows mobile 7 support which PyGame doesn't. If you want 2D I would say the apis provide similar functionality with PyGame having some more advanced raster functionality and XNA having better video hardware acceleration and sprite batching. PyGame has the advantage of being open source and cross-platform to other oses and non-microsoft portable devices, and probably supports older computer hardware better. Also python is way more fun and less of a headache to use than C#, although it will be considerably slower than C# in some areas (Since the heavy drawing stuff is in the C SDL binary for pygame it shouldn't be a huge issue though). Devon On Mon, Jul 26, 2010 at 9:16 AM, Thadeus Burgess wrote: > Having "Develop XNA games as a hobby and deploy them to the Windows > Game network" on your resume is much more appealing to an employer. > > It really depends on what platform you want to develop for. If you > want cross-platform, use pygame > . If all you care about is windows/xbox, then use XNA. > -- > Thadeus > > > > > > On Mon, Jul 26, 2010 at 4:12 AM, René Dudfield wrote: > > hi, > > > > there's a free book here: > > http://inventwithpython.com/ > > > > Otherwise there's lots of examples and tutorials that come with pygame. > > > > cheers, > > > > On Mon, Jul 26, 2010 at 9:36 AM, Hokan LUNDBERG wrote: > >> > >> Hi! > >> > >> What would you say are the advantages and disadvantages of Pygame > compared > >> with XNA? > >> > >> I found a good book (*) on XNA in PDF for free. Is there something > similar > >> for Pygame? > >> > >> Regards, > >> Hokan > >> > >> > >> (*) > >> > http://www.lulu.com/items/volume_66/7658000/7658212/1/print/CBennettXNA2D31.pdf > > > > >
Re: [pygame] GSoC 2010: A New Draw Module
Congratulations Julian, looking forward to it. Devon On Sun, May 2, 2010 at 6:00 PM, Luke Paireepinart wrote: > Yay. > Pygame has needed this for a LONG time. > Good luck! Keep us updated. > > On Sun, May 2, 2010 at 5:55 PM, jug wrote: > > Hello! > > > > I'm going to write a new draw module for pygame and pygame2 as part of > > GSoC this year. The aim is to have one draw module for pygame that > > implements not only the very basic drawing of a few plain color shapes > but > > also drawing of more advanced shapes and whith more advanced attributes > > (ie. curves, rounded corners, aa, etc.) as well as alternative filling > > methods > > (ie. procedural or image based textures, filling from another > surface/image > > (cloning), etc.). Unlike now the code will be object oriented thus you'll > > need to create a (pen) object before using it to draw stuff. That is to > to > > keep > > code clean and structured and avoid functions with (terribly) long > parameter > > lists. However, I plan to add some shortcuts for basic functionality (and > > maybe > > compatibility). > > > > I'm still thinking about concepts and have some more vague ideas in mind > so > > if you have any ideas or suggestions please tell me :) > > > > > > While development I'll blog about any progress at > > http://pygamedraw.wordpress.com/ > > > > Even though I've got svn access to the pygame repo (thank you, rene) I > also > > have a (currently still empty) hg repo with wiki and issue tracker at > > http://bitbucket.org/schlangen/pygamedraw > > > > > > Regards, > > Julian > > >
Re: [pygame] informal poll on Windows python version
windows 7 python 2.6 On Thu, Apr 29, 2010 at 2:46 AM, Chris Van Bael wrote: > Windows XP SP3 in VirtualBox on Windows 7 or Ubuntu (I'm very hesitant > to build executables on Windows 7) > Python 2.6 (just switched over from 2.4 without problems) > Pygame 1.9.1 >
Re: [pygame] Info on writing pygame game for iPodTouch / iPhone?
Cydia is for jail broken iphones. You can't use python in the app store until someone makes a static version that compiles into the app. which should theoretically be possible since there are static ruby and .net apps in the app store... but afaik there have been no python ones. Otherwise you need objective-c, at least for the the interfacing with the iphone libraries, but the compiler can link and compile c++ after the intial glue/setup code. On Tue, Apr 6, 2010 at 7:10 AM, Alex Nordlund wrote: > There's PyObj-C in Cydia > > --- > //Alex > "Look boys, the graphical part is done. Now we just have to code it!" > --tdist > > > > On Tue, Apr 6, 2010 at 12:43 PM, Jake b wrote: > > Phil, I know you've made a couple ports to the iPhone. > > How much work / how hard it is to write an iphone app? > > > > Do I have to use c++, or can it be completely in python / tinypy? [ I > have > > experience in c++, but it's a been a while. ) > > > > -- > > Jake > > >
Re: [pygame] DMs, what are you doing?!
I plan on trying to do the 7 day roguelike challenge March 6-14th. But it will probably be turn based. http://groups.google.com/group/rec.games.roguelike.development/browse_thread/thread/96fae2f059d0b2b2 On Sun, Feb 14, 2010 at 5:27 PM, B W wrote: > I'm curious. :) > > Is anybody out there working on a dungeon crawler? > > My interests travel specifically along this line: > >- RP with a storyline and character building >- PVE >- real-time combat and movement (not turn-based) >- melee-range-magic >- not too deep in stats or skills >- plans for network co-op a plus > > Gumm >
Re: [pygame] unsubscribe
It's all about the tools folks. Unity has a leg up there. On Sun, Jan 31, 2010 at 6:56 PM, ryan wrote: > unity3d is awesome. Its got a few less that desirable limitations here and > there, it also needs some serious help in doing FPS games right now. But for > point and click games or sidescroller games, its the best ive found. The > rate at which you can get things functioning in unity3d engine, that > actually feel good in controls and gameplay mechanics, is really impressive. > > and no I still have not figured out how to unsubscribe this thing, but I > think I got it now > > > On Sun, Jan 31, 2010 at 12:10 PM, Brian Fisher > wrote: > >> Proprietary, yes, but Unity is cross-platform, not a windows product. To >> Wii, iPhone and the web browser plugin as well - although the platforms are >> all so different you'd need to change lots about a game to target all those >> effectively, it's not a major win. And since Unity is built on Mono, once >> mono supports the Dynamic Language Runtime extensions of .NET, IronPython >> could be used for unity. Then it will taste like snakes. Which taste like >> chicken. >> >> ... but it does not run on OLPC... >> >> On Sun, Jan 31, 2010 at 12:14 AM, Bryce Schroeder < >> bryce.schroe...@gmail.com> wrote: >> >>> Unity3D? Eeew. Windows. Proprietary. And I bet it tastes like gophers, >>> too. >>> >>> >> >
Re: [pygame] Re: Announce: PygWeb2.0rc
> > Yes, the "code" tab is the one handled by Trac (with its own templates and > style sheets). Okay, then I probably just forgot to update the trac one when I changed the django one, I'll fix that. It would be so nice if I could figure out how they could use the same style sheets... Devon On Mon, Dec 7, 2009 at 8:00 AM, jug wrote: > B W wrote: > >> I like the aesthetics of your redesign, and the layout is very >> friendly. >> > > Thanks. > > > I'm curious to see if your conversion will fix HTML-wrapping >> issues like this: http://www.pygame.org/wiki/2DVectorClass. And >> whether project screenshots will be ported and the default N/A images >> will be replaced. >> >> > > I don't see any errors there. > Since the pygame developers who run pygame.org are not interested in the > website, it will (probably) run as a individual website, independent of > pygame.org (if anyone is interested, email me). In this case, it will not > migrate any data from pygame.org. > We did not migrate screenshots for the demo cause its just a lot of data > (of course it would be possible). > > > One content-related feedback. This occurs on the following converted >> "snippet" from the Pygame Code Repository. >> >> http://pygameweb.no-ip.org/snippets/28/ >> >> The original distribution bundles files critical to the code's >> function. While your converstion exposes the code for convenient >> viewing--a very nice touch--it seems to have lost the other >> components: an image file, and POV files if anyone should want to dig >> into the 3D image with POV. I predict this would be a frustrating >> discovery for anyone wishing to see the code in action. >> >> I do not know how many are like this, but I'm sure you would want to >> follow up on it, in the spirit of insuring converted content is >> "either unchanged or improved". :) >> >> > > There are a few snippets that have additional data like images or extra > files with it. Normally, Snippets (on pygWeb) are just code and maybe some > explanatory text. Thus, migrating additional files it not possible (when > using a converter script). Of course these extra data may be important. Not > for the demo, but for a productive usage. The problem is, that there is no > option for normal users to attach any files to snippets (which is, I think, > basically appropriate). So these snippets either have to work without > additional data or host this data somewhere else and link to it or use the > wiki that allows attachments (but is not meant for code hosting). > > > > Devon Scott-Tunkin wrote: > >> I can't remember right now if the code was using different templates than >> the rest of the site. >> > > Yes, the "code" tab is the one handled by Trac (with its own templates and > style sheets). > > > -- Julian >
Re: [pygame] Re: Announce: PygWeb2.0rc
> > if clicking on the "code" tab, the whol website recenter and has smaller > width (1024) than before. you may have to test with high browser > resolution > I should look into this though, sounds like the code css is overriding the other widths. I don't think he was complaining that it was too wide, Julian, just that the code section did not match the rest of the site. I can't remember right now if the code was using different templates than the rest of the site. Thanks again for the feedback everyone, Devon On Sun, Dec 6, 2009 at 7:49 AM, jug wrote: > Hey, > > Thanks for the feedback. > > > I have a suggestion: If you download a code snippet, it gets named like >> '49.py' or '55.py'. But a filename would be more useful, like >> 'ZoomScreen.py' instead of '55.py >> > Good idea, I've changed that. > > > if clicking on the "code" tab, the whol website recenter and has smaller >> width (1024) than before. you may have to test with high browser >> resolution >> > I know that. Not yet sure whats better. The smaller, fixed width was the > original style, but sometimes its not enough space for the entire content > (logged in as admin or with very long user name). > > > I only have one question; how is updating the new site different from the >> old? Is the Django site still serving most things from static pages and >> just using the database to store comments and such, or did they use one of >> the little CMS doo-dads available for use with Django? >> > The site runs with an own database. Currently its sqlite, but since its > done with Django, most other db backends should work as well. All content > except the documentation is stored in the database. It's possible to convert > data from the current pygame.org db, but you cannot use the same data or > database without converting. > > > The issue is some people felt Jug and the others went ahead without proper >> discussion before-hand. >> > Some people wanted to rewrite the website as well, but not with Django. The > discussion got nowhere fast, so we just started (otherwise, I think we would > be still discussing). Also, those who wanted to write a website with other > tools, did not do that (afaik). The same applies to the details. You cannot > discuss every single detail on such a mailing list. Everyone has his own > opinion, but you can only implement it one way. So we did it how we deemed > it right and then showed it to the list so that everyone could have a look > at it, test it, and tell us whether it is ok or he found any no-go's. > > > -- Julian >
Re: [pygame] Standard methodology for different game screens
A state machine or stack is a usual way to do it, where each state/scene has its own update stuff and event handling and the pygame loop just uses the current scene. --- On Sat, 9/19/09, Pablo Moleri wrote: > From: Pablo Moleri > Subject: [pygame] Standard methodology for different game screens > To: pygame-users@seul.org > Date: Saturday, September 19, 2009, 1:13 PM > Hello, > > I'm going through a game code > written in pygame, the game shows different screens: > - an introduction > > - a menu > - and then it enters to different game modes. > > For each of these parts there's a different pygame > loop, which doesn't seem right. > I would like to know if there's a standard way to use > pygame in this scenario. > > > Thanks in advance, > Pablo > > >
Re: [pygame] moonlight 2.0
I'm no expert, but I believe it would require porting the whole api to wrap the silverlight drawing api. There was also a project mono.xna that was trying to have xna calls wrap sdl and opengl, which you could use from ironpython as an alternative. But true pygame 1:1 api would take a lot of work, which would probably be better spent just porting your game to use whatever graphics engine moonlight or mono uses, but simply using ironpython to access it instead of c#. Devon --- On Mon, 8/17/09, machinim...@gmail.com wrote: > From: machinim...@gmail.com > Subject: [pygame] moonlight 2.0 > To: "pygame-users" > Date: Monday, August 17, 2009, 12:55 PM > hi, > > ...again a pygame in the webbrowser topic. :) > > http://go-mono.com/moonlight-beta/ > i just noticed that the moonlight 2.0 beta is out. > moonlight 2.0 supports the DLR and ironpython. > > did anyone here have a look into moonlight/silverlight > already? how feasible would it be (and how much work?) to > create a pygame "layer" for moonlight/silverlight? > what do you think? just curious... >
Re: [pygame] how to remove spam comments in pygame wiki
Thanks for the bugs. IE7 also has some graphical issues with the menu that I still need to address. Devon --- On Fri, 7/31/09, claudio canepa wrote: > From: claudio canepa > Subject: Re: [pygame] how to remove spam comments in pygame wiki > To: pygame-users@seul.org > Date: Friday, July 31, 2009, 11:37 PM > > > On Sat, Aug 1, 2009 at 12:55 AM, > Devon Scott-Tunkin > wrote: > ... This is something I have put > much thought into and I believe using a combination of fluid > width with maximum and minimums is the best solution for > single column pages and have chosen this design instead of > fixed width or completely fluid width. > > > > > As webpagesthatsuck.com > will tell you in its list of no-nos for web design: > > -Our site uses liquid design. > > -Our site uses fixed-width design. (You can't win. > Liquid is wrong on wide-screen monitors because you have > line lengths that are hard to read — and vice versa.) > > > > you just can't win ;). > > > > but if you want the objectivity behind my decisions please > read: > > http://www.humanfactors.com/downloads/feb03.asp > > > > I find it interesting that this study notes kids prefer ~45 > characters per line and then web 2.0 sites popular with kids > (myspace (shudder), facebook, blog templates etc) all have > extremely short fixed-length line lengths for their content > columns. > > > > > best, > > > > Devon > > Specific > content adds additional constraints to the width conundrum; > look at > http://pygameweb.no-ip.org/snippets/4/ > some code lines are truncated to fit, very bad for > code.And adding a horizontal scroll bar is not > really a solution.The projects column adds > nothing to the page value, and takes real state better to be > used for code. > (additional note for this specific page: IE7 cannot > save this page as html plus images; only as .mht > ) --claxo >
Re: [pygame] The great pySchism, was: how to remove spam comments in pygame wiki
ditto everything Brian just said. Devon --- On Fri, 7/31/09, Brian Fisher wrote: > From: Brian Fisher > Subject: Re: [pygame] The great pySchism, was: how to remove spam comments in > pygame wiki > To: pygame-users@seul.org > Date: Friday, July 31, 2009, 10:24 PM > On Fri, Jul > 31, 2009 at 6:53 PM, Nirav Patel > wrote: > > It seems this is going in a direction detrimental to > everyone's cause, > > and I do mean everyone. Please, lets be civilized about > this and try > > to come up with a middle ground. > > > I appreciate that you would like to find > a situation where people can work together - but did you > have any middle ground in mind? Cause I don't really see > any right now. > > > First, It is clear that having two pygame websites will do > nothing but > > confuse the community of users and developers. > > I disagree with this. The other things that having two > pygame websites would do (besides cause confusion) is show > in what ways the new site being constructed is or isn't > going to actually be any better than the current one; and it > would create competition and comparisons between the two. > Good ideas implemented well on one side will inspire and > educate the other. > > > Besides, having two websites for pygame users for a while > doesn't mean there will be two websites forever. If one > wins, the other will probably die, one way or another. A > little confusion in the short term may well be worth it in > the end. > > > It is also clear that > > the current pygame website has flaws. > If by flaws you mean spam comments on the doc pages, I > agree but that is very easily fixed without doing any > "new site" development at all. If you mean > anything besides that, I think to say it has flaws is > overstating the condition. It very much achieves what it > went out to achieve. > > > What I would agree is that there are many opportunities > which could be pursued - I appreciate that Jug and Devon > want to pursue them, but quite frankly they are speculative > improvements, the true value of which is unproven. So it > seems to me that the impass is Jug and Devon said they > didn't want to work from the existing site or it's > underlying technology or framework - while Rene doesn't > want to deal with the cost of switching the site over to > another system for the mere promise of the improvements they > want to bring. > > > The only way I see to really resolve this and come up with > the "middle ground" you want is to let the ideas > and possible value of the new site that has started > development become an actual reality. > > > > Finally, it is clear that > the > > new website being proposed is not acceptable to replace the > current > > one. > > > I don't think that it is all that > clear exactly what the website will become. > > What the new website being proposed is, is just a proposal. > And that proposal is currently to throw out everything on pygame.org and > develop using a > system that the current site developer/maintainers have no > experience or desire to work with, for a bunch of features > whose value to the community seems good on paper, but in the > end is not actually clear. > > > If, on the other hand, the website being proposed becomes a > reality though, and people who use it think it's super > awesome, and it looks like it will likely be well > maintained, then the new proposal would be something like > "migrate the project data over, migrate the site over > to the main server, and then let everyone love the > awesomeness", which is a very different proposal. > > > > > > I understand that not everyone wants mailing list traffic > about it, > > but I think the first step would be to not have a seperate > closed > > mailing list discussing website development. Discussing > it here > > allows everyone to debate about features/implementation > without > > building it first and then getting rejected. > > > > I agree with keeping it on list - > but I have to ask, are pygame-users > offended/annoyed/displeased by the mailing list traffic on > this? I'm not aware of anybody who has said so. Have you > heard from anyone who is? > > > I can't speak for Zack, but when he posted > "Let's do our best to keep drama off the mailing > list" I interpreted it to be more like saying people > should keep their posts practical and professional instead > of being emotional - as opposed to saying "take it off > list guys" > > > >
Re: [pygame] how to remove spam comments in pygame wiki
Not fixed width, max width. There's a difference. You can have min widths as well. It's not either or. Full width is just as much of a copout, it is no more difficult to simply expand the content section of a page than to make everything fixed width. That's not being smart or creative, that's using a feature just because it's there (also common with wii developers). When layout is ALL css it's as easy switching from fixed to max with as changing one line of code.I'm all for full width if the designer does something good with it, like create columns of text or search results when you expand not just make the descriptions hard to read. Or actually moving widgets and menus around the screen and not just moving them linearly. I am not that courageous or talented and neither is google or amazon. But until browsers are all standards compliant no one really can be and have billions of users using dozens of browsers. Dealing with tiny minimum widths is what is difficult (and would cause problems with our website menu, which is why we have a minimum width as well) and notice that amazon DOES have a minimum width. I have found google to create frustrating user experiences at times, and at other times quite wonderful ones. I do find amazon frustrating to use on a large widescreen monitor. Do I want to have to move my mouse that far to click search? (well, I should be hitting enter...). > also, I think you are mistaken in believing that a > website could possibly set how many characters per line a > browser shows. True, but using em measurements (the width of an M at the current font and size) instead of px can get you in a close enough range in 99% of the cases. Thank you for your sympathy (any web designer needs it), but please allow me my opinion on full width pages. Your opinion is just as valid and I do appreciate it. This is something I have put much thought into and I believe using a combination of fluid width with maximum and minimums is the best solution for single column pages and have chosen this design instead of fixed width or completely fluid width. As webpagesthatsuck.com will tell you in its list of no-nos for web design: -Our site uses liquid design. -Our site uses fixed-width design. (You can't win. Liquid is wrong on wide-screen monitors because you have line lengths that are hard to read — and vice versa.) you just can't win ;). but if you want the objectivity behind my decisions please read: http://www.humanfactors.com/downloads/feb03.asp I find it interesting that this study notes kids prefer ~45 characters per line and then web 2.0 sites popular with kids (myspace (shudder), facebook, blog templates etc) all have extremely short fixed-length line lengths for their content columns. best, Devon --- On Fri, 7/31/09, Brian Fisher wrote: > From: Brian Fisher > Subject: Re: [pygame] how to remove spam comments in pygame wiki > To: pygame-users@seul.org > Date: Friday, July 31, 2009, 4:48 PM > It makes me sad to hear a web designer > say that :( > > I do respect how difficult and limiting designing for full > horizontal scaling can be, but quite frankly the web is > simply better full width. Also, I think to imply that > usability "suffers" for all non-fixed width > designs is an obviously wrong statement, and in my opinion, > just a cop out. In my experience, google & amazon made > the right choice letting the content grow horizontally. Do > you find their pages to have poor readability and usability? > Cause if you do, the objective formalized testing with real > customers those companies have done disagrees with your > opinion. > > > also, I think you are mistaken in believing that a > website could possibly set how many characters per line a > browser shows. > > All that being said, I'm terribly sympathetic with how > hard the web design stuff can be as your testing matrix of > browsers and window widths explode, and I'd never judge > somebody for sticking with fixed width restrictions for that > reason. Just please don't claim it's > "better" for the user. :) > > > > On Fri, Jul 31, 2009 at 2:10 PM, > Devon Scott-Tunkin > wrote: > > > > As the designer of the new site I'm against that idea > on principle. > > > > I really hate using pages with no max width on widescreen > monitors as it forces me to resize my window to read the > pages. Readability and usability suffer with expanding > width pages after a certain width, which is why I like > having max widths. I don't think any readability is > gained by having more than 80-100 characters per line, and > that readability and usability is actually hindered. I > could probably increase the max width slightly, but
Re: [pygame] how to remove spam comments in pygame wiki
I don't like minimum widths either but I like to maximize programs often and not tweak with resizing them. Why should the user have to make a program usable? It should do it for them, while still allowing for small adjustments. I believe the site should be readable and user friendly at most resolutions without the user having to do squat. Devon --- On Fri, 7/31/09, Greg Ewing wrote: > From: Greg Ewing > Subject: Re: [pygame] how to remove spam comments in pygame wiki > To: pygame-users@seul.org > Date: Friday, July 31, 2009, 8:02 PM > Brian Fisher wrote: > > > On Fri, Jul 31, 2009 at 2:10 PM, Devon Scott-Tunkin > <mailto:djvonfun...@yahoo.com>> > wrote: > > > > I really hate using pages with > no max width on widescreen monitors > > as it forces me to resize my > window to read the pages. > > I don't follow that. Why set your browser window wider > than you find comfortable for reading in the first > place? > > What annoys me is sites that impose a *minimum* width > on a page, so that I have to either scroll horizontally > or fill the whole screen up with my browser window so > that there's no room for anything else. > > -- Greg >
[pygame] The great pySchism, was: how to remove spam comments in pygame wiki
>The Pygame website is a completely separate project, privately funded and >run. I hope you are talking about the old site, otherwise that IS a good joke. Our rewrite is not funded or intended to be privately run, although it could be. Although it may remain OBSCURELY run because of people having large toes that are easy to step on. Devon --- On Fri, 7/31/09, Zack Schilling wrote: > From: Zack Schilling > Subject: Re: [pygame] how to remove spam comments in pygame wiki > To: pygame-users@seul.org > Date: Friday, July 31, 2009, 9:26 AM > On Jul 31, 2009, at 5:43 AM, jug > wrote: > > > René Dudfield wrote: > >> Hello Jug, > >> > >> I'm not interested in working with you or your > website. This is the last reply I'll make to you. > >> > >> bye. > > "PYGAME - An Open Source Community Project" > > > > haha, good joke! > > Let's do our best to keep drama off the mailing list. > Pygame is still an open source community project. The Pygame > website is a completely separate project, privately funded > and run. > > -Zack
Re: [pygame] Improving pygame web docs
"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] how to remove spam comments in pygame wiki
As the designer of the new site I'm against that idea on principle. I really hate using pages with no max width on widescreen monitors as it forces me to resize my window to read the pages. Readability and usability suffer with expanding width pages after a certain width, which is why I like having max widths. I don't think any readability is gained by having more than 80-100 characters per line, and that readability and usability is actually hindered. I could probably increase the max width slightly, but I do not want it over 100 characters for the main page column, it is at 80 something now I believe. Devon --- On Thu, 7/30/09, Greg Ewing wrote: > From: Greg Ewing > Subject: Re: [pygame] how to remove spam comments in pygame wiki > To: pygame-users@seul.org > Date: Thursday, July 30, 2009, 8:01 PM > Ian Mallett wrote: > > > It's harder to read because the page is narrower. > > I would say don't try to control the page width at > all. Let it flow to whatever size the browser window > is. > > -- Greg > > >
Re: [pygame] status report
Bah, I like the colors (Do you mean teal? There's not very much green in there any more?) and the arch linux site is boring (although clean and well structured), which fits with arch linux, but not pygame :). Although there will be a second "classic" theme based on the older revision if any one remembers (--and I will work on it this weekend, I promise, Julian). It will be simple and like the arch linux one and in fact already has almost the exact same menu design, but will use green instead of blue. Devon --- On Fri, 7/10/09, el lauwer wrote: > From: el lauwer > Subject: Re: [pygame] status report > To: pygame-users@seul.org > Date: Friday, July 10, 2009, 1:45 AM > Hoi, > > I like the new logo, and it seems to work ok. > > I would however try to use a lot less green, I think you > should try something like the archlinux site > http://www.archlinux.org/ > > > On 10-jul-09, at 08:19, René Dudfield wrote: > > > > > Hi, > > > > I'll get you the pygame database soon... quite busy at > the moment. After the pygame release. I was > going to give it earlier. Sorry again. > > > > cheers, > > > >
Re: [pygame] resources for edge tile algorithm
Well since the forest is drawing outside sides when on top, and the dirt is drawing inside sides, probably something going wrong there. Perhaps it IS drawing the side dirt tile, but it is drawing the wrong cardinal side/position so the forest is showing through? But it is hard for me to tell which part is wrong from the screen shot. Does the problem happen if you draw forest on the bottom, but have an "island" of dirt on top? Devon --- On Thu, 7/2/09, Michael Fiano wrote: > From: Michael Fiano > Subject: Re: [pygame] resources for edge tile algorithm > To: pygame-users@seul.org > Date: Thursday, July 2, 2009, 9:02 PM > My transitions are split into 4 sides, > 4 corners, and 4 curves. If I set forest to be > 'higher' than dirt, it draws as expected - See > screenshot: http://bloodcurse.axedcode.net/images/1.png > . However, if I swap the order so that dirt draws over > forest, I'd expect the circular dirt patches to be > completely over the dark green forests. Instead, you can see > that the sides of the forest are always drawn over the dirt, > making it pretty ugly looking. See screenshot: > http://bloodcurse.axedcode.net/images/2.png > . Here is what I did in pseudo-code: > > > for depth in range(4): > if depth > tile.order: > for type in terrain_types: > draw_sides() > draw_corners() > draw_curves() > > orders are: > water (not shown): 0 > > plains (lt. green grass pattern): 1 > dirt (circular lt. green patches): 2 > forest (dk. green): 3 > > Does anyone have any idea why the sides are drawing in the > wrong order? > > On Tue, Jun 30, 2009 at 5:41 PM, > Michael Fiano > wrote: > > Fawkes, > Yes, my rock is actually on a separate layer that is > supposed to be drawn after the base terrain, but it seems it > has to be reorganized as somehow the transitions are drawn > after the 2 layers with my recent changes. > > > > On Tue, Jun 30, 2009 at 9:52 AM, > Fawkes > wrote: > > > Michael, > Please correct me if I'm not interpreting > what you're trying to do right. > For things like your rocks, rather than handling them > within the terrain map, we just made a separate > "Landmarks" layer for things like rocks, houses, > statues, etc that was drawn on top after the terrain stuff > got drawn. > > > > > ~Fawkes > > > > >
Re: [pygame] resources for edge tile algorithm
I don't know if this is helpful but I came across it the other day. http://www.gamedev.net/reference/articles/article934.asp I believe it's basically just saying that when creating the top transition tile layer check the 8 surrounding tiles of each tile on the screen (or the whole generated map if you want) to see if they are of a lower terrain type then the current tile. If so, apply the correct transition tile to use from a tilesheet indexed the same as the for loop doing the checking or however you want to keep track of which edge of the tile you're currently checking. I haven't done it myself, but if you get something working let me know. I am planning on doing the same thing in one of my projects but it is a ways off. Devon --- On Wed, 6/24/09, Michael Fiano wrote: > From: Michael Fiano > Subject: [pygame] resources for edge tile algorithm > To: pygame-users@seul.org > Date: Wednesday, June 24, 2009, 9:07 PM > I am looking into edge tile placement > algorithms for 2D square tile > maps, for the pygame 'bloodcurse'. The idea is I > have a layer of square > tiles representing each type of terrain laid down. Then > another layer > with transparent curves is layered over the top of the > previous layer > to create transitions from terrain x to y. I can do this > fine manually, > but I was wondering what similar ideas anyone has done, or > any relevant > links on the subject? Ultimately, layer 1 will be randomly > generated, > and 2 will have to follow. > > > Thanks >
RE: [pygame] Alpha channels and per pixel alpha
What are you trying to do with the alpha channel? Just a transparent
background? Are you drawing something on the alpha channel in photoshop? Just
adding one doesn't really do anything, the alpha channel has to have , pixel
data too, just like the rgb channels.
If I want to make a jpg transparent in parts I usually just unlock the
background layer and then erasing it or magic wanding it or quick masking or
however you want to make something transparenty-like will work. Make sure you
see the "checker-box" pattern to know its transparent, if its still white or a
color its not transparent. Then just save it as a normal png, I don't know what
a superpng is.
--- On Wed, 6/10/09, Bjorn Samuelsson wrote:
> From: Bjorn Samuelsson
> Subject: RE: [pygame] Alpha channels and per pixel alpha
> To: pygame-users@seul.org
> Date: Wednesday, June 10, 2009, 6:03 PM
>
>
>
> #yiv1831619233 .hmmessage P
> {
> margin:0px;padding:0px;}
> #yiv1831619233 {
> font-size:10pt;font-family:Verdana;}
>
>
>
> 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: [pygame] Pygame Website Rewrite: First alpha version ready for testing
Thanks. She's right about the teal gradient:). The current design is VERY alpha, more basic layout to get started then anything and I'm really just playing with the colors at this point. Adobe kuler is also good for color schemes. Devon --- On Sun, 5/24/09, Tyler Laing wrote: > From: Tyler Laing > Subject: Re: [pygame] Pygame Website Rewrite: First alpha version ready for > testing > To: pygame-users@seul.org > Date: Sunday, May 24, 2009, 4:17 PM > Hi, lots of good work there. I sent > over your current design, as of sun may 24, 2:02 PM, to an > artist friend of mine. Also, I sent her the old design. She > had some advice and criticisms: > > "The gradient must disappear. On the > first one and on both of them the dark green does not match > the yellower-based greens. They need > to pick a theme of green thoughout. Not teal green and then > toss in some lime. It just doesn't match or coordinate > at all." > > > "What they really need is a > blend of the new site and the old. Because the new site is > too sparse and the old one is too busy without having > good-looking dividers." > > About the new site design: "Just make > sure that their greens match. The > white background's(for the new site) not bad but > it's pretty stark. I'd say maybe the > best thing would be just a solid background, or just take > out that big image and do a simple texture on the background > paired with a smaller, more modest header image. > Also the tables in the white are very > boring. They should have better borders or a little > color." > > > If you want to use green, she suggests using this website > to pick a color scheme: http://bighugelabs.com/flickr/colors.php > > Just remember, if you don't like the advice, you > don't have to listen to her, but it is advice intended > to make the site better. :) > > > -Tyler > > On Sun, May 24, 2009 at 1:48 PM, > jug > wrote: > > Hello, > > > > A first version of the rewritten pygame.org > website is ready for testing: > > > > http://pygameweb.no-ip.org/ > > > > Main focus is on project management and user system. News > are also > > yet available. Feel free to register or log in with > guest/guest, create and > > edit projects, releases, screenshots and your profile or > vote the > > (dummy-)project of the month. > > > > Devon is still working on the design and often changes it. > > > > For development organization we use Trac and a mailing list > at google groups. > > More information at http://pygameweb.no-ip.org/trac/wiki/. > > > > If you spot any bugs or have an idea for this first version > thats not > > already on our ToDo list (http://pygameweb.no-ip.org/trac/wiki/ToDo) > > create a ticket. > > > > There was a problem with email and Trac, but now, all > registration > > and email stuff should work. > > > > Regards, > > Julian > > > > > -- > Visit my blog at http://oddco.ca/zeroth/zblog > >
Re: [pygame] audio programming with pygame?
There's also the pure data "language" http://puredata.info/ --- On Sat, 5/23/09, Alexandre Quessy wrote: > From: Alexandre Quessy > Subject: Re: [pygame] audio programming with pygame? > To: pygame-users@seul.org > Date: Saturday, May 23, 2009, 8:46 AM > Hi, > ChucK is also an awesome language for sound synthesis. It > uses the STK library. > I can't wait until there is a STK Python binding ! > > a > > 2009/5/23 Olaf Nowacki : > > maybe you would like to try supercollider for making > the synthesizers and > > use pygame as UI? > > > > http://pypi.python.org/pypi/SC/0.2/ > > http://supercollider.sourceforge.net/ > > > > On Fri, May 22, 2009 at 11:02 PM, machinim...@gmail.com > > > wrote: > >> > >> hi, > >> > >> i would like to learn how to program simple > synthesizers and sound effects > >> and it would be nice if i could experiment with > this in python. > >> > >> http://en.wikipedia.org/wiki/Jeskola_Buzz > >> would something like buzz theoretically be > possible with pygame? > >> > >> of course python is slow but if buzz was able to > handle hundreds of > >> machines on the hardware of 10 years ago then a > hand full should be possible > >> in python today? > >> > >> is low level sound programming possible with > pygame at all or are only > >> higher level audio features exposed? > > > > -- > Alexandre Quessy > http://alexandre.quessy.net/ >
Re: [pygame] starting the rewrite
I don't know either framework, but I'm partial to Django becuase of: http://en.wikipedia.org/wiki/Django_Reinhardt --- On Fri, 5/1/09, Casey Duncan wrote: > From: Casey Duncan > Subject: Re: [pygame] starting the rewrite > To: pygame-users@seul.org > Date: Friday, May 1, 2009, 1:35 PM > I would vote that anyone not actually > working on the website gets no vote in how it is implemented > 8^). I think armchair web jockeying should be limited to > features and aesthetics, if anything. > > How many folks are actually working on this? > > -Casey > > On May 1, 2009, at 12:12 PM, Jake b wrote: > > > Maybe we need a vote thread. > > > > 1st line: pick your framework > > 2nd like: amount of work you expect to put in. > > > > No discussion, just vote tallies, so we can see if > it's definitely one > > sided, and to stick with that. [ keeping discussion in > another thread > > ] > > > > I 2nd shaun. I can write css/php/html, but haven't > volunteered yet > > since I haven't used django/cherrypy. So I could help > if you have > > access to that level. [ Haven't written a website in > py yet, but it > > sounds fun. ] > > --Jake > >
Re: [pygame] starting the rewrite
>We are still searching for a web-designer, so please help us. >Over again, please write your name to the list there if you'd like to >>participate. which list where? err what's the link? I thought I got on the google list, and then I tried to join the first one (trac?) but it never sent me the e-mail. I don't have a lot of web design experience, but I am trying to get some. I currently work mostly as a print designer (while also going to grad school for game dev), but I know css/html well enough. I can make some photoshop mockups for different styles for people to discuss, or hack the current pygame css to look pretty in the meantime. I assume there will be a basic css template eventually (possibly more) for the whole site with django generating the html from a database, but I am not familiar with django or web backends beyond some basic php/mysql. Devon my website is minimal and very static. I don't like the design much anymore, but it does have an interesting css menu system. http://www.devonscott-tunkin.com I managed to make my wikka wiki look pretty recently, but since it's a personal wiki I haven't yet fixed some of the ie bugs and other rough patches that require php hacking: http://wiki.devonscott-tunkin.com/ --- On Thu, 4/30/09, jug wrote: > From: jug > Subject: [pygame] starting the rewrite > To: pygame-users@seul.org > Date: Thursday, April 30, 2009, 7:08 PM > Hello, > > Today, I started to write some first lines of code for the > new pygame.org website and > just checked it into SVN. For further questions I'd like to > create tickets in the > development-trac (and maybe write here a mail with a > link). > We are still searching for a web-designer, so please help > us. > Over again, please write your name to the list there if > you'd like to participate. > > > Regards > Julian > > >
Re: [pygame] PyGame Website Rewrite
I'd like to help on the graphics side, the current site kind of looks like the python threw up all over the place. --- On Tue, 4/21/09, jug wrote: > From: jug > Subject: [pygame] PyGame Website Rewrite > To: pygame-users@seul.org > Date: Tuesday, April 21, 2009, 3:38 PM > Hello, > > Even if it was not selected as a project for GSoC, I would > like to do the pygame website rewrite. > Like the other applicants, I'd do that with Django. Now > that there can not only be one student/participant, > it would be cool to work together and combine forces. > > Since I applied for GSoC, I've already made a small > concept. Merging multiple implementing-/design ideas > may become difficult, but before I go into detail just say > me if you are interested. > > Regards > Jug >
Re: [pygame] Google Summer of Code participation
>Please do not mix font and image formats up. Focus on one of them, as >implementing a bit of this and a bit of that is unlikely to be >accepted. The main reason for this is that both are completely different >areas and as such need several special considerations and probably API >design changes to get all - to be planned - features into them. I'll focus on one before I apply then, probably image formats, depending on which I understand best and find more interesting after some research. >SVG would be some cool and huge task, I guess. As there is no >cross-platform SVG library (to my knowledge and no, cairo-svg's not the >best option here) to rely on, this would be a nice project and require >you to show us some good work of you (because SVG is a complex topic). ImageMagick does SVG, although incomplete. I don't know how useful that would be. Inkscape's libnr might be something to look at, although it might be saying something that they use cairo for faster rendering in outline mode. If I had to roll my own from scratch, yeah that would very likely be beyond my current capabilities for the summer. Devon --- On Wed, 3/11/09, Marcus von Appen wrote: > From: Marcus von Appen > Subject: Re: [pygame] Google Summer of Code participation > To: pygame-users@seul.org > Date: Wednesday, March 11, 2009, 2:11 PM > On, Wed Mar 11, 2009, Devon Scott-Tunkin wrote: > > > > > I'd like to apply for gsoc 2009 in pygame when the > time comes. I'm > > Great! > > > doing an MS in Game Development (programming), but > have spent my first > > year taking undergraduate prerequisites in computer > science classes as > > my background is in graphic design and not > programming. That leaves me > > probably at a beginning undergrad junior level in > computer science. > > That's no problem at all. > > > Coming from graphic design I'm interested in > adding more font and > > graphic file supports to pygame. I know C reasonably > well, but I > > haven't really looked at the C parts of pygame or > even fiddled with > > the pygame python source, only used the api. > > Ideally those tasks could be done on a clean pgreloaded > branch (yes > ma'am, I'm strongly advocating here). It's API > is a lot cleaner than > pygame's at the moment, so a clean backport could be > done once > anything's settled. > > > > > To get ready to apply, obviously it would be good for > me to review > > some of the pygame source, build pygame, and maybe > even write a few > > tests. As well as researching the technical side of > implementing new > > fonts and image format conversions as I am very > familiar with using > > many types of both, but conversion routines for images > I only have a > > general idea that different formats store the channel > bytes and pixel > > arrays in different ways. > > > > Please do not mix font and image formats up. Focus on one > of them, as > implementing a bit of this and a bit of that is unlikely to > be > accepted. The main reason for this is that both are > completely different > areas and as such need several special considerations and > probably API > design changes to get all - to be planned - features into > them. > > > > > Implementing SVG or some sort of basic vector image > support is a > > related project I'd like to do, but may be out of > scope if I end up > > working on font and raster image format support. > > > > SVG would be some cool and huge task, I guess. As there is > no > cross-platform SVG library (to my knowledge and no, > cairo-svg's not the > best option here) to rely on, this would be a nice project > and require > you to show us some good work of you (because SVG is a > complex topic). > > > > > Do you have any other suggestions for me? Ways to > improve my chances? > > Code examples I should write or focus on? > > Depending on what you want to do in the end, show us what > you did > already (projects, etc.) when it comes to applying (and we > got some > slots from Google). The easier the project, the less you > would have to > show ;-). > > However, first we will have to be accepted as > organisation... > > Regards > Marcus
Re: [pygame] Google Summer of Code participation
I'd like to apply for gsoc 2009 in pygame when the time comes. I'm doing an MS in Game Development (programming), but have spent my first year taking undergraduate prerequisites in computer science classes as my background is in graphic design and not programming. That leaves me probably at a beginning undergrad junior level in computer science. Coming from graphic design I'm interested in adding more font and graphic file supports to pygame. I know C reasonably well, but I haven't really looked at the C parts of pygame or even fiddled with the pygame python source, only used the api. To get ready to apply, obviously it would be good for me to review some of the pygame source, build pygame, and maybe even write a few tests. As well as researching the technical side of implementing new fonts and image format conversions as I am very familiar with using many types of both, but conversion routines for images I only have a general idea that different formats store the channel bytes and pixel arrays in different ways. Implementing SVG or some sort of basic vector image support is a related project I'd like to do, but may be out of scope if I end up working on font and raster image format support. Do you have any other suggestions for me? Ways to improve my chances? Code examples I should write or focus on? Devon --- On Tue, 3/10/09, Nirav Patel wrote: > From: Nirav Patel > Subject: Re: [pygame] Google Summer of Code participation > To: pygame-users@seul.org > Date: Tuesday, March 10, 2009, 3:14 PM > On Tue, Mar 10, 2009 at 3:26 AM, Marcus von Appen > wrote: > > Done. I added a news entry and a new ideas page at > > http://pygame.org/wiki/gsoc2009ideas > > I updated the ideas page to be categorized into Easy, > Medium, and Hard > projects. Most of the projects are still unsorted, so any > help > completing and sorting project ideas would be appreciated. > > Nirav
Re: [pygame] GMArcade Contest, PyGame Users Invited
I agree, I find this info interesting and related to pygame users. If someone is annoyed by non technical marketing for contests or activities then that person can simply ignore those messages. Devon --- On Mon, 1/19/09, pymike wrote: > From: pymike > Subject: Re: [pygame] GMArcade Contest, PyGame Users Invited > To: pygame-users@seul.org > Date: Monday, January 19, 2009, 10:39 PM > Thanks for the info, Matt. :-) > > On Mon, Jan 19, 2009 at 9:09 PM, Noah Kantrowitz > wrote: > > > Okay, this is now officially annoying me. Get your own > mailing list and > > stop cross-posting to this one. > > > > --Noah > > > Umm, people always post announcements here for game > competitions/activities > that invite PyGame (PyWeek, LudumDare, etc.) What's the > big problem here? > > -- > - pymike > "Python eggs me on."
Re: [pygame] Re: Working on Retro 80s Game SDK, Looking for general support
Does it use its own map format? or did you use a basic txt or graphics file format? Have you looked at the pgu editor code for examples? they might be helpful, even though I kind of hate them :). never know when map sizes are too big for it. This project sounds great though, XML objects is something I've been meaning to try. I'm an even worse programmer still, otherwise I'd help (and I'm busy trying to learn in my own projects), and I'm also becoming more interested in making a similar thing in c++ using sfml these days. One suggestion I have is to abstract the engine enough that you could port it to use another graphics engine (or any component) if you want to in the future without altering the way the classes and functions work, only what they wrap or use. Devon --- On Tue, 1/6/09, The Music Guy wrote: > From: The Music Guy > Subject: [pygame] Re: Working on Retro 80s Game SDK, Looking for general > support > To: pygame-users@seul.org > Date: Tuesday, January 6, 2009, 10:26 PM > Good point. I was sort of thinking the same thing, actually. > I don't > think I'll be able to start testing anything, though, > until I have a > basic world editor ready, otherwise it will be very > difficult to > create any test levels. > > On Jan 6, 5:39 pm, Casey Duncan > wrote: > > On piece of advice I have is to create actual games > with the system as > > early as possible, especially before the apis and > features have > > completely solidified. It's very helpful to point > out awkward or > > missing parts of the system. > > > > -Casey > > > > On Jan 6, 2009, at 4:23 PM, The Music Guy wrote: > > > > > Hello all, > > > > > There are two purposes to this message: > > > 1.) To test my recent subscription to the Pygame > mailing list, and > > > 2.) To announce that I am working on a game SDK > that is similar (in > > > some ways) to Pgu. > > > > > My SDK is called "Scrollback," > abbreviated "sbak". At the moment, my > > > it is still just a library and is about 70% > through the alpha stages. > > > It's developed enough that one could make > some relatively simple games > > > with it, but very little of the API is actually > nailed down yet. > > > (That's one of the things I am posting > about.) > > > > > The main goals of my SDK are, in order of > importance: > > > > > 1. To be an all-in-one 8- and 16-bit era game > SDK. > > > 2. To remain as OS-independent as possible. > > > 3. To be easy for people with little or no > experience making games > > > to get a quick start. > > > 4. To be easy for beginning and novice > programmers to begin using. > > > 5. To take advantage of the Python programming > language. > > > 6. To rely on as few external libraries as > possible, even if it > > > means including 3rd-party libraries with the main > package > > > distribution. > > > > > As you can see, the main theme for my SDK is > availablility rather than > > > speed, as in many other game SDKs. > > > > > Some of the ideas of Scrollback are inspired by > Game Maker, though > > > Scrollback is far from being a GM clone. I once > had a near-guru level > > > of experience with GM, but since switching > exclusively to Linux, GM is > > > no longer much of an option. I hear a lot of > people have this problem, > > > including Mac users, so I decided to try and do > something about it. > > > While I was at it, I decided to add some features > to the mix which I > > > have felt GM has always needed. > > > > > Though I was good with GM, I'm not generally > a very good programmer, > > > and I'm going to need a lot of help, > otherwise I could see this > > > project taking decades to complete by myself. > Incidentally, I've been > > > trying to start projects like this off and on for > the last few years, > > > but kept having to start over. Now it seems > I'm finally getting > > > somewhere, and I don't want to have to start > over again. > > > > > I'm going through some issues with my web > host right now (trying to > > > get mod_wsgi activated) otherwise I would have a > wiki up with as much > > > information about this project as I have. Until I > can start the wiki, > > > here are some of the most prominent features > planned, subject to > > > change at any time: > > > > > Features which are presently implemented either > in part or in full: > > > > > * "Images", basically a kind of object > which can be drawn to a > > > surface, but has a built-in offset that is > applied every draw. > > > * "Composites", which are clusters of > Images that are drawn together > > > as a stack of layers. > > > * "Animations", which are clusters of > Images that are each drawn > > > separately at different times as > "frames", where each frame may be > > > displayed for a varying length of time. > > > * "Worlds", which are basically planes > that contain tile maps and > > > "entities" > > > * "Entities" are the physical objects > which interact with each other. > > > These would be things like the player, enemies, > proje
Re: [pygame] Geany
So I just tried Geany based on everyone's lamp love and it rocks. It is just fast, simple, small and convenient. Instead of using IDLE for python and VS2005 for C++ and tearing my hair out when they behave like unresponsive, bloated children, I have this program that just works (until my next c++ project...). Or maybe it's just the joy of using Ubuntu again instead of XP, in anycase.. Thanks guys! Devon --- On Fri, 11/7/08, pymike <[EMAIL PROTECTED]> wrote: > From: pymike <[EMAIL PROTECTED]> > Subject: Re: [pygame] Geany > To: pygame-users@seul.org > Date: Friday, November 7, 2008, 7:36 PM > If you want simplicity and speed, geany's the way to go. > > On Fri, Nov 7, 2008 at 4:08 PM, yanom @linuxmail.org > <[EMAIL PROTECTED]>wrote: > > > Uhhh. don't use Geany. use DrPython or > IDLE. > > > - Original Message - > > > From: "Matt Pearson" > <[EMAIL PROTECTED]> > > > To: pygame-users@seul.org > > > Subject: [pygame] Geany > > > Date: Thu, 6 Nov 2008 09:18:47 -0600 > > > > > > > > > is there anyway to make geany python aware??(in > regards to indention) > > > > > > > > > > > = > > Allied Video Conference Services > > Video Conference room & center near Providence; > sevicing RI, MA & CT. > > > > > http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=c533b69d222047e5b543fa818da8659f > > > > > > -- > > Powered by Outblaze > > > > > > -- > - pymike > "Stop loling into a false sense of hilarity"
Re: [pygame] Python cant read
system properties, advanced, environmental variables, variable: Path should have C:\Python; in it or whatever the path to python is. --- On Thu, 11/13/08, Matt Pearson <[EMAIL PROTECTED]> wrote: > From: Matt Pearson <[EMAIL PROTECTED]> > Subject: Re: [pygame] Python cant read > To: pygame-users@seul.org > Date: Thursday, November 13, 2008, 11:34 AM > windows xp, i though i set the path > > On Thu, Nov 13, 2008 at 11:32 AM, Luke Paireepinart > <[EMAIL PROTECTED]>wrote: > > > No, environment variables are for your whole system. > > What OS are you on? > > > > On Thu, Nov 13, 2008 at 11:30 AM, Matt Pearson > <[EMAIL PROTECTED]> > > wrote: > > > so i need to set it in Geany(my IDE)? > > > if so, for every file or just once? > > > > > > On Thu, Nov 13, 2008 at 11:27 AM, Luke > Paireepinart < > > [EMAIL PROTECTED]> > > > wrote: > > >> > > >> you need the Python directory in your PATH > environment variable. > > >> > > >> On Thu, Nov 13, 2008 at 10:54 AM, Matt > Pearson <[EMAIL PROTECTED]> > > >> wrote: > > >> > I sent out a problem about python not > being able to read scripts > > inside > > >> > of a > > >> > folder > > >> > well i forgot alot of details, forgive > me, Im using Geany as an IDE > > and > > >> > the > > >> > command > > >> > prompt is telling me this when i try to > execute. > > >> > > > >> > 'python' is not recognized as an > internal or external command, > > operable > > >> > program or > > >> > batch file. > > >> > > > >> > it wil read files if teh scripts and > images are in the python folder > > >> > with > > >> > the exe and the DLL > > >> > This is really hampering my production > flow and organization, i have > > no > > >> > idea > > >> > why its doin it > > >> > > > >> > Thanks again > > > > > > > >
Re: [pygame] sprite groups and tilesheets
its returning a list so you cant have self.image = load_sprite('player.png').
you need something like:
self.images = load_sprite('player.png')
self.image = self.images[0] #for first frame
or
self.frame = 0
self.image = self.images[self.frame]
#if you want to update it later with the different animation frames.
Here's a basic sprite class with a looping animation:
class Bob(pygame.sprite.Sprite):
def __init__(self):
self.frame = 0
self.images = load_sprite('bob.png')
self.image = self.images[self.frame]
self.rect = self.image.get_rect()
self.animcounter = 0
self.animspeed = 7
def update(self):
self.animcounter = (self.animcounter + 1)%self.animspeed
if self.animcounter == 0:
self.frame = (self.frame + 1)%len(self.images)
self.image = self.images[self.frame]
bob = Bob()
where bob.update() #would be called in the main loop
Devon
--- On Mon, 11/10/08, Michael Fiano <[EMAIL PROTECTED]> wrote:
> From: Michael Fiano <[EMAIL PROTECTED]>
> Subject: [pygame] sprite groups and tilesheets
> To: pygame-users@seul.org
> Date: Monday, November 10, 2008, 10:52 PM
> I am having problems adding my player sprite to a sprite
> group since
> self.image needs a surface, though it is a list of
> animation frames for the player in my code and I can't
> figure out what I need to do. Can anybody give me some
> pointers? Thanks.
>
> self.image = load_sprite('player.png')
>
> class load_sprite:
> def __init__(self, filename):
> self.sheet =
> pygame.image.load(os.path.join('data',
> 'graphics', filename))
> def imgat(self, rect, colorkey = None):
> rect = Rect(rect)
> image = pygame.Surface(rect.size).convert()
> image.blit(self.sheet, (0, 0), rect)
> if colorkey is not None:
> if colorkey is -1:
> colorkey = image.get_at((0, 0))
> image.set_colorkey(colorkey, RLEACCEL)
> return image
> def imgsat(self, rects, colorkey = None):
> imgs = []
> for rect in rects:
> imgs.append(self.imgat(rect, colorkey))
> return imgs
Re: [pygame] Game Maker but with Python?
I'd use Game Maker if it was multiplatform and didn't have slowdown issues so much for me. I love Python, but scripting languages all do pretty much the same thing, and if you know one you can learn them all. I think expanding on PGU to create a graphical level editor / tile engine that allowed visual placement of sprites, backgrounds, resources, and triggers would be amazing. Just the step of seeing where your putting things and handling game resources visually is so much easier to work with for those of us that grew up with Windows and its nice to see exactly what your game would look like immediately. Even if it isn't playable immediately and you still have to code all the logic. Python is a great beginner's language though. It convinced me that programming wasn't that difficult and made stepping into the backwards world of C++ much easier. Devon --- On Wed, 10/1/08, Nathan Whitehead <[EMAIL PROTECTED]> wrote: > From: Nathan Whitehead <[EMAIL PROTECTED]> > Subject: [pygame] Game Maker but with Python? > To: pygame-users@seul.org > Date: Wednesday, October 1, 2008, 4:12 PM > I just saw "100 Game Maker Games", a cool 10 > minute video that shows > the wide variety of cool games you can make with Game > Maker. > > http://playthisthing.com/100-game-maker-games > > There should be something like this but with Python and > pygame! > > My friends at UCSC have taught intro programming using Game > Maker, and > it went well but they were ultimately unhappy with GML (the > Game Maker > scripting language) as a first programming language. When > I taught > game programming I went straight for pygame and Python (of > course). > It worked out pretty well, but the students had to spend > quite a bit > of time figuring out programming concepts before they could > even get a > square moving around on the screen. > > Would you use a graphical tool like Game Maker to make your > games if > it used pygame and was extensible using Python? Why or why > not? What > would such a tool have to do to be useful? > -- > Nathan
Re: [pygame] PyGameDB coming along well
oh and you can get the BPreplay font I used which is a little more interesting and playful than arial (or helvetica, or whatever you want to call it) at dafont.com. http://www.dafont.com/search.php?psize=m&q=BPreplay --- On Wed, 8/27/08, Richie Ward <[EMAIL PROTECTED]> wrote: > From: Richie Ward <[EMAIL PROTECTED]> > Subject: Re: [pygame] PyGameDB coming along well > To: pygame-users@seul.org > Date: Wednesday, August 27, 2008, 11:42 AM > That would be great, I think I will play around with the > layout and > try different colours! > > I just need some web 2.0 buttons, gradients, whatever fancy > looking > things you can fit in to make it look snazzy. > > On Wed, Aug 27, 2008 at 4:45 PM, Devon Scott-Tunkin > <[EMAIL PROTECTED]> wrote: > > Nice start, I can barely see that light blue against > the white, so it looks more like an unintentional color > mismatch, maybe choose a slightly darker light blue for the > boxes or some sort of border? > > > > I can make some graphics if you want. > > > > Devon > > > > > > --- On Tue, 8/26/08, Richie Ward > <[EMAIL PROTECTED]> wrote: > > > >> From: Richie Ward <[EMAIL PROTECTED]> > >> Subject: Re: [pygame] PyGameDB coming along well > >> To: pygame-users@seul.org > >> Date: Tuesday, August 26, 2008, 9:30 PM > >> I have made a mockup of hypernucleus-server's > website: > >> http://4rensics.com/hnwebsite/webmockup2.html > >> > >> Opinions? It needs some more graphics i think. > >> > >> On Thu, Aug 21, 2008 at 7:35 PM, Richie Ward > >> <[EMAIL PROTECTED]> wrote: > >> > Already started to rename it to hypernucleus. > >> > > >> > On Thu, Aug 21, 2008 at 4:04 PM, Dan Krol > >> <[EMAIL PROTECTED]> wrote: > >> >> On Wed, Aug 20, 2008 at 8:55 PM, PyMike > >> <[EMAIL PROTECTED]> wrote: > >> >>> Flying PyGames! > >> >> > >> >> Pygame Circus? > >> >> > >> > > >> > > >> > > >> > -- > >> > Thanks, Richie Ward > >> > > >> > >> > >> > >> -- > >> Thanks, Richie Ward > > > > > > > > > > > > -- > Thanks, Richie Ward
Re: [pygame] PyGameDB coming along well
I played around with your template a little bit, adding some web 2.0ness and whatnot and adding some orange to make it less dull. What do you think? http://www.devonscott-tunkin.com/nonweb/HNmockupWIP.png I was going to try my hand at redoing the arrows logo later. And here's the photoshop file with all the pieces in layers, if you don't have photoshop let me know. http://www.devonscott-tunkin.com/nonweb/HNmockupWIP.psd Devon --- On Wed, 8/27/08, Richie Ward <[EMAIL PROTECTED]> wrote: > From: Richie Ward <[EMAIL PROTECTED]> > Subject: Re: [pygame] PyGameDB coming along well > To: pygame-users@seul.org > Date: Wednesday, August 27, 2008, 11:42 AM > That would be great, I think I will play around with the > layout and > try different colours! > > I just need some web 2.0 buttons, gradients, whatever fancy > looking > things you can fit in to make it look snazzy. > > On Wed, Aug 27, 2008 at 4:45 PM, Devon Scott-Tunkin > <[EMAIL PROTECTED]> wrote: > > Nice start, I can barely see that light blue against > the white, so it looks more like an unintentional color > mismatch, maybe choose a slightly darker light blue for the > boxes or some sort of border? > > > > I can make some graphics if you want. > > > > Devon > > > > > > --- On Tue, 8/26/08, Richie Ward > <[EMAIL PROTECTED]> wrote: > > > >> From: Richie Ward <[EMAIL PROTECTED]> > >> Subject: Re: [pygame] PyGameDB coming along well > >> To: pygame-users@seul.org > >> Date: Tuesday, August 26, 2008, 9:30 PM > >> I have made a mockup of hypernucleus-server's > website: > >> http://4rensics.com/hnwebsite/webmockup2.html > >> > >> Opinions? It needs some more graphics i think. > >> > >> On Thu, Aug 21, 2008 at 7:35 PM, Richie Ward > >> <[EMAIL PROTECTED]> wrote: > >> > Already started to rename it to hypernucleus. > >> > > >> > On Thu, Aug 21, 2008 at 4:04 PM, Dan Krol > >> <[EMAIL PROTECTED]> wrote: > >> >> On Wed, Aug 20, 2008 at 8:55 PM, PyMike > >> <[EMAIL PROTECTED]> wrote: > >> >>> Flying PyGames! > >> >> > >> >> Pygame Circus? > >> >> > >> > > >> > > >> > > >> > -- > >> > Thanks, Richie Ward > >> > > >> > >> > >> > >> -- > >> Thanks, Richie Ward > > > > > > > > > > > > -- > Thanks, Richie Ward
Re: [pygame] PyGameDB coming along well
I'll cook something up in the next few days. Devon --- On Wed, 8/27/08, Richie Ward <[EMAIL PROTECTED]> wrote: > From: Richie Ward <[EMAIL PROTECTED]> > Subject: Re: [pygame] PyGameDB coming along well > To: pygame-users@seul.org > Date: Wednesday, August 27, 2008, 11:42 AM > That would be great, I think I will play around with the > layout and > try different colours! > > I just need some web 2.0 buttons, gradients, whatever fancy > looking > things you can fit in to make it look snazzy. > > On Wed, Aug 27, 2008 at 4:45 PM, Devon Scott-Tunkin > <[EMAIL PROTECTED]> wrote: > > Nice start, I can barely see that light blue against > the white, so it looks more like an unintentional color > mismatch, maybe choose a slightly darker light blue for the > boxes or some sort of border? > > > > I can make some graphics if you want. > > > > Devon > > > > > > --- On Tue, 8/26/08, Richie Ward > <[EMAIL PROTECTED]> wrote: > > > >> From: Richie Ward <[EMAIL PROTECTED]> > >> Subject: Re: [pygame] PyGameDB coming along well > >> To: pygame-users@seul.org > >> Date: Tuesday, August 26, 2008, 9:30 PM > >> I have made a mockup of hypernucleus-server's > website: > >> http://4rensics.com/hnwebsite/webmockup2.html > >> > >> Opinions? It needs some more graphics i think. > >> > >> On Thu, Aug 21, 2008 at 7:35 PM, Richie Ward > >> <[EMAIL PROTECTED]> wrote: > >> > Already started to rename it to hypernucleus. > >> > > >> > On Thu, Aug 21, 2008 at 4:04 PM, Dan Krol > >> <[EMAIL PROTECTED]> wrote: > >> >> On Wed, Aug 20, 2008 at 8:55 PM, PyMike > >> <[EMAIL PROTECTED]> wrote: > >> >>> Flying PyGames! > >> >> > >> >> Pygame Circus? > >> >> > >> > > >> > > >> > > >> > -- > >> > Thanks, Richie Ward > >> > > >> > >> > >> > >> -- > >> Thanks, Richie Ward > > > > > > > > > > > > -- > Thanks, Richie Ward
Re: [pygame] PyGameDB coming along well
Nice start, I can barely see that light blue against the white, so it looks more like an unintentional color mismatch, maybe choose a slightly darker light blue for the boxes or some sort of border? I can make some graphics if you want. Devon --- On Tue, 8/26/08, Richie Ward <[EMAIL PROTECTED]> wrote: > From: Richie Ward <[EMAIL PROTECTED]> > Subject: Re: [pygame] PyGameDB coming along well > To: pygame-users@seul.org > Date: Tuesday, August 26, 2008, 9:30 PM > I have made a mockup of hypernucleus-server's website: > http://4rensics.com/hnwebsite/webmockup2.html > > Opinions? It needs some more graphics i think. > > On Thu, Aug 21, 2008 at 7:35 PM, Richie Ward > <[EMAIL PROTECTED]> wrote: > > Already started to rename it to hypernucleus. > > > > On Thu, Aug 21, 2008 at 4:04 PM, Dan Krol > <[EMAIL PROTECTED]> wrote: > >> On Wed, Aug 20, 2008 at 8:55 PM, PyMike > <[EMAIL PROTECTED]> wrote: > >>> Flying PyGames! > >> > >> Pygame Circus? > >> > > > > > > > > -- > > Thanks, Richie Ward > > > > > > -- > Thanks, Richie Ward
Re: [pygame] PyGameDB coming along well
PyFloat --- On Tue, 8/19/08, Richie Ward <[EMAIL PROTECTED]> wrote: > From: Richie Ward <[EMAIL PROTECTED]> > Subject: Re: [pygame] PyGameDB coming along well > To: pygame-users@seul.org > Date: Tuesday, August 19, 2008, 8:38 PM > Not bad, short names are nice :) > > On Wed, Aug 20, 2008 at 2:21 AM, Greg Ewing > <[EMAIL PROTECTED]> wrote: > > Hugo Arts wrote: > > > >> Back on topic: smoke, mist, or other steam > derivatives are a bit lame, > >> though I am all for a pun on steam, these are a > bit obvious. I think > >> it would also be a good idea(tm) to get either a > snake or flying > >> circus reference into the name. Anyone know any > skits that are > >> smoke/steam/hydrogen related? > > > > How about Helium? It's a gas, and it's lighter > than > > air, so you can make things fly with it. > > > > The logo could be an airship with the PyGame python > > emblazoned on the side, and a large foot hanging > > below. With a few puffs of vapour leaking from > > patched seams for added comical effect. > > > > -- > > Greg > > > > > > -- > Thanks, Richie Ward
Re: [pygame] PyGameDB coming along well
That's why I like it. --- On Tue, 8/19/08, Luke Paireepinart <[EMAIL PROTECTED]> wrote: > From: Luke Paireepinart <[EMAIL PROTECTED]> > Subject: Re: [pygame] PyGameDB coming along well > To: pygame-users@seul.org > Date: Tuesday, August 19, 2008, 4:02 PM > On Tue, Aug 19, 2008 at 2:12 PM, Devon Scott-Tunkin > <[EMAIL PROTECTED]>wrote: > > > I'm liking snake oil as well. > > > You guys know that snake oil is a term referring to items > that are said to > be good but are basically placebos, or at the worst, even > dangerous?
Re: [pygame] PyGameDB coming along well
I'm liking snake oil as well. --- On Tue, 8/19/08, Brad Montgomery <[EMAIL PROTECTED]> wrote: > From: Brad Montgomery <[EMAIL PROTECTED]> > Subject: Re: [pygame] PyGameDB coming along well > To: pygame-users@seul.org > Date: Tuesday, August 19, 2008, 2:01 PM > On Tue, Aug 19, 2008 at 1:54 PM, Richie Ward > <[EMAIL PROTECTED]> wrote: > > I like sound of SnakeOil, anyone else wanna vote on > that too? :) > > SnakeOil has my vote.
Re: [pygame] Sprite Code
I've just been doing it manually, but I haven't been doing very complicated
things.
For a jumping grasshopper:
def load_image(name):
image = pygame.image.load(name)
image = image.convert()
return image
def grasshopper_images():
image = load_image("sprite2.png")
return [image.subsurface((0,0,64,128)),
image.subsurface((64,0,64,128)),
image.subsurface((128,0,64,128))]
class Grasshopper(pygame.sprite.Sprite):
def __init__(self):
pygame.sprite.Sprite.__init__(self)
self.images = grasshopper_images()
self.image = self.images[self.frame]
def update(self):
#timed animation before jumping
if self.frame == 2:
self.animcounter = self.animcounter + 1
if self.animcounter == 30:
self.animcounter = 0
self.frame = 0
self.sound.set_volume(0.6)
self.sound.play()
self.jumping = True
return
#update image to correct animation frame
self.image = self.images[self.frame]
--- On Tue, 8/19/08, kschnee <[EMAIL PROTECTED]> wrote:
> From: kschnee <[EMAIL PROTECTED]>
> Subject: [pygame] Sprite Code
> To: pygame-users@seul.org
> Date: Tuesday, August 19, 2008, 9:46 AM
> I've been looking at my sprite code again and finding a
> different way than
> I'd used for loading animation frames. That is,
> Pygame.sprite doesn't seem
> to have any way to set up the notion of having multiple
> frames, and my old
> method involved loading a single "sprite sheet"
> image and finding a set of
> rect objects refering to sections of the sprite sheet.
>
> What I'm doing lately involves looking in a graphics
> directory
> (\graphics\sprites) for text files, loading some
> info from those, and using
> them to define the rects to be used from a sprite sheet
> image. The input is
> some simple text files and the images. The output is a
> dictionary that
> looks like this (for a sheet called "guy" having
> 4 rows of a 3-frame
> walking animation):
> {"guy":
>
> {"frame_size":(96,128),"image": 388x512>,
>"animations":{ "stand":[
> (45,[(0,0,96,128),(96,0,96,128)]) [...] ]}
> }
> }
>
> ...Well, something like that! Anyway it's listed by
> sprite, then by
> animation name (like "stand"), then by some angle
> that's used to determine
> which frames to use based on the character's facing
> direction, and finally
> as a list of rects marking the individual animation frames.
> (An alternative
> method might be to use the text files just to say things
> like "walk =
> frames 0,1,2,3" and then automatically load frames by
> number only and trust
> the program using this code to know how to use them.) With
> this code you
> should be able to auto-load all sprite data on startup and
> then, for any
> movement angle, look up which frames to cycle through.
>
> Any interest in this code? What methods do you use to get
> your sheet
> together?
Re: [pygame] Perlin Noise Function
Bullet patterns for shooters and terrain generation is what i could see using it for in 2d... Devon --- On Wed, 7/30/08, Knapp <[EMAIL PROTECTED]> wrote: > From: Knapp <[EMAIL PROTECTED]> > Subject: Re: [pygame] Perlin Noise Function > To: pygame-users@seul.org > Date: Wednesday, July 30, 2008, 4:29 PM > > > > exactly. I think this is one of the main uses for > pygame. And how many > > fun little 2 week 2d games really need/use a perlin > noise function? > > We'll probably have to agree to disagree on the > answer to that question. > > > > Don't think I can a agree to something that I have no > idea of the answer to. > :-) > > As far as graphics are concerned, that is covered very well > all over the net > and you can do all sorts of cool things with it. . I think > a great research > project would be to see how it can be used for movement in > 2d and why it > might be better than just plane random functions. > > > A bunch of links to perlin noise used to make graphics. > http://freespace.virgin.net/hugo.elias/models/m_perlin.htm > http://mrl.nyu.edu/~perlin/facedemo/ > http://www.cs.cmu.edu/~mzucker/code/perlin-noise-math-faq.html > > This is more what I was thinking about. It uses Perlin to > make 2d look life > like and not so compter like. This is what Perlin does, > simulate life like > graphics and movement. > http://www.kelvinluck.com/assets/perlin_noise_experiments/#section19 > > > Relating back to grid based proximity and sort of cool too. > http://www.gskinner.com/blog/archives/2005/02/source_code_gri.html > > -- > Douglas E Knapp > > http://sf-journey-creations.wikispot.org/Front_Page
Re: [pygame] how hexcolour arrays works?
yay graphic designers here, here, hey, hey! Devon --- On Mon, 7/28/08, Paulo Silva <[EMAIL PROTECTED]> wrote: > From: Paulo Silva <[EMAIL PROTECTED]> > Subject: Re: [pygame] how hexcolour arrays works? > To: pygame-users@seul.org > Date: Monday, July 28, 2008, 6:59 AM > Noah, i also agree completelly each person works > differently, of > course! :-) (maybe that's why i got concerned about > politeness on > pasting code here, which i didn't know how far is it > needed or not...) > - you may be from the academic world, and i'm hobbyst, > academically > from graphic design area (and still with some bad habits > from the > ansi-basic 80's coding...) > > When compaired with Perl, Ruby and Java, Python for me is > maybe the > very best language i found - it's clean, and also works > fine as script > language on Gimp, Inkscape, Blender, Scribus, etc., what is > truly > awesome for me... - and as well, Python came installed on > all Linux > and MacOS-X, what is awesome as well... > > what made me becoming so surprised with Python is i could > code there > in the same way i used to code on sdlBasic and wxBasic, and > these > codes worked fine! :-) - you know, a mere graphic designer > with a > hobbyst taste about coding, being able to code scripts for > Gimp and so > on (the python version of the .ai importer from Inkscape is > mine, as > well the Gnome menu converter for Fluxbox, for example... > :-p ), even > some small converters... why i shoutd stop coding on > Python, you > know... ? > > thanks! :-) > > > > On Mon, Jul 28, 2008 at 12:38 PM, Noah Kantrowitz > <[EMAIL PROTECTED]> wrote: > > Paulo Silva wrote: > >> > >> Stop right now? oh please, just now when i were > getting so happy on > >> trying to learn it? what a stimulation from the > open-source world... > >> :-(( > >> > >> (i really wanted only to focus in the solutions of > doubts like mine > >> one...) > > > > If Python doesn't match the way you work, I doubt > you will enjoy it. Not > > every tool is right for every job, and each person > works differently. Thats > > all. > > > > --Noah > > > >
Re: [pygame] Re: Car physics
Thank Mike, I have always wanted to make a rock'n roll racing clone... Devon --- PyMike <[EMAIL PROTECTED]> wrote: > Never mind, I converted one of DrPetter's car demos > to python, and it works > great. > if anyone's interested, it's here: > http://pymike.aftermatheffect.com/demos/cardemo-0.1.zip > > On Sat, May 24, 2008 at 9:40 AM, PyMike > <[EMAIL PROTECTED]> wrote: > > > Hi all, > > > > I've been working on making a 2D game that will > involve cars driving > > throughout a city, and I need some more or less > realistic physics for it. > > (like accelerate around, and then skid when you do > sharp turns.) > > > > I was thinking of using PyODE, but I can only find > like three examples for > > it, and they're not what I need. I can't find a > nice documentation for it > > either. > > > > Anyone have any suggestions on how to do this? > > > > PS. I'm not above "faking" the physics for it ;-) > if you want to see what > > I've done so far, my source code is here: > > > http://pymike.aftermatheffect.com/files/GTO%20Car%20Sim.zip > > > > Thanks, > > -- > > - pymike (http://pymike.aftermatheffect.com/) > > > > > -- > - pymike (http://pymike.aftermatheffect.com/) >
Re: [pygame] The introduction of my Google Summer Code Project
This looks great, I was meaning to get into Box2D but hadn't researched enough to see how easy it would be to implement into PyGame. RE: GSoC Seems like it would make more sense to use parts of Box2D or another open source physics implementation that is stable, tested, and fast, and then gut the parts that are bloat and adjust as needed. But if you want to do it from scratch, more power to you. I look forward to testing it if it gets to a useable state! Devon --- Chris Hager <[EMAIL PROTECTED]> wrote: > Hey, > > We are a team also working on 2d physics for python, > and I thought I > could maybe post a useful comment :) Congratulations > for your GSoC > project btw!! > > First of all, I think it's extremely ambitious to > write an own physics > engine, especially considering the quality of Box2d > and Chipmunk. They > are stable, quick and fully featured -- especially > Box2D being grown up > since a while and actively developed and driven by a > large community. I > think it will take a few man-years to get to that > point in terms of > stability, speed and functionality, although maybe > not all functions are > required. > > There are Python ports for both, Box2D and Chipmunk. > One is "pyMunk" > which is a CTypes Interface to the Chipmunk physics > engine > (http://code.google.com/p/pymunk/). > > The other project is called "Elements". It's on the > one side a python > port of Box2D with a SWIG Interface, on the other > side an API for easy > usage of Box2D (even for kids), and a lot of > examples and demos. We > spent a lot of time on the SWIG Interface and on > speed optimisations, as > we also run it successfully on the XO Laptop. We > also ported the (as of > yesterday) current Box2D testbed demos to python and > pygame as well as > opengl. I hope you can find a few inspirations from > our code: > > "svn co http://svn2.assembla.com/svn/elements";. > Absolutely use "python > -O ..." -- it improves the performance a lot with > these demos (up to > 100% with opengl). > > I also worked with Chipmunk and did speed tests with > both engines > (http://wiki.laptop.org/go/Physic_Engines/Speed_Tests). > Box2D (C++) is a > lot faster with Python (SWIG Interface), compared to > Chipmunk (C) with > CTypes Bindings. > > Another thing: Current 2d physic engines have > problems with concave > polygons ([1], [2]). We detect and support both, > with breaking a concave > poly up in rectangles. (Not very efficcient, but > it's very hard to find > open tessellation algorightms; many developers seem > to use the OpenGL > Tessellater ([2]), but it has a strange half-free > license [3]). > > Also the "Elements" project supports drawing with > pygame, opengl and > cairo, and we have compiled box2d libraries with > python swig interface > for windows, linux 32 and 64 bit (+ instructions for > the other > platforms). You can just copy them and start playing > around! :) > > Best, > - Chris > > [1] > http://www.box2d.org/forum/viewtopic.php?f=4&t=83 > [2] > http://www.box2d.org/forum/viewtopic.php?f=3&t=719 > [3] > http://www.box2d.org/forum/viewtopic.php?f=3&t=719&p=4200#p4223 > > -- > \___/Chris Hager > |___|GSoC '08 Mentor for OLPC -- > http://wiki.laptop.org > \___\ Elements Developer -- > http://elements.linuxuser.at > > Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: [pygame] The introduction of my Google Summer Code Project
--- Chris Hager <[EMAIL PROTECTED]> wrote: > Hey, > > We are a team also working on 2d physics for python, > and I thought I > could maybe post a useful comment :) Congratulations > for your GSoC > project btw!! > > First of all, I think it's extremely ambitious to > write an own physics > engine, especially considering the quality of Box2d > and Chipmunk. They > are stable, quick and fully featured -- especially > Box2D being grown up > since a while and actively developed and driven by a > large community. I > think it will take a few man-years to get to that > point in terms of > stability, speed and functionality, although maybe > not all functions are > required. > > There are Python ports for both, Box2D and Chipmunk. > One is "pyMunk" > which is a CTypes Interface to the Chipmunk physics > engine > (http://code.google.com/p/pymunk/). > > The other project is called "Elements". It's on the > one side a python > port of Box2D with a SWIG Interface, on the other > side an API for easy > usage of Box2D (even for kids), and a lot of > examples and demos. We > spent a lot of time on the SWIG Interface and on > speed optimisations, as > we also run it successfully on the XO Laptop. We > also ported the (as of > yesterday) current Box2D testbed demos to python and > pygame as well as > opengl. I hope you can find a few inspirations from > our code: > > "svn co http://svn2.assembla.com/svn/elements";. > Absolutely use "python > -O ..." -- it improves the performance a lot with > these demos (up to > 100% with opengl). > > I also worked with Chipmunk and did speed tests with > both engines > (http://wiki.laptop.org/go/Physic_Engines/Speed_Tests). > Box2D (C++) is a > lot faster with Python (SWIG Interface), compared to > Chipmunk (C) with > CTypes Bindings. > > Another thing: Current 2d physic engines have > problems with concave > polygons ([1], [2]). We detect and support both, > with breaking a concave > poly up in rectangles. (Not very efficcient, but > it's very hard to find > open tessellation algorightms; many developers seem > to use the OpenGL > Tessellater ([2]), but it has a strange half-free > license [3]). > > Also the "Elements" project supports drawing with > pygame, opengl and > cairo, and we have compiled box2d libraries with > python swig interface > for windows, linux 32 and 64 bit (+ instructions for > the other > platforms). You can just copy them and start playing > around! :) > > Best, > - Chris > > [1] > http://www.box2d.org/forum/viewtopic.php?f=4&t=83 > [2] > http://www.box2d.org/forum/viewtopic.php?f=3&t=719 > [3] > http://www.box2d.org/forum/viewtopic.php?f=3&t=719&p=4200#p4223 > > -- > \___/Chris Hager > |___|GSoC '08 Mentor for OLPC -- > http://wiki.laptop.org > \___\ Elements Developer -- > http://elements.linuxuser.at > > Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: [pygame] Python and Speed
>Note this is not the most efficient way to do this, >using a partitioned space you may be able to avoid >comparing most points with one another most of the >time. To do this in 2D you could use quad-trees, in >3D you could use oct-trees Just out of curiousity as a complete newbie programmer, would you set out 2d partitioning the screen in pygame by making say 4 invisible sprites with rects like say: #partition quadrants 1, 2, 3, 4 = sprites if(while?) player collides(overlaps?) with sprite 1: if player collides with enemy: do x or by just using x,y values: if player x > 0 and < 24 and player y < 50 and > 0 and player collides with enemy: do x am I even understanding partitioning correctly? please excuse these nonworking examples. Devon Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: [pygame] simple question about creating multiple instances of a sprite
Thanks, that makes sense now that I know what xrange and range are. Devon --- Greg Ewing <[EMAIL PROTECTED]> wrote: > Devon Scott-Tunkin wrote: > > Please forgive my programming ignorance, but is > there > > a simpler way to create multiple instances of a > sprite > > than say: > > > > sprite(), sprite(), sprite(), sprite(), sprite()? > > for i in xrange(5): >sprite() > > Although you may want to store references to the > created > sprites somewhere, if your sprite() function doesn't > do that itself. > > -- > Greg > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[pygame] simple question about creating multiple instances of a sprite
Please forgive my programming ignorance, but is there a simpler way to create multiple instances of a sprite than say: sprite(), sprite(), sprite(), sprite(), sprite()? Devon __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [pygame] my first game (so far)
ill have to look at it again tonight see if the controls are on my end (maybe ill also load it up on my ubuntu partition...), anyone else try this in vista? i have had 2 very odd keyboard control issues in some non pygame games before, but 2 out of the hundreds ive played on vista isn't very many. but it may be a hardware or driver issue somewhere on my end and vista. great start though, ill be excited to see it when its more done. Devon --- Michael Fiano <[EMAIL PROTECTED]> wrote: > On Mon, 17 Mar 2008 17:18:46 -0700 (PDT) > Devon Scott-Tunkin <[EMAIL PROTECTED]> wrote: > > > Hey, > > > > I liked the weird american idol like menu song and > the > > tiles look pretty cool in the graphics file. When > I > > first ran it and tried to select new game I got a > > pygame.error: music not loaded for the > > pygame.mixer.music.play in scene.py (line 28). i > > commented it out and it started (as i haven't > worked > > with sound yet in pygame myself to try and fix it > and > > am just starting oop too). then i was in a field > of > > all grass with really wonky controls that would > > sometimes not allow me to walk in certain > directions. > > > > i am using python 2.5 pygame 1.7 and windows > vista. > > > > But hey at least the guy animates nicely and does > > something! > > > > Devon > > Thanks, though the graphics and sounds are just > place-holders for nowdefinitely not the final > versions. > > As for the music error, this is because I was trying > to save space with the archive on my web server and > created a symlink for the menu music to the scene > musicwhich now that I think about shouldn't work > on non-nix systems :) As for the wonky controls, > that I cannot explain. The player can move all over > the viewable area (no scrolling yet [help?]) for me. > Anyone else want to try it on Vista, or other > versions of Windows, or other OS's? It seems to work > fine on Linux with pygame 1.7.1 and python 2.5. > > Anyway, I'm glad you like it so far. I'm quite happy > with the result so far myself being my first > OOP/game project and all. > Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: [pygame] my first game (so far)
Hey, I liked the weird american idol like menu song and the tiles look pretty cool in the graphics file. When I first ran it and tried to select new game I got a pygame.error: music not loaded for the pygame.mixer.music.play in scene.py (line 28). i commented it out and it started (as i haven't worked with sound yet in pygame myself to try and fix it and am just starting oop too). then i was in a field of all grass with really wonky controls that would sometimes not allow me to walk in certain directions. i am using python 2.5 pygame 1.7 and windows vista. But hey at least the guy animates nicely and does something! Devon --- Michael Fiano <[EMAIL PROTECTED]> wrote: > Hi all. First, I would like to thank this list, and > the #pygame channel for all the help so far in > writing my first game, which is going to be a 2D > RPG. Thank you so much! > > I started writing my first game January 1st, and I > have a long way to go, but I figured I would post my > progress so far and maybe get some suggestions for > improvement, or maybe my code can somehow help > someone else, so here it is: > > http://onyx.yi.org/sites/onyx.yi.org/files/test.tar_.bz2 > > I am currently having difficulties figuring out how > I can adapt what I have so far to scroll the world > when the player moves near the edges of the screen. > If you have any ideas, any help would be > appreciated. > > Well, enjoy the code..or don't enjoy it. I actually > expect a lot of criticism. I'm new to OOP and game > design. > Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
[pygame] scaling the entire screen
I'm completely new to this, but I've been trying to figure out if there's a way to scale an entire game to a higher resolution, like what is frequently done in emulators etc so i could allow the user to play at the low resolution or scale it higher if desired. Is there a simple way to do this? And even if there is, would that somehow mess up any game logic that uses pixels (ie sprites moving at half speed etc)? I've tried using pygame.transform.scale and scale2x on the screen, background, and display hoping one of those would magically be a surface that held all the images blitted to it and could then scale up. but it either does nothing or makes everything black if i try and copy the screen to a new screen surface. Any help or examples would be appreciated. Thanks, Devon Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: [pygame] PyDay #1
can i use grid paper? :) PyMike <[EMAIL PROTECTED]> wrote: I give up. I had made the String To Image script so people could have a little more interesting graphics, but since people are not cooperating, I'm completely changing the rules. This is driving me crazy with everyone suggesting ways of cheating. You have to use pygame.draw only. If I find someone who is drawing from any type of string, he/she will be disqualified. Compression of images is not allowed, and if I find that the competitor will be disqualified. On Thu, Feb 28, 2008 at 12:06 PM, Jason Ward <[EMAIL PROTECTED]> wrote: so how do you stop someone from drawing in an editor, converting it to a string and then copy pasting the string pixel values into the code? Why not just allow all that but it is eventually gonna cut into our precious 32000 byte limit, so it makes it fair to use editors? coz currently I don't see how we are gonna stop people from cheating, other than believing in the common good in people. :) Um I have never heard of CST before, so I googled it but I can't work out what the time in South Africa is from what I read. Can't you just say like 7:30pm at GMT+whatever your gmt is? -- - PyMike - Never miss a thing. Make Yahoo your homepage.
Re: [pygame] spritesheets and animation
I thought that might be the problem as i was just throwing in a dummy number there to try and get it to do something, otherwise it errored out if it didn't have any number there as t was not defined. I got it working from another example, but will try yours as well. I didn't really understand in the equation what t was supposed to be coming from. do i just throw the get ticks in there instead of 4? ill have to read up on subsurface, I'm completely new to all this. I'm not worried too much right now about memory as these sprites are very small (4k), although bigger ones may become an issue. Thanks, Devon Mel Collins <[EMAIL PROTECTED]> wrote: On Sunday 24 February 2008 18:09, Devon Scott-Tunkin wrote: > Thanks, now it shows up. But it doesn't animate. Just displays the 2nd > frame oddly enough... I suspect it may be because, after the initial: > self.update(pygame.time.get_ticks()) You only ever pass to the update method the number 4: > genesprite.update(4) ...which is then stored in self._last_update, and compared against the next value to come in... which is always 4! Incidentally, your Spritesheet class can probably be replaced simply by calls to .subsurface(), which has the added advantage (under most circumstances) in that it references the original image data, so doesn't use up as much memory as a copy. Incidentally #2, I wrote a generic animated-sprite class for pygame a while ago, which is more featureful than the one from piman's tutorial (which you appear to be using): http://raumkraut.net/libs/animsprite - MEl C - Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
Re: [pygame] spritesheets and animation
Thanks, now it shows up. But it doesn't animate. Just displays the 2nd frame
oddly enough...
Sean Berry <[EMAIL PROTECTED]> wrote: Please forgive me if this is totally
incorrect, I haven't worked with Sprites yet.
Looking at your code, you have a Sprite class called Gene.
You then instantiated a sprite.Group instance and called it "genesprite". But
this group doesn't actually have any sprites in it yet!
You only have one instantiated sprite, so throw it in your group after you
created it like so:
genesprite = pygame.sprite.RenderUpdates()
genesprite.add(gene)
I hope that works, good luck!
-Sean
On Sat, Feb 23, 2008 at 3:18 PM, Devon Scott-Tunkin <[EMAIL PROTECTED]> wrote:
Hi I've just started using pygame and python in general as of a week ago and
I'm probably trying to get up the mountain too soon. In the following program
I've frankensteined in order to simply repeat a 4 frame walk cycle animation, I
can't get the sprite to display, all I see is black. If anyone can point me to
what I'm doing wrong I'd appreciate it.
Thanks,
Devon
import os, pygame
from pygame.locals import *
SCREENRECT = Rect(0, 0, 320, 240)
class Spritesheet:
def __init__(self, filename):
self.sheet = pygame.image.load(os.path.join('data', filename)).convert()
def imgat(self, rect, colorkey = None):
rect = Rect(rect)
image = pygame.Surface(rect.size).convert()
image.blit(self.sheet, (0, 0), rect)
if colorkey is not None:
if colorkey is -1:
colorkey = image.get_at((0, 0))
image.set_colorkey(colorkey, RLEACCEL)
return image
#def imgsat(self, rects, colorkey = None):
#imgs = []
#for rect in rects:
#imgs.append(self.imgat(rect, colorkey))
#return imgs
def geneimages():
spritesheet = Spritesheet('sprite_gene.png')
return [spritesheet.imgat((0, 0, 16, 32), -1),
spritesheet.imgat((17, 0, 16, 32), -1),
spritesheet.imgat((33, 0, 16, 32), -1),
spritesheet.imgat((49, 0, 16, 32), -1)]
class Gene(pygame.sprite.Sprite):
def __init__(self, fps = 10):
pygame.sprite.Sprite.__init__(self)
# Track the time we started, and the time between updates.
# Then we can figure out when we have to switch the image.
self._frame = 0
self.image = self._images[self._frame]
self.rect = self.image.get_rect()
self._start = pygame.time.get_ticks()
self._delay = 1000 / fps
self._last_update = 0
# Call update to set our first image.
self.update(pygame.time.get_ticks())
def update(self, t):
# Note that this doesn't work if it's been more that self._delay
# time between calls to update(); we only update the image once
# then, but it really should be updated twice.
if t - self._last_update > self._delay:
self._frame += 1
if self._frame >= len(self._images): self._frame = 0
self.image = self._images[self._frame]
self._last_update = t
def main():
pygame.init()
screen = pygame.display.set_mode(SCREENRECT.size)
Gene._images = geneimages()
gene = Gene()
genesprite = pygame.sprite.RenderUpdates()
# Set-up background surface
global background
background = pygame.Surface(screen.get_size())
background = background.convert()
# keep track of time
clock = pygame.time.Clock()
# Blit everything to the screen
screen.blit(background, (0, 0))
pygame.display.flip()
# game loop
while 1:
# maintain frame rate
clock.tick(30)
# get input
for event in pygame.event.get():
if event.type == QUIT \
or (event.type == KEYDOWN and\
event.key == K_ESCAPE):
return
# clear sprites
genesprite.clear(screen, background)
# update sprites
genesprite.update(4)
# redraw sprites
genesprite.draw(screen)
pygame.display.flip()
if __name__ == '__main__': main()
-
Never miss a thing. Make Yahoo your homepage.
-
Never miss a thing. Make Yahoo your homepage.
[pygame] spritesheets and animation
Hi I've just started using pygame and python in general as of a week ago and
I'm probably trying to get up the mountain too soon. In the following program
I've frankensteined in order to simply repeat a 4 frame walk cycle animation, I
can't get the sprite to display, all I see is black. If anyone can point me to
what I'm doing wrong I'd appreciate it.
Thanks,
Devon
import os, pygame
from pygame.locals import *
SCREENRECT = Rect(0, 0, 320, 240)
class Spritesheet:
def __init__(self, filename):
self.sheet = pygame.image.load(os.path.join('data', filename)).convert()
def imgat(self, rect, colorkey = None):
rect = Rect(rect)
image = pygame.Surface(rect.size).convert()
image.blit(self.sheet, (0, 0), rect)
if colorkey is not None:
if colorkey is -1:
colorkey = image.get_at((0, 0))
image.set_colorkey(colorkey, RLEACCEL)
return image
#def imgsat(self, rects, colorkey = None):
#imgs = []
#for rect in rects:
#imgs.append(self.imgat(rect, colorkey))
#return imgs
def geneimages():
spritesheet = Spritesheet('sprite_gene.png')
return [spritesheet.imgat((0, 0, 16, 32), -1),
spritesheet.imgat((17, 0, 16, 32), -1),
spritesheet.imgat((33, 0, 16, 32), -1),
spritesheet.imgat((49, 0, 16, 32), -1)]
class Gene(pygame.sprite.Sprite):
def __init__(self, fps = 10):
pygame.sprite.Sprite.__init__(self)
# Track the time we started, and the time between updates.
# Then we can figure out when we have to switch the image.
self._frame = 0
self.image = self._images[self._frame]
self.rect = self.image.get_rect()
self._start = pygame.time.get_ticks()
self._delay = 1000 / fps
self._last_update = 0
# Call update to set our first image.
self.update(pygame.time.get_ticks())
def update(self, t):
# Note that this doesn't work if it's been more that self._delay
# time between calls to update(); we only update the image once
# then, but it really should be updated twice.
if t - self._last_update > self._delay:
self._frame += 1
if self._frame >= len(self._images): self._frame = 0
self.image = self._images[self._frame]
self._last_update = t
def main():
pygame.init()
screen = pygame.display.set_mode(SCREENRECT.size)
Gene._images = geneimages()
gene = Gene()
genesprite = pygame.sprite.RenderUpdates()
# Set-up background surface
global background
background = pygame.Surface(screen.get_size())
background = background.convert()
# keep track of time
clock = pygame.time.Clock()
# Blit everything to the screen
screen.blit(background, (0, 0))
pygame.display.flip()
# game loop
while 1:
# maintain frame rate
clock.tick(30)
# get input
for event in pygame.event.get():
if event.type == QUIT \
or (event.type == KEYDOWN and\
event.key == K_ESCAPE):
return
# clear sprites
genesprite.clear(screen, background)
# update sprites
genesprite.update(4)
# redraw sprites
genesprite.draw(screen)
pygame.display.flip()
if __name__ == '__main__': main()
-
Never miss a thing. Make Yahoo your homepage.
