RE: [pygame] Changelog for Pygame 1.9.2a0 vs 1.9.1
Well I could but the source is overall pretty darn large and I have not pinned it down to a particular line or two. I can tell you that when I realized 1.9.2 was an alpha and backed off to 1.9.1 plus python 2.7 (I had been doing python 2.5 and 1.9.1) the bug went away. So it seems pretty clearly tied to pygame 1.9.2a So my standpoint I am ok for now.. I will just wait till 1.9.2 goes full release and try again. The font rendering I could probably post my source.. not as elaborate. It worked but was definitely differently scaled then in 1.9.1. Do you want me to post that or email it to you? From: owner-pygame-us...@seul.org [mailto:owner-pygame-us...@seul.org] On Behalf Of Noel Garwick Sent: Wednesday, September 25, 2013 11:02 AM To: pygame-users@seul.org Subject: Re: [pygame] Changelog for Pygame 1.9.2a0 vs 1.9.1 Can you post the source? On Wed, Sep 25, 2013 at 1:32 PM, Lin Parkh wrote: Hi, I have a game running fine on pygame 1.9.1 with python 2.5.4 . I am attempting to modernize python to 2.7.5. To that end I have installed python 2.7.5 and pygame-1.9.2a0.win32-py2.7Installation worked and the program runs. However, now I get occasional odd graphical glitches (background fill showing through during some redraws). Never got this in my older installation. I did uninstall python 2.5.4 and earlier pygame. So I am trying to track down what is going on. To that end I am hoping there is a changelog for the changes in pygame from 19.1 to 1.9.2.a0 so that I can narrow down what is going on. Thanks for any pointers (I searched Google but was not having much luck finding a changelog). On a secondary note I notice font rendering has changed in its sizing (it's smaller now). I can live with this but should I be expecting to see such a change?
[pygame] Changelog for Pygame 1.9.2a0 vs 1.9.1
Hi, I have a game running fine on pygame 1.9.1 with python 2.5.4 . I am attempting to modernize python to 2.7.5. To that end I have installed python 2.7.5 and pygame-1.9.2a0.win32-py2.7Installation worked and the program runs. However, now I get occasional odd graphical glitches (background fill showing through during some redraws). Never got this in my older installation. I did uninstall python 2.5.4 and earlier pygame. So I am trying to track down what is going on. To that end I am hoping there is a changelog for the changes in pygame from 19.1 to 1.9.2.a0 so that I can narrow down what is going on. Thanks for any pointers (I searched Google but was not having much luck finding a changelog). On a secondary note I notice font rendering has changed in its sizing (it's smaller now). I can live with this but should I be expecting to see such a change?
RE: [pygame] Pygame subsurface inherit surface flags? <-- RLE encoding
This is very interesting. I had no idea. So guide me a slight bit and then Ill try to leave you alone J In the context of pygame how would I pursue RLE? My impression is I convert things into surfaces.. now it is out of my hands (it is a pygame surface) as I blit it. At what step am I intervening to RLE? If there is a link you can point me towards I will read. Put differently right now I have tons of surfaces which I blit as needed (my sprites). I understand they could be derived from originaly RLE files but once they are pygame surfaces how is RLE involved? Thanks for your time! From: owner-pygame-us...@seul.org [mailto:owner-pygame-us...@seul.org] On Behalf Of René Dudfield Sent: Thursday, September 19, 2013 12:14 PM To: pygame-users@seul.org Subject: Re: [pygame] Pygame subsurface inherit surface flags? <-- RLE encoding Yeah, Run Length Encoding :) It is faster to blit as well. Iff your image repeats the same colour a lot. The reason is you can keep the same value in a register for multiple writes of the same colour, and you can batch colour writes into a multiple of eg 8 pixels at once. There is at least one less read per pixel. Note, that some array processing libraries also use compression for array processing. Since many times after a certain amount of memory used speed comes down to memory bandwidth. On modern CPUs, you often have the CPU just waiting for memory... and you have plenty of processing cycles to spare. So you can use those spare processing cycles to decompress or compress data, therefore allowing you to "transfer" more data over memory. cu. On Thu, Sep 19, 2013 at 6:06 PM, Lin Parkh wrote: OK I didnt recognize the acronym RLE encoding but decompressed I do ;-) I see how that would save memory but wouldnt that slow graphical performance because presumably it would need to be decompressed to blit? Im not worried about memory efficiency but FPS. Please advise. From: owner-pygame-us...@seul.org [mailto:owner-pygame-us...@seul.org] On Behalf Of Lin Parkh Sent: Thursday, September 19, 2013 9:03 AM To: pygame-users@seul.org Subject: RE: [pygame] Pygame subsurface inherit surface flags? Thank you. I suspect you are right about HWSURFACE. For example I used to be able to generate these and now I cant at all with the same code! I suspect just doing a driver update to my video card squelched it. Color depth is good advice except I would have to drop my display color depth wouldnt I or I would have slow downs due to mismatch? And that would be annoying to any user. Ill look into RLE encoding. Dont know about that. From: owner-pygame-us...@seul.org [mailto:owner-pygame-us...@seul.org] On Behalf Of René Dudfield Sent: Thursday, September 19, 2013 12:28 AM To: pygame-users@seul.org Subject: Re: [pygame] Pygame subsurface inherit surface flags? Yeah, they should inherit the flags. However... you should generally avoid HWSURFACE surfaces. There are cases on some hardware and drivers where they actually get accelerated... but often they don't. If your sprites don't have many colours, dropping the colour depth will give you a speedup (less memory bandwidth used). Also RLE encoding can speed up drawing for some sprites. All the best, On Wed, Sep 18, 2013 at 9:11 PM, Lin Parkh wrote: Hi, I've read the documentation but am still hazy. If have defined a surface with specific flags (in particular pygame.HWSURFACE) should a subsurface of that surface inherit the flags (i.e. is also a hardware accelerated surface(i.e. in video card memory) or do I need to do an explicit 'convert' with the flags called again? My impression when I call 'get_flags' on the subsurface is that it is NOT getting the parent flags... but wanted to confirm this is expected and therefore I have to do an explicit convert. Thanks p.s. my overall context is I have loaded a texture atlas from file. I have given hardware acceleration flag (HWSURFACE) I now want sprite imagery derived from the atlas (subsurface seem the simplest and most efficient way to achieve this) but I want it to retain the same flags (e.g. HWSURFACE).
RE: [pygame] Pygame subsurface inherit surface flags? <-- RLE encoding
OK I didnt recognize the acronym RLE encoding but decompressed I do ;-) I see how that would save memory but wouldnt that slow graphical performance because presumably it would need to be decompressed to blit? Im not worried about memory efficiency but FPS. Please advise. From: owner-pygame-us...@seul.org [mailto:owner-pygame-us...@seul.org] On Behalf Of Lin Parkh Sent: Thursday, September 19, 2013 9:03 AM To: pygame-users@seul.org Subject: RE: [pygame] Pygame subsurface inherit surface flags? Thank you. I suspect you are right about HWSURFACE. For example I used to be able to generate these and now I cant at all with the same code! I suspect just doing a driver update to my video card squelched it. Color depth is good advice except I would have to drop my display color depth wouldnt I or I would have slow downs due to mismatch? And that would be annoying to any user. Ill look into RLE encoding. Dont know about that. From: owner-pygame-us...@seul.org [mailto:owner-pygame-us...@seul.org] On Behalf Of René Dudfield Sent: Thursday, September 19, 2013 12:28 AM To: pygame-users@seul.org Subject: Re: [pygame] Pygame subsurface inherit surface flags? Yeah, they should inherit the flags. However... you should generally avoid HWSURFACE surfaces. There are cases on some hardware and drivers where they actually get accelerated... but often they don't. If your sprites don't have many colours, dropping the colour depth will give you a speedup (less memory bandwidth used). Also RLE encoding can speed up drawing for some sprites. All the best, On Wed, Sep 18, 2013 at 9:11 PM, Lin Parkh wrote: Hi, I've read the documentation but am still hazy. If have defined a surface with specific flags (in particular pygame.HWSURFACE) should a subsurface of that surface inherit the flags (i.e. is also a hardware accelerated surface(i.e. in video card memory) or do I need to do an explicit 'convert' with the flags called again? My impression when I call 'get_flags' on the subsurface is that it is NOT getting the parent flags... but wanted to confirm this is expected and therefore I have to do an explicit convert. Thanks p.s. my overall context is I have loaded a texture atlas from file. I have given hardware acceleration flag (HWSURFACE) I now want sprite imagery derived from the atlas (subsurface seem the simplest and most efficient way to achieve this) but I want it to retain the same flags (e.g. HWSURFACE).
RE: [pygame] Pygame subsurface inherit surface flags?
Thank you. I suspect you are right about HWSURFACE. For example I used to be able to generate these and now I cant at all with the same code! I suspect just doing a driver update to my video card squelched it. Color depth is good advice except I would have to drop my display color depth wouldnt I or I would have slow downs due to mismatch? And that would be annoying to any user. Ill look into RLE encoding. Dont know about that. From: owner-pygame-us...@seul.org [mailto:owner-pygame-us...@seul.org] On Behalf Of René Dudfield Sent: Thursday, September 19, 2013 12:28 AM To: pygame-users@seul.org Subject: Re: [pygame] Pygame subsurface inherit surface flags? Yeah, they should inherit the flags. However... you should generally avoid HWSURFACE surfaces. There are cases on some hardware and drivers where they actually get accelerated... but often they don't. If your sprites don't have many colours, dropping the colour depth will give you a speedup (less memory bandwidth used). Also RLE encoding can speed up drawing for some sprites. All the best, On Wed, Sep 18, 2013 at 9:11 PM, Lin Parkh wrote: Hi, I've read the documentation but am still hazy. If have defined a surface with specific flags (in particular pygame.HWSURFACE) should a subsurface of that surface inherit the flags (i.e. is also a hardware accelerated surface(i.e. in video card memory) or do I need to do an explicit 'convert' with the flags called again? My impression when I call 'get_flags' on the subsurface is that it is NOT getting the parent flags... but wanted to confirm this is expected and therefore I have to do an explicit convert. Thanks p.s. my overall context is I have loaded a texture atlas from file. I have given hardware acceleration flag (HWSURFACE) I now want sprite imagery derived from the atlas (subsurface seem the simplest and most efficient way to achieve this) but I want it to retain the same flags (e.g. HWSURFACE).
[pygame] Pygame subsurface inherit surface flags?
Hi, I've read the documentation but am still hazy. If have defined a surface with specific flags (in particular pygame.HWSURFACE) should a subsurface of that surface inherit the flags (i.e. is also a hardware accelerated surface(i.e. in video card memory) or do I need to do an explicit 'convert' with the flags called again? My impression when I call 'get_flags' on the subsurface is that it is NOT getting the parent flags... but wanted to confirm this is expected and therefore I have to do an explicit convert. Thanks p.s. my overall context is I have loaded a texture atlas from file. I have given hardware acceleration flag (HWSURFACE) I now want sprite imagery derived from the atlas (subsurface seem the simplest and most efficient way to achieve this) but I want it to retain the same flags (e.g. HWSURFACE).
RE: [pygame] Professional games made with Pygame?
Please publish your final list. Thanks for compiling. From: owner-pygame-us...@seul.org [mailto:owner-pygame-us...@seul.org] On Behalf Of Al Sweigart Sent: Saturday, February 16, 2013 2:35 PM To: pygame-users@seul.org Subject: [pygame] Professional games made with Pygame? Hi everyone, I'm compiling a list of professional-quality games made using Pygame. These don't necessarily have to be commercial games, but games that have a professional level of quality. So far, I have: * Dangerous High School Girls in Trouble * Frets on Fire * Metin2 * Galcon * PyDance * SolarWolf * División Especial de Detectives Are there any others? Or have I added some games to this list erroneously? -Al
RE: [pygame] Mixing Colorkey and Surface alpha
Ian this is an extremely helpful answer. It will save me much pain. I have sent you a personal email thanks as well. From: owner-pygame-us...@seul.org [mailto:owner-pygame-us...@seul.org] On Behalf Of Ian Mallett Sent: Saturday, March 03, 2012 11:52 PM To: pygame-users@seul.org Subject: Re: [pygame] Mixing Colorkey and Surface alpha On Wed, Feb 29, 2012 at 12:23 PM, Lin Parkh wrote: I have two surfaces. The source surface that I am blitting has a "surface alpha" set to give me semi transparency. The destination surface has a transparent colorkey. What I would like to have happen is that source surface makes semi transparent any pixels on the destination surface that are not transparent but otherwise ignores the colorkey pixels. Is this possible? As far as I am aware, and the way you're asking, no. If you think about it, the destination surface is has binary transparency values (i.e., completely opaque or completely transparent). What sort of data would you expect to store to get a semi-transparent colorkeyed surface? My recommendation is to just use per-pixel alpha for just about everything. You can pretty easily convert a colorkeyed surface into one. At a guess, I would appreciate if the designers made .convert_alpha() do this--but if they didn't, the conversion would be pretty simple: loop through all pixels in the old surface, set the new surface's corresponding pixel's transparency to be either 0 or 255 based on what the RGB color is. If you do this, then the blending operation you described above suddenly becomes trivial. Ian
[pygame] Mixing Colorkey and Surface alpha
I have two surfaces. The source surface that I am blitting has a "surface alpha" set to give me semi transparency. The destination surface has a transparent colorkey. What I would like to have happen is that source surface makes semi transparent any pixels on the destination surface that are not transparent but otherwise ignores the colorkey pixels. Is this possible? Right now what happens is that the surface alpha of the source surface simply makes semi transparent everything on the destination surface. Including the the colorkey pixels (i.e. ones intended to stay transparent). In brief is it possible to blit a surface alphaed surface such that it does not alter transparent color on the destination source? Maybe there is some blend I should use? Thanks for any help.
RE: [pygame] Pygame Subset for Android 0.9.3 Released
Though python 2.7 was bad right? So maybe hold off on this? -Original Message- From: owner-pygame-us...@seul.org [mailto:owner-pygame-us...@seul.org] On Behalf Of Sean Wolfe Sent: Sunday, May 01, 2011 5:27 PM To: pygame-users@seul.org Subject: Re: [pygame] Pygame Subset for Android 0.9.3 Released sweet!! On Sun, May 1, 2011 at 4:47 PM, Tom Rothamel wrote: > We've released version 0.9.3 of the Pygame Subset for Android to: > http://pygame.renpy.org/ > as well as the Android Market. This new release adds the following features: > * Python has been upgraded to version 2.7.1. > * Better support for Honeycomb tablets. > * APIs for getting the screen DPI, and showing/hiding the keyboard. > * New python modules: urllib2, io, uuid, json; optionally PIL and sqlite3. > * New encodings: idna, base64, hex > This release requires a change to existing programs; the > android.init() method must be called before a program will receive input. > I'd like to welcome Patrick Dawson to the PGS4A development team - all > of the new features in this release were based on his contributions. > -- A musician must make music, an artist must paint, a poet must write, if he is to be ultimately at peace with himself. - Abraham Maslow
Re: [pygame] A* module using surfaces for walkability data
An efficient A* in python would be great! So here's a vote :-) - Original Message - From: "Forrest Voight" To: Sent: Thursday, March 26, 2009 11:48 PM Subject: [pygame] A* module using surfaces for walkability data A while ago I made a really efficient A* pathfinding module in C that is integrated with Pygame. It has all kinds of optimizations, some of which increase the speed at the expense of memory. It uses a binary heap for the open list, gridded storage for the closed list and a counter so the grid doesn't have to be cleared. It also has a system for more detailed control of allowable movements, but they are hardcoded. Last, it has 'layers' which are not actually fully implemented, but the idea is that you can have seperate Surfaces, possibly of seperate sizes that affect the costs and walkability data. For example, on the bottom you would have the actual terrain. Then you would have the fog of war layer, which could be a surface that circles are drawn to to reaveal parts of the map to the pathfinder. Right now it's not very configurable. The movement directions and costs are hardcoded. If there's any interest or possibility of it being integrated, I can make everything configurable and clean it up. To use the attached file: * run make * run python pathtest.py map.png
Re: [pygame] Redraw under mouse cursor in HWSURFACE mode
I'm using OS cursor (or whatever pygame defaults to (on windows)). Is that not good practice? - Original Message - From: Jake b To: pygame-users@seul.org Sent: Sunday, March 01, 2009 4:24 PM Subject: Re: [pygame] Redraw under mouse cursor in HWSURFACE mode are you using the OS cursor, or blit-ing your own? (ie: hide cursor, and draw cursor sprite ) On Sun, Mar 1, 2009 at 5:19 PM, Lin Parkh wrote: I'm noticing a weird little artifact namely that I get left over fragments of a surface i redraw on to screen where the mouse cursor moves. It appears as if my code is interacting with whatever controls cursor redraw. I notice that this only happens when i go to fullscreen mode and enable hardware draw (HWSURFACE (not using double buffer right now since not 'flipping display' but rather controling exactly what rectangles get redrawn). I need HWSURFACE to be on for performance. So seems like in HWSURFACE mode the mouse cursor is run differently and is interacting with my redraws (i.e. fails to let them complete well under it). Anyone familiar with this kind of mouse cursor issue in HWSURFACE mode? Thanks Lin . -- Jake
[pygame] Redraw under mouse cursor in HWSURFACE mode
I'm noticing a weird little artifact namely that I get left over fragments of a surface i redraw on to screen where the mouse cursor moves. It appears as if my code is interacting with whatever controls cursor redraw. I notice that this only happens when i go to fullscreen mode and enable hardware draw (HWSURFACE (not using double buffer right now since not 'flipping display' but rather controling exactly what rectangles get redrawn). I need HWSURFACE to be on for performance. So seems like in HWSURFACE mode the mouse cursor is run differently and is interacting with my redraws (i.e. fails to let them complete well under it). Anyone familiar with this kind of mouse cursor issue in HWSURFACE mode? Thanks Lin .
Re: [pygame] Making a Breakpoint happen during a run via keyboard
Worked thanks! - Original Message - From: "Ulrich Petri" To: Sent: Sunday, February 22, 2009 3:07 PM Subject: Re: [pygame] Making a Breakpoint happen during a run via keyboard Hi, since your post is spectacularly scarce on details I'm not exactly sure what your environment is but I usually do something like so if I need interactive debugging: -- pseudo code main loop: if key == K_whatever: import pdb pdb.set_trace() # <- brakes here and gives pdb console HTH Ulrich Am 22.02.2009 um 23:28 schrieb Lin Parkh: I know this question is vaguely structured but would love insight if anyone can manage it. I am trying to give myself an interactive debugger during the running of my game. That is, while game is in execution I hit a keystroke which leads to a breakpoint being reached and execution stops but program does not terminate. Then I ask the console various questions about game state etc. I used to have this running! But somehow I have done something to my environment such that while when I hit the keystroke the excution of code goes to the breakpoint line but fails to stop :- ( This is of course while I am running in debug mode (using F11). Breakpoints in other places in code continue to run. I have of course tried doing new breakpoints, getting rid of old etc. Two questions: 1) fixing -- any idea what I could have done that would make pygame/ pydev ignore the breakpoint but not ignore breakpoints prior to the program going into active event management 'running' mode? I'm thinking somehow maybe the event queue or some otherquality of pygame forces execution to continue past breakpoint. But this didn't used to be an issue... 2) alternative -- is there a more clever way to go into a debug mode while a game is active? say maybe have a pseudo console that responds to queries (like asking properties of a class instance while execution ongoing or halted). Or maybe a way to make program suspend on command in the code besides a breakpoint? Is there perhaps a breakpoint piece of code I could insert directly into the code? Instead of the due-hickky on the side tab in eclipse/pydev? I would really appreciate help here as my debuggin efficiency has suffered dramatically since I lost this interrupt and query ability. Thanks, Lin
Re: [pygame] Making a Breakpoint happen during a run via keyboard
Yes it was pretty vague :-) Thanks I will try your suggestion. Looks like the right kind of thing. - Original Message - From: "Ulrich Petri" To: Sent: Sunday, February 22, 2009 3:07 PM Subject: Re: [pygame] Making a Breakpoint happen during a run via keyboard Hi, since your post is spectacularly scarce on details I'm not exactly sure what your environment is but I usually do something like so if I need interactive debugging: -- pseudo code main loop: if key == K_whatever: import pdb pdb.set_trace() # <- brakes here and gives pdb console HTH Ulrich Am 22.02.2009 um 23:28 schrieb Lin Parkh: I know this question is vaguely structured but would love insight if anyone can manage it. I am trying to give myself an interactive debugger during the running of my game. That is, while game is in execution I hit a keystroke which leads to a breakpoint being reached and execution stops but program does not terminate. Then I ask the console various questions about game state etc. I used to have this running! But somehow I have done something to my environment such that while when I hit the keystroke the excution of code goes to the breakpoint line but fails to stop :- ( This is of course while I am running in debug mode (using F11). Breakpoints in other places in code continue to run. I have of course tried doing new breakpoints, getting rid of old etc. Two questions: 1) fixing -- any idea what I could have done that would make pygame/ pydev ignore the breakpoint but not ignore breakpoints prior to the program going into active event management 'running' mode? I'm thinking somehow maybe the event queue or some otherquality of pygame forces execution to continue past breakpoint. But this didn't used to be an issue... 2) alternative -- is there a more clever way to go into a debug mode while a game is active? say maybe have a pseudo console that responds to queries (like asking properties of a class instance while execution ongoing or halted). Or maybe a way to make program suspend on command in the code besides a breakpoint? Is there perhaps a breakpoint piece of code I could insert directly into the code? Instead of the due-hickky on the side tab in eclipse/pydev? I would really appreciate help here as my debuggin efficiency has suffered dramatically since I lost this interrupt and query ability. Thanks, Lin
[pygame] Making a Breakpoint happen during a run via keyboard
I know this question is vaguely structured but would love insight if anyone can manage it. I am trying to give myself an interactive debugger during the running of my game. That is, while game is in execution I hit a keystroke which leads to a breakpoint being reached and execution stops but program does not terminate. Then I ask the console various questions about game state etc. I used to have this running! But somehow I have done something to my environment such that while when I hit the keystroke the excution of code goes to the breakpoint line but fails to stop :-( This is of course while I am running in debug mode (using F11). Breakpoints in other places in code continue to run. I have of course tried doing new breakpoints, getting rid of old etc. Two questions: 1) fixing -- any idea what I could have done that would make pygame/pydev ignore the breakpoint but not ignore breakpoints prior to the program going into active event management 'running' mode? I'm thinking somehow maybe the event queue or some otherquality of pygame forces execution to continue past breakpoint. But this didn't used to be an issue... 2) alternative -- is there a more clever way to go into a debug mode while a game is active? say maybe have a pseudo console that responds to queries (like asking properties of a class instance while execution ongoing or halted). Or maybe a way to make program suspend on command in the code besides a breakpoint? Is there perhaps a breakpoint piece of code I could insert directly into the code? Instead of the due-hickky on the side tab in eclipse/pydev? I would really appreciate help here as my debuggin efficiency has suffered dramatically since I lost this interrupt and query ability. Thanks, Lin
Re: [pygame] Clock versus time tick checks
This looks quite interesting. Thanks for pointing that out. - Original Message - From: Jake b To: pygame-users@seul.org Sent: Saturday, January 10, 2009 7:53 PM Subject: Re: [pygame] Clock versus time tick checks This may interest you, it's a tutorial on de-coupling the game physics rate (fps) with display (video fps): http://gafferongames.wordpress.com/game-physics/fix-your-timestep/ -- Jake
[pygame] Clock versus time tick checks
Hi, I'm going to be introducing animation and want to ensure a steady frame rate. I see two approaches to this right now from reviewing examples. One is to use a Clock with a frame rate argument. This appears to simply do a delay any time there are spare milliseconds till the name frame update. The second approach which I see in piman's sprite example (http://kai.vm.bytemark.co.uk/~piman/writing/sprite-tutorial.shtml) seems instead to ask each sprite to look at a time stamp and based on that, update or not (i.e. every 10 milliseconds since last time updated show a new frame or location). The first has the appeal of using a pygame specific mechanism for frame rates (Clock) but the second seems like it does waste cycles. That is it seems like if I had things to do with spare cycle like do some AI I could use the time as opposed to having it absorbed by a Clock controlled frame rate. Leaving aside my perhaps erronious latter intuition, my question is this: what would you recommend as preferred way to control frame rate for animations...on whatever basis you would argue for :-) Thanks for your time, Lin p.s. For more context, I'm using sjbrown's Writing Games Tutorial where he generates tick events as fast as a loop can manage. These tickevents then spawn subevents like display updates. I'm thinking I either have these tick events simply communicate the absolute time in style of piman code or at each return to generate a new tickevent do a clock frame rate delay. Please let me know if any further advise or comments given I'm using that kind of Mediator architecture.
Re: [pygame] @
It is always possible to write game specific languages :-) Like AI languages. - Original Message - From: "Noah Kantrowitz" To: Sent: Wednesday, December 31, 2008 1:58 PM Subject: Re: [pygame] @ Python _is_ the scripting language to use in your game. --Noah On Dec 31, 2008, at 4:56 PM, Lin Parkh wrote: Thanks. The game context is I would like to write a scripting language on top of pygame/python for my game. - Original Message - From: "Lenard Lindstrom" To: Sent: Wednesday, December 31, 2008 1:32 PM Subject: Re: [pygame] @ This is getting off topic for a game oriented mailing list, but many of the things other languages use macro to accomplish come naturally to Python because it is dynamically typed. For instance the function: def do_add(x, y): return x + y will work with integers, floats, complex numbers, lists and any other class that defines an addition operation. Python has many hooks that take callback functions. These can redefine the way imports work, for instance. Also, metaclasses allow one to change how class declarations work. So though there is no mechanism to add new syntax and constructs to the Python language, there are plenty of ways to change how the existing syntax works. Lenard Noah Kantrowitz wrote: Python has no such system. Boo is a python-like language that supports hygienic macros. --Noah On Dec 31, 2008, at 1:20 PM, Lin Parkh wrote: While we're on this kind of topic what is the best approach in python to creating code macros? That is ability to write a higher level language (or script) which translates down into python? Decorators look like they would be part of that story. Is that the best way or is their a more general way? Thanks, Lin p.s. I used to write code macros in LISP... context I am coming from. - Original Message - From: "Michael George" > To: Sent: Wednesday, December 31, 2008 9:56 AM Subject: Re: [pygame] @ Michael Phipps wrote: Yanom - A decorator is a method that takes another method as a parameter so that it can do something. It is usually used for aspect oriented programming. For example: def logThisMethodCall(methodCall) # Do some logging here @logThisMethodCall def myMethod(a,b,c) # do Somthing in here Now, whenever you call "myMethod", logThisMethodCall gets called first, with the invocation of myMethod passed into it. You can use it for logging, security (i.e. does this person have permission to be calling this), etc. Michael This isn't quite right. logThisMethodCall doesn't get called when you call myMethod, but when you _define_ myMethod. So to fix this example: def logThisMethodCall(methodCall): def result(a,b,c): # do some logging here methodCall(a,b,c) return result @logThisMethodCall def myMethod(a,b,c): # do something here When you define myMethod, logThisMethodCall is called to create a replacement function for myMethod. it returns a new function "result" which gets called instead of the original myMethod whenever someone calls myMethod. result does some logging and then calls the orginal myMethod. -- Lenard Lindstrom
Re: [pygame] @
Thanks. The game context is I would like to write a scripting language on top of pygame/python for my game. - Original Message - From: "Lenard Lindstrom" To: Sent: Wednesday, December 31, 2008 1:32 PM Subject: Re: [pygame] @ This is getting off topic for a game oriented mailing list, but many of the things other languages use macro to accomplish come naturally to Python because it is dynamically typed. For instance the function: def do_add(x, y): return x + y will work with integers, floats, complex numbers, lists and any other class that defines an addition operation. Python has many hooks that take callback functions. These can redefine the way imports work, for instance. Also, metaclasses allow one to change how class declarations work. So though there is no mechanism to add new syntax and constructs to the Python language, there are plenty of ways to change how the existing syntax works. Lenard Noah Kantrowitz wrote: Python has no such system. Boo is a python-like language that supports hygienic macros. --Noah On Dec 31, 2008, at 1:20 PM, Lin Parkh wrote: While we're on this kind of topic what is the best approach in python to creating code macros? That is ability to write a higher level language (or script) which translates down into python? Decorators look like they would be part of that story. Is that the best way or is their a more general way? Thanks, Lin p.s. I used to write code macros in LISP... context I am coming from. - Original Message - From: "Michael George" To: Sent: Wednesday, December 31, 2008 9:56 AM Subject: Re: [pygame] @ Michael Phipps wrote: Yanom - A decorator is a method that takes another method as a parameter so that it can do something. It is usually used for aspect oriented programming. For example: def logThisMethodCall(methodCall) # Do some logging here @logThisMethodCall def myMethod(a,b,c) # do Somthing in here Now, whenever you call "myMethod", logThisMethodCall gets called first, with the invocation of myMethod passed into it. You can use it for logging, security (i.e. does this person have permission to be calling this), etc. Michael This isn't quite right. logThisMethodCall doesn't get called when you call myMethod, but when you _define_ myMethod. So to fix this example: def logThisMethodCall(methodCall): def result(a,b,c): # do some logging here methodCall(a,b,c) return result @logThisMethodCall def myMethod(a,b,c): # do something here When you define myMethod, logThisMethodCall is called to create a replacement function for myMethod. it returns a new function "result" which gets called instead of the original myMethod whenever someone calls myMethod. result does some logging and then calls the orginal myMethod. -- Lenard Lindstrom
Re: [pygame] @
While we're on this kind of topic what is the best approach in python to creating code macros? That is ability to write a higher level language (or script) which translates down into python? Decorators look like they would be part of that story. Is that the best way or is their a more general way? Thanks, Lin p.s. I used to write code macros in LISP... context I am coming from. - Original Message - From: "Michael George" To: Sent: Wednesday, December 31, 2008 9:56 AM Subject: Re: [pygame] @ Michael Phipps wrote: Yanom - A decorator is a method that takes another method as a parameter so that it can do something. It is usually used for aspect oriented programming. For example: def logThisMethodCall(methodCall) # Do some logging here @logThisMethodCall def myMethod(a,b,c) # do Somthing in here Now, whenever you call "myMethod", logThisMethodCall gets called first, with the invocation of myMethod passed into it. You can use it for logging, security (i.e. does this person have permission to be calling this), etc. Michael This isn't quite right. logThisMethodCall doesn't get called when you call myMethod, but when you _define_ myMethod. So to fix this example: def logThisMethodCall(methodCall): def result(a,b,c): # do some logging here methodCall(a,b,c) return result @logThisMethodCall def myMethod(a,b,c): # do something here When you define myMethod, logThisMethodCall is called to create a replacement function for myMethod. it returns a new function "result" which gets called instead of the original myMethod whenever someone calls myMethod. result does some logging and then calls the orginal myMethod. --Mike
Re: [pygame] Controlling Display Location on screen
Thanks. Would not have figured this one out easily :-)
- Original Message -
From: "Kris Schnee"
To:
Sent: Thursday, December 18, 2008 7:50 AM
Subject: Re: [pygame] Controlling Display Location on screen
On Thu, 18 Dec 2008 07:44:21 -0800, "Lin Parkh"
wrote:
Is it possible to set where on the monitor the display will appear? For
example I would like the pygame display to appear on a second monitor I
have. I see how to control resolution and size but not this. I am using
windows btw,
There was a command to center the SDL window, but in a recent version of
Pygame this command just didn't work. The window would appear in a random
place, often hanging over the screen's edge so that the program couldn't
be
properly used until the window is moved. I'm not sure whether the
problem's
been fixed yet.
I think you need to "import os" and then set an environment flag
("os.setenv"?), and that the flag is "SDL_VIDEO_CENTER", in quotes.
[pygame] Controlling Display Location on screen
Is it possible to set where on the monitor the display will appear? For example I would like the pygame display to appear on a second monitor I have. I see how to control resolution and size but not this. I am using windows btw, Thanks, Lin
Re: [pygame] Fw: rect.center.. confusion over result.. or bad result?
thanks for putting up with my denseness and replying :-) - Original Message - From: "René Dudfield" <[EMAIL PROTECTED]> To: Sent: Thursday, December 04, 2008 4:49 PM Subject: Re: [pygame] Fw: rect.center.. confusion over result.. or bad result? hi, (85 / 2.) + 44 86.5 It divides the height by two, and then adjusts it by the y coordinate. cu. On Fri, Dec 5, 2008 at 11:44 AM, Lin Parkh <[EMAIL PROTECTED]> wrote: I think I am confused about what center of a rectangle is becaue I am getting an "odd" (to me) result. Specifically: #I define a rectangle: tes =pygame.Rect(0,44,200,85) #now i would expect the center of this rectangle to be be ((200+0)/2),(44+85)/2)) in other words (100, 64) instead I get: tes.center (100, 86) Where did the 86 come from Please advise. Thanks for any help!
[pygame] Fw: rect.center.. confusion over result.. or bad result?
I think I am confused about what center of a rectangle is becaue I am getting an "odd" (to me) result. Specifically: #I define a rectangle: tes =pygame.Rect(0,44,200,85) #now i would expect the center of this rectangle to be be ((200+0)/2),(44+85)/2)) in other words (100, 64) instead I get: tes.center (100, 86) Where did the 86 come from Please advise. Thanks for any help!
