Re: [pygame] Faster blitting
etting lower to SDL >>>>> blitting. I get >>>>> your message, I am absolutely clear that python is generally the >>>>> bottleneck. If >>>>> you can find a way to isolate and test the following parts of the C >>>>> extension >>>>> library, I would be happy to see the results. >>>>> >>>>> >>>>> https://bitbucket.org/pygame/pygame/src/d61ea8eabd56025fcb4ceb24d63f9a6a30fbe8d4/src/surface.c?at=default&fileviewer=file-view-default#surface.c-2988:3114 >>>>> >>>>> >>>>> >>>>> On Mon, Mar 14, 2016 at 12:06 PM, Peter Finlayson < >>>>> frnkn...@iafrica.com >>>>> <mailto:frnkn...@iafrica.com>> wrote: >>>>> >>>>> On 2016/03/14 04:35 PM, herve wrote: >>>>> >>>>> before being a skilled pygame developer, there is a newby >>>>> developer and >>>>> _maybe_ >>>>> giving him good performance for simple things will let him >>>>> stay and >>>>> growing to >>>>> skilled developer. >>>>> >>>>> >>>>> A newbie developer seeing a "faster" unchecked function, trying to >>>>> use it, >>>>> and then getting discouraged when it inevitably fails... That is >>>>> exactly why >>>>> unsafe_blit() is a bad fit for Pygame. >>>>> >>>>> If you want a quick benchmark to show you are barking up the wrong >>>>> tree, you >>>>> can do one at home, with no C experience needed! Take some game >>>>> code you >>>>> wrote, and run it three ways: >>>>> >>>>> 1. Once unaltered >>>>> 2. Once where you run the sprite update code twice (logic, >>>>> movement and physics) >>>>> 3. Once where you draw every sprite twice >>>>> >>>>> Record the FPS every time and see if that shows you where the real >>>>> bottleneck lies. Here are the results I got from one of my >>>>> projects: >>>>> >>>>> 1. Base:125 FPS >>>>> 2. Double logic: 75 FPS >>>>> 3. Double draw: 115 FPS >>>>> >>>>> I had to take the game all the way up to 6x draw calls per frame >>>>> (4000+ >>>>> blits!) before I got it down to the 75 FPS mark. >>>>> >>>>> The point here is that if I was writing a game to have even double >>>>> the >>>>> sprites I do now, the game logic overhead would be the problem. >>>>> Even if the >>>>> unsafe_blit() magically doubled the speed of my draw routines, it >>>>> would have >>>>> little effect on my overall frame rate. >>>>> >>>>> Regards, >>>>> Peter Finlayson >>>>> >>>>> >>>>> >>>> >>> >>> >> > -- Jeffrey Kleykamp
Re: [pygame] circular movement in pygame
It might be a rounding issue. rect.x is always the nearest integer I think. It's better to store position as a float and then only round when drawing. On Tue, Apr 28, 2015 at 4:28 PM, Charles Cossé wrote: > Well I just spent 15 minutes looking at your code ... nothing obvious > jumps out, except inconsistent use of variables and representations. Let > me ask: Can you write a simple pygame program that makes a sprite move in a > circle, yourself, right now? > > On Tue, Apr 28, 2015 at 11:10 AM, Charles Cossé wrote: > >> Hi, >> >> Typically x=r*cos(angle) and y=r*sin(angle) ... you've got the opposite. >> >> You'd have to post more code for anyone to help with you in/out of class >> problem ... >> >> Charles >> >> On Tue, Apr 28, 2015 at 6:52 AM, diliup gabadamudalige > > wrote: >> >>> Looking at the code on this page lines 47 & 48 >>> >>> >>> http://programarcadegames.com/python_examples/show_file.php?file=sprite_circle_movement.py >>> >>> is there a way to do >>> self.rect.x +*= some value* >>> self.rect.y += some value >>> >>> rather than >>> >>> self.rect.x = self.radius * math.sin(self.angle) + self.center_x >>> self.rect.y = self.radius * math.cos(self.angle) + self.center_y >>> >>> ? >>> >>> I tired it in the code attached and strangely it works ok but only >>> OUTSIDE THE class. When I implement the exact code in a class it does >>> something weird. I can't find where I have gone wrong. >>> >>> Please help. >>> >>> Many thanks in advance. >>> >>> Diliup Gabadamudalige >>> >>> >>> >>> ** >>> This e-mail is confidential. It may also be legally privileged. If you >>> are not the intended recipient or have received it in error, please delete >>> it and all copies from your system and notify the sender immediately by >>> return e-mail. Any unauthorized reading, reproducing, printing or further >>> dissemination of this e-mail or its contents is strictly prohibited and may >>> be unlawful. Internet communications cannot be guaranteed to be timely, >>> secure, error or virus-free. The sender does not accept liability for any >>> errors or omissions. >>> >>> ** >>> >>> >> > -- Jeffrey Kleykamp
Re: [pygame] Potential Malware in Pygame 1.9.2a0.win32-py3.2
I'm pretty sure it was a false positive. On Wed, Sep 3, 2014 at 10:28 AM, Thomas Kluyver wrote: > Hi, > > It seems very likely that it was a false positive. Nobody else reported > that issue, and I scanned the same file on virustotal, which checks with > lots of different scanners, and none of them found anything. It's > impossible to be 100% certain without understanding exactly what was going > on on Jeffrey's computer, but I wouldn't worry about using it. > > Of course, on windows it's a good idea to have an up to date virus scanner > installed anyway, as a general precaution. > > Thomas > On 3 Sep 2014 03:56, "Little Bird" > wrote: > >> Jeffrey Kleykamp wrote >> > I just downloaded and installed >> > pygame-1.9.2a0.win32-py3.2.msi >> > and my webroot secure anywhere caught some malware in it. I have no idea >> > if >> > this is real or what. Here's the log, >> > >> > >> > Automated Cleanup Engine >> > Starting Cleanup at 29/06/2014 - 21:35:57 GMT >> > >> > Starting Routine> Removing >> > c:\python32\lib\site-packages\pygame\fastevent.pyd...#(PX5: >> > 5958229000E66EC43402003B3C2E0700DECDFB7E - MD5: >> > CB274A3F1A83260D82957409855CA077)... >> > Deleting File> c:\python32\lib\site-packages\pygame\fastevent.pyd >> > >> > Automated Cleanup Engine >> > Starting Cleanup at 29/06/2014 - 21:36:05 GMT >> > >> > Starting Routine> Removing >> > c:\python32\lib\site-packages\pygame\rwobject.pyd...#(PX5: >> > 9715EE78004EFB243081002B48A504004E3053AE - MD5: >> > 2C5778D0816BEBA8ECC7D1FE11B23384)... >> > Deleting File> c:\python32\lib\site-packages\pygame\rwobject.pyd >> > >> > Automated Cleanup Engine >> > Starting Cleanup at 29/06/2014 - 21:36:13 GMT >> > >> > Starting Routine> Removing >> > c:\python32\lib\site-packages\pygame\surflock.pyd...#(PX5: >> > 84FADE1C0046001620F7009522A6E30019BD6E14 - MD5: >> > 685D26D6E4EF4ADE48436B92B9118669)... >> > Deleting File> c:\python32\lib\site-packages\pygame\surflock.pyd >> > >> > >> > -- >> > >> > Jeffrey Kleykamp >> >> Greetings. >> >> I believe that I may be using the exact version of Pygame that Jeffrey >> Kleykamp has encountered a potential virus in. >> >> Is there anyway to confirm that this was a false positive? Has anyone else >> encountered this problem? >> >> This has me really worried. T_T >> >> >> I'm new to using mailing lists, so I'm treating it like a forum. If that >> is >> incorrect than please mention it as I do not wish to offend. >> >> >> Thank you for your time. >> ___ >> Little Bird >> >> >> >> >> -- >> View this message in context: >> http://pygame-users.25799.x6.nabble.com/pygame-Potential-Malware-in-Pygame-1-9-2a0-win32-py3-2-tp1315p1412.html >> Sent from the pygame-users mailing list archive at Nabble.com. >> > -- Jeffrey Kleykamp
Re: [pygame] Fwd: Missing Module and Font
I don't know anything about py2exe but does this website help? phttp://bytes.com/topic/python/answers/848048-py2exe-module-error On Thu, Jul 31, 2014 at 5:27 AM, diliup gabadamudalige wrote: > someone please help! > > > -- Forwarded message -- > From: diliup gabadamudalige > Date: Thu, Jul 31, 2014 at 1:33 AM > Subject: Missing Module and Font > To: pygame-users@seul.org > > > Dear Peter or anyone else who can help me, > > I downloaded > >- pygame-1.9.2a0.win32-py2.7.msi ><http://pygame.org/ftp/pygame-1.9.2a0.win32-py2.7.msi> 6.4MB > > from the Pygmaesite and everything runs smoothly. I can comile using > py2exe without any error. BUT I CANNOT import pygame.freetype. Gives me the > following error. > ImportError: No module named freetype > > Now when I download Pygame from the link below > https://bitbucket.org/pygame/pygame/downloads > > I can do import pygame.freetype but whn I compile the program using py2exe > I get an error > import pygame._view error. module not found. > > Please help as this is causing a LOT of preoblems and I am stuck between > the view module and the freefont. Kind of uncomfortable here so please help > me. > > Thank you very much in advance. > -- > Diliup Gabadamudalige > > http://www.diliupg.com > http://soft.diliupg.com/ > > > ** > This e-mail is confidential. It may also be legally privileged. If you are > not the intended recipient or have received it in error, please delete it > and all copies from your system and notify the sender immediately by return > e-mail. Any unauthorized reading, reproducing, printing or further > dissemination of this e-mail or its contents is strictly prohibited and may > be unlawful. Internet communications cannot be guaranteed to be timely, > secure, error or virus-free. The sender does not accept liability for any > errors or omissions. > > ** > > > > > -- > Diliup Gabadamudalige > > http://www.diliupg.com > http://soft.diliupg.com/ > > > ** > This e-mail is confidential. It may also be legally privileged. If you are > not the intended recipient or have received it in error, please delete it > and all copies from your system and notify the sender immediately by return > e-mail. Any unauthorized reading, reproducing, printing or further > dissemination of this e-mail or its contents is strictly prohibited and may > be unlawful. Internet communications cannot be guaranteed to be timely, > secure, error or virus-free. The sender does not accept liability for any > errors or omissions. > > ** > > -- Jeffrey Kleykamp
Re: [pygame] OpenGL stretch of a pygame.Surface
Well you might be able to scroll for some speedup. If everything is moving in the same general direction then scroll the biggest thing (like the background) and redraw everything else and the edges. On Tue, Jul 29, 2014 at 11:02 AM, sylvain.boussekey < sylvain.bousse...@vertpingouin.fr> wrote: > I have an asynchronous rendering function. > My game does logic updates at a fixed rate. > Rendering is done as fast as it can, possibly fps limited by a > pygame.time.Clock with interpolated position for sprites. > I'm actually drawing everything every frames because everthing is moving > constantly moving. > > On my not so fast computer, I acheive 400FPS, which is useless but a good > indicator to know how many sprites I can draw simultaneously. Pretty > confortable. > But if I want to go fullscreen in native resolution (to keep pixels art > pixelated !), I must resize and I drop below 60FPS. > > But maybe I don't need 60FPS in the first place... > > Le 2014-07-29 15:28, Jeffrey Kleykamp a écrit : > >> I still dont understand what you are doing in the first place. Are you >> >> taking a bunch of frames of art and running them as a movie? Do you >> really have 60 frames of art per second? If not, then theres no reason >> >> to redraw everything each frame. Only redraw when something changes. >> Or, redraw only the part of the screen that changes. At least, as a >> rule, only transform an image ONCE. If you transform the same image >> more than once then youre wasting resources! Its much faster to save >> >> the transformed image and blit it onto the screen each time you use >> it. Its even faster to not redraw the screen if nothing changed. >> >> I understand that each frame youre trying to draw is 640x480 and then >> you want to upscale that to your screens resolution. How many frames >> >> in total are you trying to draw over how much time?? If the answer >> isnt 60 frames over 1 second then theres no reason to redo your >> >> transform and blit each frame! >> >> Are they looping? If they are then save the transformed image for the >> next loop. >> >> I hope that helps, >> >> Jeffrey >> >> On Tue, Jul 29, 2014 at 8:38 AM, sylvain.boussekey >> wrote: >> >> I tried that with almost no perf gain. >>> I managed to do it in opengl but perfs are poor... The only >>> advantage is >>> that there is almost no fps differences when increasing resolution. >>> But >>> still framerate is poor. Here is roughly what I do (without knowing >>> what I >>> do really)e : >>> >>> def openglblit(self, surf): >>> textureSurface = surf >>> >>> textureData = pygame.image.tostring(textureSurface, >>> "RGBA", 1) >>> >>> width = textureSurface.get_width() >>> height = textureSurface.get_height() >>> >>> texture = glGenTextures(1) >>> glBindTexture(GL_TEXTURE_2D, texture) >>> glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, >>> GL_NEAREST) >>> glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, >>> GL_NEAREST) >>> glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, >>> 0, GL_RGBA, >>> GL_UNSIGNED_BYTE, textureData) >>> >>> glClear(GL_COLOR_BUFFER_BIT) >>> >>> glBindTexture(GL_TEXTURE_2D, texture) >>> glBegin(GL_QUADS) >>> glTexCoord2d(0,1) >>> glVertex2d(-1,1) >>> glTexCoord2d(0,0) >>> glVertex2d(-1,-1) >>> glTexCoord2d(1,0) >>> glVertex2d(1,-1) >>> glTexCoord2d(1,1) >>> glVertex2d(1,1) >>> >>> glEnd() >>> glFlush() >>> >>> glDeleteTextures(texture) >>> >>> But it seems that the conversion between pygame surface and opengl >>> tex is >>> slow. >>> Argh !! I will really need to go full opengl if I want better >>> perfs... sad... >>> >>> Le 2014-07-28 23:14, Noel Garwick a écrit : >>> >>> vertpingouin, >>>> >>>> If you are doing that every frame as part of the sprites .draw or >>>> .update method , its still possible the transform is what is >>>> taking up >>>> >>>> CPU time. You may want to use something like this instead: >>>> >>>> class MySpriteThing( pygame.sprite.Sprite): >>>>
Re: [pygame] OpenGL stretch of a pygame.Surface
> self.screen) >>> >>> where native is the little one and screen the big one. I assume >>> that >>> self.native is scaled then blit onto self.screen... >>> >>> I think this is the blitting that is slow because if I use a lesser >>> resolution for self.screen, I almost get back my precious frames >>> per >>> second. >>> >>> It will be really cool to send my little native surface to my >>> graphic >>> card, then let it scale by itself. Dont know if its even possible. >>> >>> >>> Le lundi 28 juillet 2014 à 11:50 -0400, Noel Garwick a écrit : >>> >>> Right now you are blitting tiles to a 640x480 surface, and then >>>> >>> > performing a transform on the whole surface and then blitting it >>> to >>> > the display? >>> > >>> > >>> > If this is the case, then try to only perform the scale operation >>> when >>> > the resolution is changed (instead of once each frame) and see >>> how >>> > that works. I know you mentioned that the full screen blit >>> operation >>> > seems to be the main bottleneck, but this should help too. >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > On Mon, Jul 28, 2014 at 7:32 AM, Sam Bull >> [1]> >>> >>> > wrote: >>> > On lun, 2014-07-28 at 06:54 +0200, VertPingouin >>> wrote: >>> > > So I came up with the idea of an hardware opengl >>> texture >>> > stretching >>> > > instead of a dumb blit but I dont know how to >>> >>> achieve it. >>> > > >>> > > Anyone has already done this ? >>> > > >>> > >>> > >>> > You would just need to code the graphics in OpenGL >>> without >>> > using >>> > pygame.Surface and pygame.draw. First though, check >>> you are >>> > using the >>> > HWSURFACE flag, if you are running fullscreen, its >>> >>> possible >>> > this might >>> > provide the necessary speedup without going to >>> OpenGL. >>> > >>> > >>> http://www.pygame.org/docs/ref/display.html#pygame.display.set_mode >>> [2] >>> > >>> > >>> >> >> >> >> Links: >> -- >> [1] mailto:sam.hack...@sent.com >> [2] http://www.pygame.org/docs/ref/display.html#pygame.display.set_mode >> [3] mailto:sylvain.bousse...@vertpingouin.fr >> > > -- Jeffrey Kleykamp
Re: [pygame] Potential Malware in Pygame 1.9.2a0.win32-py3.2
That could be but this computer is only a month old. I think this may just be a false positive... On Mon, Jun 30, 2014 at 1:26 PM, Thomas Kluyver wrote: > I extracted fastevent.pyd, the first file you saw a problem with (md5 > cb274a3f1a83260d82957409855ca077), and checked it with virustotal. Still > nothing: > > https://www.virustotal.com/en-gb/file/30d7c47d4385ff2b16b23544c4525e6699dddcaa7c3ddf3c66f302f78e78c333/analysis/1404149051/ > > Another possibility is that you have a virus elsewhere on the system which > is infecting those files as they get installed. > > Thomas > > > On 30 June 2014 10:01, Jeffrey Kleykamp > wrote: > >> The file itself doesn't trip any alarms for me either. After installing >> and doing 'import pygame' I get the warning. The md5sum is the same for my >> file. >> >> Jeffrey >> >> >> On Mon, Jun 30, 2014 at 12:53 PM, Thomas Kluyver >> wrote: >> >>> Did you download this from the pygame website? I've just downloaded that >>> same file and checked it with virustotal (which scans with a load of >>> different AV engines), and it was all clear: >>> >>> https://www.virustotal.com/en-gb/file/18d88fb656e1868e0949e0189d1a2b03d697bd9d9a539cc7131089b4284157bf/analysis/1404146796/ >>> >>> So I'd suspect it's a false positive, although it's possible that >>> someone is doing a MITM attack to give you a modified download. Check the >>> md5sum of the file you downloaded - it should be: >>> 71e8d3d1679a9d803302ff2923406def >>> >>> Thomas >>> >>> >>> On 30 June 2014 07:44, Jeffrey Kleykamp >>> wrote: >>> >>>> It also said it was Win32 Malware Gen. >>>> >>>> http://www.ehow.com/info_12106213_win32-malwaregen.html >>>> >>>> Who made the msi? >>>> >>>> >>>> On Mon, Jun 30, 2014 at 1:49 AM, diliup gabadamudalige < >>>> dili...@gmail.com> wrote: >>>> >>>>> this could be potentially dangerous! does anyone else have more info? >>>>> i am using this version. >>>>> >>>>> >>>>> On Mon, Jun 30, 2014 at 3:13 AM, Jeffrey Kleykamp < >>>>> jeffrey.kleyk...@gmail.com> wrote: >>>>> >>>>>> I just downloaded and installed >>>>>> pygame-1.9.2a0.win32-py3.2.msi >>>>>> and my webroot secure anywhere caught some malware in it. I have no >>>>>> idea if this is real or what. Here's the log, >>>>>> >>>>>> >>>>>> Automated Cleanup Engine >>>>>> Starting Cleanup at 29/06/2014 - 21:35:57 GMT >>>>>> >>>>>> Starting Routine> Removing >>>>>> c:\python32\lib\site-packages\pygame\fastevent.pyd...#(PX5: >>>>>> 5958229000E66EC43402003B3C2E0700DECDFB7E - MD5: >>>>>> CB274A3F1A83260D82957409855CA077)... >>>>>> Deleting File> c:\python32\lib\site-packages\pygame\fastevent.pyd >>>>>> >>>>>> Automated Cleanup Engine >>>>>> Starting Cleanup at 29/06/2014 - 21:36:05 GMT >>>>>> >>>>>> Starting Routine> Removing >>>>>> c:\python32\lib\site-packages\pygame\rwobject.pyd...#(PX5: >>>>>> 9715EE78004EFB243081002B48A504004E3053AE - MD5: >>>>>> 2C5778D0816BEBA8ECC7D1FE11B23384)... >>>>>> Deleting File> c:\python32\lib\site-packages\pygame\rwobject.pyd >>>>>> >>>>>> Automated Cleanup Engine >>>>>> Starting Cleanup at 29/06/2014 - 21:36:13 GMT >>>>>> >>>>>> Starting Routine> Removing >>>>>> c:\python32\lib\site-packages\pygame\surflock.pyd...#(PX5: >>>>>> 84FADE1C0046001620F7009522A6E30019BD6E14 - MD5: >>>>>> 685D26D6E4EF4ADE48436B92B9118669)... >>>>>> Deleting File> c:\python32\lib\site-packages\pygame\surflock.pyd >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Jeffrey Kleykamp >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Diliup Gabadamudalige >>>>> >>>>> http://www.diliupg.com >>>>> http://soft.diliupg.com/ >>>>> >>>>> >>>>> ** >>>>> This e-mail is confidential. It may also be legally privileged. If you >>>>> are not the intended recipient or have received it in error, please delete >>>>> it and all copies from your system and notify the sender immediately by >>>>> return e-mail. Any unauthorized reading, reproducing, printing or further >>>>> dissemination of this e-mail or its contents is strictly prohibited and >>>>> may >>>>> be unlawful. Internet communications cannot be guaranteed to be timely, >>>>> secure, error or virus-free. The sender does not accept liability for any >>>>> errors or omissions. >>>>> >>>>> ** >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> Jeffrey Kleykamp >>>> >>> >>> >> >> >> -- >> >> Jeffrey Kleykamp >> > > -- Jeffrey Kleykamp
Re: [pygame] Potential Malware in Pygame 1.9.2a0.win32-py3.2
The file itself doesn't trip any alarms for me either. After installing and doing 'import pygame' I get the warning. The md5sum is the same for my file. Jeffrey On Mon, Jun 30, 2014 at 12:53 PM, Thomas Kluyver wrote: > Did you download this from the pygame website? I've just downloaded that > same file and checked it with virustotal (which scans with a load of > different AV engines), and it was all clear: > > https://www.virustotal.com/en-gb/file/18d88fb656e1868e0949e0189d1a2b03d697bd9d9a539cc7131089b4284157bf/analysis/1404146796/ > > So I'd suspect it's a false positive, although it's possible that someone > is doing a MITM attack to give you a modified download. Check the md5sum of > the file you downloaded - it should be: > 71e8d3d1679a9d803302ff2923406def > > Thomas > > > On 30 June 2014 07:44, Jeffrey Kleykamp > wrote: > >> It also said it was Win32 Malware Gen. >> >> http://www.ehow.com/info_12106213_win32-malwaregen.html >> >> Who made the msi? >> >> >> On Mon, Jun 30, 2014 at 1:49 AM, diliup gabadamudalige > > wrote: >> >>> this could be potentially dangerous! does anyone else have more info? i >>> am using this version. >>> >>> >>> On Mon, Jun 30, 2014 at 3:13 AM, Jeffrey Kleykamp < >>> jeffrey.kleyk...@gmail.com> wrote: >>> >>>> I just downloaded and installed >>>> pygame-1.9.2a0.win32-py3.2.msi >>>> and my webroot secure anywhere caught some malware in it. I have no >>>> idea if this is real or what. Here's the log, >>>> >>>> >>>> Automated Cleanup Engine >>>> Starting Cleanup at 29/06/2014 - 21:35:57 GMT >>>> >>>> Starting Routine> Removing >>>> c:\python32\lib\site-packages\pygame\fastevent.pyd...#(PX5: >>>> 5958229000E66EC43402003B3C2E0700DECDFB7E - MD5: >>>> CB274A3F1A83260D82957409855CA077)... >>>> Deleting File> c:\python32\lib\site-packages\pygame\fastevent.pyd >>>> >>>> Automated Cleanup Engine >>>> Starting Cleanup at 29/06/2014 - 21:36:05 GMT >>>> >>>> Starting Routine> Removing >>>> c:\python32\lib\site-packages\pygame\rwobject.pyd...#(PX5: >>>> 9715EE78004EFB243081002B48A504004E3053AE - MD5: >>>> 2C5778D0816BEBA8ECC7D1FE11B23384)... >>>> Deleting File> c:\python32\lib\site-packages\pygame\rwobject.pyd >>>> >>>> Automated Cleanup Engine >>>> Starting Cleanup at 29/06/2014 - 21:36:13 GMT >>>> >>>> Starting Routine> Removing >>>> c:\python32\lib\site-packages\pygame\surflock.pyd...#(PX5: >>>> 84FADE1C0046001620F7009522A6E30019BD6E14 - MD5: >>>> 685D26D6E4EF4ADE48436B92B9118669)... >>>> Deleting File> c:\python32\lib\site-packages\pygame\surflock.pyd >>>> >>>> >>>> -- >>>> >>>> Jeffrey Kleykamp >>>> >>> >>> >>> >>> -- >>> Diliup Gabadamudalige >>> >>> http://www.diliupg.com >>> http://soft.diliupg.com/ >>> >>> >>> ********** >>> This e-mail is confidential. It may also be legally privileged. If you >>> are not the intended recipient or have received it in error, please delete >>> it and all copies from your system and notify the sender immediately by >>> return e-mail. Any unauthorized reading, reproducing, printing or further >>> dissemination of this e-mail or its contents is strictly prohibited and may >>> be unlawful. Internet communications cannot be guaranteed to be timely, >>> secure, error or virus-free. The sender does not accept liability for any >>> errors or omissions. >>> >>> ** >>> >>> >> >> >> -- >> >> Jeffrey Kleykamp >> > > -- Jeffrey Kleykamp
Re: [pygame] Potential Malware in Pygame 1.9.2a0.win32-py3.2
It also said it was Win32 Malware Gen. http://www.ehow.com/info_12106213_win32-malwaregen.html Who made the msi? On Mon, Jun 30, 2014 at 1:49 AM, diliup gabadamudalige wrote: > this could be potentially dangerous! does anyone else have more info? i am > using this version. > > > On Mon, Jun 30, 2014 at 3:13 AM, Jeffrey Kleykamp < > jeffrey.kleyk...@gmail.com> wrote: > >> I just downloaded and installed >> pygame-1.9.2a0.win32-py3.2.msi >> and my webroot secure anywhere caught some malware in it. I have no idea >> if this is real or what. Here's the log, >> >> >> Automated Cleanup Engine >> Starting Cleanup at 29/06/2014 - 21:35:57 GMT >> >> Starting Routine> Removing >> c:\python32\lib\site-packages\pygame\fastevent.pyd...#(PX5: >> 5958229000E66EC43402003B3C2E0700DECDFB7E - MD5: >> CB274A3F1A83260D82957409855CA077)... >> Deleting File> c:\python32\lib\site-packages\pygame\fastevent.pyd >> >> Automated Cleanup Engine >> Starting Cleanup at 29/06/2014 - 21:36:05 GMT >> >> Starting Routine> Removing >> c:\python32\lib\site-packages\pygame\rwobject.pyd...#(PX5: >> 9715EE78004EFB243081002B48A504004E3053AE - MD5: >> 2C5778D0816BEBA8ECC7D1FE11B23384)... >> Deleting File> c:\python32\lib\site-packages\pygame\rwobject.pyd >> >> Automated Cleanup Engine >> Starting Cleanup at 29/06/2014 - 21:36:13 GMT >> >> Starting Routine> Removing >> c:\python32\lib\site-packages\pygame\surflock.pyd...#(PX5: >> 84FADE1C0046001620F7009522A6E30019BD6E14 - MD5: >> 685D26D6E4EF4ADE48436B92B9118669)... >> Deleting File> c:\python32\lib\site-packages\pygame\surflock.pyd >> >> >> -- >> >> Jeffrey Kleykamp >> > > > > -- > Diliup Gabadamudalige > > http://www.diliupg.com > http://soft.diliupg.com/ > > > ** > This e-mail is confidential. It may also be legally privileged. If you are > not the intended recipient or have received it in error, please delete it > and all copies from your system and notify the sender immediately by return > e-mail. Any unauthorized reading, reproducing, printing or further > dissemination of this e-mail or its contents is strictly prohibited and may > be unlawful. Internet communications cannot be guaranteed to be timely, > secure, error or virus-free. The sender does not accept liability for any > errors or omissions. > > ** > > -- Jeffrey Kleykamp
[pygame] Potential Malware in Pygame 1.9.2a0.win32-py3.2
I just downloaded and installed pygame-1.9.2a0.win32-py3.2.msi and my webroot secure anywhere caught some malware in it. I have no idea if this is real or what. Here's the log, Automated Cleanup Engine Starting Cleanup at 29/06/2014 - 21:35:57 GMT Starting Routine> Removing c:\python32\lib\site-packages\pygame\fastevent.pyd...#(PX5: 5958229000E66EC43402003B3C2E0700DECDFB7E - MD5: CB274A3F1A83260D82957409855CA077)... Deleting File> c:\python32\lib\site-packages\pygame\fastevent.pyd Automated Cleanup Engine Starting Cleanup at 29/06/2014 - 21:36:05 GMT Starting Routine> Removing c:\python32\lib\site-packages\pygame\rwobject.pyd...#(PX5: 9715EE78004EFB243081002B48A504004E3053AE - MD5: 2C5778D0816BEBA8ECC7D1FE11B23384)... Deleting File> c:\python32\lib\site-packages\pygame\rwobject.pyd Automated Cleanup Engine Starting Cleanup at 29/06/2014 - 21:36:13 GMT Starting Routine> Removing c:\python32\lib\site-packages\pygame\surflock.pyd...#(PX5: 84FADE1C0046001620F7009522A6E30019BD6E14 - MD5: 685D26D6E4EF4ADE48436B92B9118669)... Deleting File> c:\python32\lib\site-packages\pygame\surflock.pyd -- Jeffrey Kleykamp
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
That's just a caching issue. Cpython caches small numbers so that a and b
can be the same object. This works because whenever you change the number
you are reassigning the value as opposed to changing a value within the
object.
a = 10
b = 10
a is b # True
a = 100
a is b # False
print(a, b) # 100, 10
There's no way the python interpreter can get confused so, I guess, the
python programmers though they'd save a little memory that way.
On Mon, Jun 23, 2014 at 3:39 AM, diliup gabadamudalige
wrote:
> when you say a=100 and b=100 it is understood that a and b are both given
> TWO values and that both are the same is a coincidence.
> BUT if that is the case how can a is b be TRUE for small integers and a is
> b False for large integers? What logic is Python using here?
>
>
> On Mon, Jun 23, 2014 at 1:07 PM, diliup gabadamudalige
> wrote:
>
>> ok
>> look at this!
>> a = 100
>> b = 100
>> a == b
>> True
>> a is b
>> True
>> a = 1000
>> b = 1000
>> a is b
>> False
>> a == b
>> True
>>
>> what on earth is this? what is this logic?
>>
>>
>> On Mon, Jun 23, 2014 at 1:03 PM, Sam Bull wrote:
>>
>>> On lun, 2014-06-23 at 11:45 +0530, diliup gabadamudalige wrote:
>>> > I called event.clear() cause it says in the Pygame documentation that
>>> > if you leave unused events on the buffer that eventually it may fill
>>> > up and cause the program to crash.
>>>
>>> Yes, but if you are getting everything from the buffer using event.get()
>>> or whatever every frame, then it's not going to fill up, as these
>>> returned events are removed from the queue. As long as you are reading
>>> the whole buffer, say every 100ms, you're going to be fine. Otherwise,
>>> you're just throwing away the events that have arrived between the
>>> event.get() and event.clear() calls.
>>>
>>> >
>>> > if x is True:
>>> > is not correct
>>> >
>>> > if x == True
>>> > is correct?
>>>
>>> This obviously depends on what x is.
>>>
>>> So, if we write:
>>> "foo" is True
>>>
>>> We can clearly see these are not the same object. One is a string, and
>>> the other is the True object. But, if we do:
>>> "foo" == True
>>>
>>> Then, we are asking if the string evaluates to a True value, when
>>> treated as a boolean. And any non-empty string will be considered True,
>>> and so it is equal to True (but not the same object).
>>>
>>>
>>> Futhermore, what Greg was saying is that some objects can be of the same
>>> value and still not be the same object. Thus:
>>> a = 4040
>>> b = 4040
>>> a == b # True
>>> a is b # Could be False
>>>
>>> b = a # b now references the a object itself
>>> a is b # Always True
>>>
>>> This becomes more obvious if we were to use mutable types:
>>> a = [2]
>>> b = [2]
>>> # Obviously, these are two distinct objects
>>> a == b # True
>>> a is b # False
>>> # Changing one, would not change the other, as they are
>>> different
>>> # objects.
>>> a.append(3)
>>> a == b # False
>>>
>>>
>>> On an interesting sidenote, it is not even required that an object is
>>> equal to itself:
>>> a = float("NaN")
>>> a == a # False
>>>
>>
>>
>>
>> --
>> Diliup Gabadamudalige
>>
>> http://www.diliupg.com
>> http://soft.diliupg.com/
>>
>>
>> **
>> This e-mail is confidential. It may also be legally privileged. If you
>> are not the intended recipient or have received it in error, please delete
>> it and all copies from your system and notify the sender immediately by
>> return e-mail. Any unauthorized reading, reproducing, printing or further
>> dissemination of this e-mail or its contents is strictly prohibited and may
>> be unlawful. Internet communications cannot be guaranteed to be timely,
>> secure, error or virus-free. The sender does not accept liability for any
>> errors or omissions.
>>
>> **********
>>
>>
>
>
> --
> Diliup Gabadamudalige
>
> http://www.diliupg.com
> http://soft.diliupg.com/
>
>
> **
> This e-mail is confidential. It may also be legally privileged. If you are
> not the intended recipient or have received it in error, please delete it
> and all copies from your system and notify the sender immediately by return
> e-mail. Any unauthorized reading, reproducing, printing or further
> dissemination of this e-mail or its contents is strictly prohibited and may
> be unlawful. Internet communications cannot be guaranteed to be timely,
> secure, error or virus-free. The sender does not accept liability for any
> errors or omissions.
>
> **
>
>
--
Jeffrey Kleykamp
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
You're confused about what the 'is' operator and the '==' are. They aren't the same thing. 'is' checks if two objects are the exact same objects. Whereas '==' checks if they are equal objects. Also I suggest using event.get() without specific types and ignoring event types that you don't care about. Or else you'll lose certain events you do care about when you use clear. Jeffrey On Mon, Jun 23, 2014 at 3:26 AM, diliup gabadamudalige wrote: > 6 is 2 * 3 > True > 666 is 2 * 333 > False > 60 is 10 * 6 > True > 666 == 2 * 333 > True > > above is the result of my check > This is really weird! > I thought computers were absolute logic and didn't work like humans. > Looks like the programmers have included their idiosyncrasies to the > programs! Else how could this be possible? > > > On Mon, Jun 23, 2014 at 11:55 AM, Greg Ewing > wrote: > >> diliup gabadamudalige wrote: >> >>> Can someone please explain why if event.type is KEYUP: >>> >>> is bad and >>> >>> if event.type == KEYUP: >>> >>> is correct? >>> >> >> The 'is' operator tests whether two expressions refer to >> the *same* object. It's possible for two different int >> objects to have the same value, in which case 'is' and >> '==' will give different results, e.g. >> >> >>> 666 == 2 * 333 >> True >> >>> 666 is 2 * 333 >> False >> >> You can be misled if you try this experiment with >> sufficiently small integers, however: >> >> >>> 6 is 2 * 3 >> True >> >> This happens because CPython keeps a cache of small >> integer objects and re-uses them. But that's strictly >> an implementation detail, and not something you >> should rely on. The only reliable way to tell whether >> two ints are equal is to use ==. >> >> -- >> Greg >> > > > > -- > Diliup Gabadamudalige > > http://www.diliupg.com > http://soft.diliupg.com/ > > > ** > This e-mail is confidential. It may also be legally privileged. If you are > not the intended recipient or have received it in error, please delete it > and all copies from your system and notify the sender immediately by return > e-mail. Any unauthorized reading, reproducing, printing or further > dissemination of this e-mail or its contents is strictly prohibited and may > be unlawful. Internet communications cannot be guaranteed to be timely, > secure, error or virus-free. The sender does not accept liability for any > errors or omissions. > > ** > > -- Jeffrey Kleykamp
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
Also unicode will give you caps if you type shift or caps lock. So if you hold 'b' then hold shift and let go of 'b' I suspect you'll replicate the issue. Although it looks like the "KEYUP" events don't have a unicode so that may also be it. It's better to use the key attribute which is independent of caps lock and shift. Jeffrey On Sun, Jun 22, 2014 at 8:36 PM, Jeffrey Kleykamp < jeffrey.kleyk...@gmail.com> wrote: > It may help to have less duplicate code. > > if event.type is KEYDOWN or KEYUP: > x = event.unicode > > if x in KEYLIST: > play_number = 100 if event.type == > KEYDOWN else 0 > key_select = True if event.type == > KEYDOWN else False > v.keyMIDInn = KEY_TO_MIDI_NN[x] + v.octave > player.note_on(v.keyMIDInn, play_number,1) # play the note > > for key in keyboard_full: > if v.keyMIDInn == key.midi_note_no: > key.key_select = key_select > > Also your code may run into issues if you change KEYLIST and/or > keyboard_full between frames. It may also be that you're losing the screen > and pressing getting the keyup event off screen where you may not get it. > You can check for the status of keys using the keyboard pygame module > independent of events. That'll give you the status of the key right now. > Also make sure you're completely using the event buffer. It may get full. > If you use event.get(type) then all the other types stay on the list. So > use pump to get rid of them. > > Jeffrey > > > > On Sun, Jun 22, 2014 at 3:43 AM, diliup gabadamudalige > wrote: > >> Dear Pygame experts/enthusiasts around the world, >> >> Having looked at some possible solutions on stackoverflow I optimized the >> code to this >> >> #--- play keyboard via computer keyboard >> --- >> >> if event.type is KEYDOWN: >> x = event.unicode >> >> if x in KEYLIST: >> v.keyMIDInn = KEY_TO_MIDI_NN[x] + v.octave >> player.note_on(v.keyMIDInn, 100,1) # play the note >> >> for key in keyboard_full: >> if v.keyMIDInn == key.midi_note_no: >> key.key_select = True >> >> if event.type is KEYUP: >> x = event.unicode >> >> if x in KEYLIST: >> v.keyMIDInn = KEY_TO_MIDI_NN[x] + v.octave >> player.note_off(v.keyMIDInn, 0,1) >> >> for key in keyboard_full: >> if v.keyMIDInn == key.midi_note_no: >> key.key_select = False >> >> Still, if I play the keyboard really fast there are stuck MIDI notes and >> stuck animations. >> What could be the reason? >> Any help is much appreciated. >> >> >> >> On Sun, Jun 22, 2014 at 12:59 PM, diliup gabadamudalige < >> dili...@gmail.com> wrote: >> >>> Below is my code >>> the indention is wrong here but in the program it is correct >>> >>> if event.type is KEYDOWN: >>> x = check_chr_key(event.key) if x in >>> KEYLIST: if x in KEY_TO_MIDI_NN: # if key in midi note dict v.keyMIDInn = >>> KEY_TO_MIDI_NN[x] + v.octave player.note_on(v.keyMIDInn, 100,1) # play the >>> note >>> for key in keyboard_full: if v.keyMIDInn == key.midi_note_no: >>> key.key_select = True if event.type is KEYUP: x = check_chr_key(event.key) >>> if x in KEYLIST: v.keyMIDInn = KEY_TO_MIDI_NN[x] + v.octave >>> player.note_off(v.keyMIDInn, 0,1) for key in keyboard_full: if v.keyMIDInn >>> == key.midi_note_no: key.key_select = False If I play the keyboard >>> leisurely this works fine. But If I play the keyboard really fast >>> sometimes the MIDI notes get stuck and so does the Animation ( the stuck >>> MIDI note shows the keyboard note as down) >>> I can't see anything wrong in the code. Is it that Pygame is not >>> scanning the keyboard fast enough? What is the work around to this? >>> >>> -- >>> Diliup Gabadamudalige >>> >>> http://www.diliupg.com >>> http://soft.diliupg.com/ >>> >>> >>> ** >>> This e-mail is confidential. It may also be legally privileged. If you >>> are not the intended recipient or have received it in error, please delete >>> it and all copies from your system and notify the sender immediately by >>> return e-mail. Any unauthorized reading, reproducing, printing or further >>> dissemination of this e-mail or its contents is strictly prohibi
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
It may help to have less duplicate code. if event.type is KEYDOWN or KEYUP: x = event.unicode if x in KEYLIST: play_number = 100 if event.type == KEYDOWN else 0 key_select = True if event.type == KEYDOWN else False v.keyMIDInn = KEY_TO_MIDI_NN[x] + v.octave player.note_on(v.keyMIDInn, play_number,1) # play the note for key in keyboard_full: if v.keyMIDInn == key.midi_note_no: key.key_select = key_select Also your code may run into issues if you change KEYLIST and/or keyboard_full between frames. It may also be that you're losing the screen and pressing getting the keyup event off screen where you may not get it. You can check for the status of keys using the keyboard pygame module independent of events. That'll give you the status of the key right now. Also make sure you're completely using the event buffer. It may get full. If you use event.get(type) then all the other types stay on the list. So use pump to get rid of them. Jeffrey On Sun, Jun 22, 2014 at 3:43 AM, diliup gabadamudalige wrote: > Dear Pygame experts/enthusiasts around the world, > > Having looked at some possible solutions on stackoverflow I optimized the > code to this > > #--- play keyboard via computer keyboard > --- > > if event.type is KEYDOWN: > x = event.unicode > > if x in KEYLIST: > v.keyMIDInn = KEY_TO_MIDI_NN[x] + v.octave > player.note_on(v.keyMIDInn, 100,1) # play the note > > for key in keyboard_full: > if v.keyMIDInn == key.midi_note_no: > key.key_select = True > > if event.type is KEYUP: > x = event.unicode > > if x in KEYLIST: > v.keyMIDInn = KEY_TO_MIDI_NN[x] + v.octave > player.note_off(v.keyMIDInn, 0,1) > > for key in keyboard_full: > if v.keyMIDInn == key.midi_note_no: > key.key_select = False > > Still, if I play the keyboard really fast there are stuck MIDI notes and > stuck animations. > What could be the reason? > Any help is much appreciated. > > > > On Sun, Jun 22, 2014 at 12:59 PM, diliup gabadamudalige > wrote: > >> Below is my code >> the indention is wrong here but in the program it is correct >> >> if event.type is KEYDOWN: >> x = check_chr_key(event.key) if x in >> KEYLIST: if x in KEY_TO_MIDI_NN: # if key in midi note dict v.keyMIDInn = >> KEY_TO_MIDI_NN[x] + v.octave player.note_on(v.keyMIDInn, 100,1) # play the >> note >> for key in keyboard_full: if v.keyMIDInn == key.midi_note_no: >> key.key_select = True if event.type is KEYUP: x = check_chr_key(event.key) >> if x in KEYLIST: v.keyMIDInn = KEY_TO_MIDI_NN[x] + v.octave >> player.note_off(v.keyMIDInn, 0,1) for key in keyboard_full: if v.keyMIDInn >> == key.midi_note_no: key.key_select = False If I play the keyboard >> leisurely this works fine. But If I play the keyboard really fast >> sometimes the MIDI notes get stuck and so does the Animation ( the stuck >> MIDI note shows the keyboard note as down) >> I can't see anything wrong in the code. Is it that Pygame is not scanning >> the keyboard fast enough? What is the work around to this? >> >> -- >> Diliup Gabadamudalige >> >> http://www.diliupg.com >> http://soft.diliupg.com/ >> >> >> ** >> This e-mail is confidential. It may also be legally privileged. If you >> are not the intended recipient or have received it in error, please delete >> it and all copies from your system and notify the sender immediately by >> return e-mail. Any unauthorized reading, reproducing, printing or further >> dissemination of this e-mail or its contents is strictly prohibited and may >> be unlawful. Internet communications cannot be guaranteed to be timely, >> secure, error or virus-free. The sender does not accept liability for any >> errors or omissions. >> >> ** >> >> > > > -- > Diliup Gabadamudalige > > http://www.diliupg.com > http://soft.diliupg.com/ > > > ** > This e-mail is confidential. It may also be legally privileged. If you are > not the intended recipient or have received it in error, please delete it > and all copies from your system and notify the sender immediately by return > e-mail. Any unauthorized reading, reproducing, printing or further > dissemination of this e-mail or its contents is strictly prohibited and may > be unlawful. Internet communications cannot be guaranteed to be timely, > secure, error or virus-free. The sender does not accept liability for any > errors or omissions. > > ** > > -- Jeffrey Kleykamp
Re: [SPAM: 10.100] Re: [pygame] Circle cut off at 60+fps, fixed by display.flip
One thing I noticed about your code is you're making your own rectangle.
The draw function returns a rect so you should pass that. It's useful
because the rect it returns is constrained by the screen so there's less to
update. Plus you don't have to make as many rects. But that doesn't fix
your problem.
Here's just a list of observations I made while experimenting.
I'm not sure what's causing this issue. It's weird because it goes in all
directions. It seems to be affected by the time it has to compute. Eg. if
you change fps down to 20 it goes away. And if you change it to 120 it gets
terrible. Also the amount of clipping is proportional to the speed at which
you move. More speed = more clipping.
I'm not sure why flipping or increasing the size of the rect fixes the
problem but it does. If you inflate your rect slightly it fixes it. But if
you increase speed too much then it comes back.
The final observation that I made is that's it's not possible to stop on a
clipped rect. This makes me think this is a vsync issue. I'm pretty sure
that pygame does not vsync unless it's in hardware accelerated fullscreen.
So maybe the reason that flipping and bigger rects stop the issue is
because they give the system a slight delay. I also managed to get two
circles to draw and the effect goes away entirely. This might also have to
do with a longer processing time.
Here's modified code that allows you to try to "catch" the clipping in
action (it's not observable). It also toggles from inflating to not if you
uncomment the right part. This doesn't have two circles.
import pygame
w,h=500,500
fps=40
pygame.init()
screen = pygame.display.set_mode([w, h])
color=pygame.Color("white")
clock=pygame.time.Clock()
radius=20
x,y=w/2,h
dx = 10
r = pygame.Rect((0,0), (radius*2, radius*2))
r.center = (x, y)
inflate = False
def get_bbox(x,y):
left = x - radius
top = y - radius
width = radius * 2
height = radius * 2
return pygame.Rect((left, top), (width, height))
while True:
old_r=r
y-=dx
if y < 100:
y = w
#fps -= 5
#dx += 1
fps = 0
#inflate = not inflate
if fps <= 0:
fps = 40
pygame.time.wait(500)
screen.fill(pygame.Color("black"),old_r)
r = pygame.draw.circle(screen, color, (x, h-y), radius, 0)
if inflate: r.inflate_ip(20,20)
pygame.display.update([r,old_r])
clock.tick(fps)
I'm really at a loss as to what this actually is,
Jeffrey
On Fri, Jun 13, 2014 at 7:41 PM, Greg Ewing
wrote:
> I just tried this on a Mac, and it works fine,
> no flickering or tearing.
>
> The only thing I can think of is that, on your system,
> display.update() is not waiting for vertical sync,
> whereas display.flip() is.
>
> The pygame docs aren't very clear about whether it's
> supposed to or not. They say that flip() does, and then
> just say that update() is an "optimised version" of
> flip().
>
> This suggest to me that it should, and it does seem
> to on my system, but maybe some implementations are
> different.
>
> Maybe you could try passing a single rect to update()
> that's the union of the old an new rects. While that
> won't eliminate all possibility of tearing, it may
> make it less likely.
>
> --
> Greg
>
>
--
Jeffrey Kleykamp
Re: [pygame] Scaling the hitbox/rect of a sprite
Oops, my code was wrong, it should be, my_collide_rect = lambda a, b: a.hitbox.colliderect(b.hitbox) You want to use the colliderect function of the Rect module to test if they collide. http://www.pygame.org/docs/ref/rect.html#pygame.Rect.colliderect Jeffrey On Fri, May 23, 2014 at 10:02 AM, Skorpio wrote: > Thanks for the help everybody, but it still doesn't work. > > I've tried these functions as collided values (as Jeffrey Kleykamp > suggested): > > pygame.sprite.collide_rect() takes only sprites as values and then uses > their rects. That means I can't use the sprite's scaled "hitbox" attribute, > otherwise I get this error: AttributeError: 'pygame.Rect' object has no > attribute 'rect' > And if I do sprite.rect = sprite.hitbox, the image gets blitted at the top > left corner again. > > pygame.Rect.colliderect() doesn't work. > > pygame.sprite.collide_rect_ratio() works as intended but causes a huge > performance drop, so it's not useable for me. I have quite a lot of sprites > on the screen (sometimes over 100). > > Christopher Night is right. It would be a lot easier for me, if Pygame > sprites had an additional (optional) hitbox rect. > > Maybe I should rewrite my collision detection passage and just use > pygame.Rect.colliderect() instead of pygame.sprite.spritecollide(). > > > > -- > View this message in context: > http://pygame-users.25799.x6.nabble.com/pygame-Scaling-the-hitbox-rect-of-a-sprite-tp1227p1237.html > Sent from the pygame-users mailing list archive at Nabble.com. > -- Jeffrey Kleykamp
Re: [pygame] Scaling the hitbox/rect of a sprite
Using spritecollide(sprite, group, dokill, collided = None) you can specify a collided function. They have one built in for a constant ratio pygame.sprite.collide_rect_ratio(). You can also specify your own function. If you do that you can specify a different variable of your sprite to be your collision rect. Eg. my_func = lambda left, right: pygame.sprite.collide_rect(left.scaled_rect, right.scaled_rect) spritecollide(sprite, group, dokill, collided = my_func) Jeff On Thu, May 22, 2014 at 9:08 AM, Skorpio wrote: > I don't blit the sprites at the rect/hitbox, Pygame does that. The sprites > are in a pygame.sprite.Group and when I call sprite_group.draw(screen) and > if the rects are scaled, their images get still blitted at the top left > corner of the rect. I'm using pygame.sprite.spritecollide() for the > collision detection. > > Is there a way to give a sprite a additional hitbox? > > > > -- > View this message in context: > http://pygame-users.25799.x6.nabble.com/pygame-Scaling-the-hitbox-rect-of-a-sprite-tp1227p1231.html > Sent from the pygame-users mailing list archive at Nabble.com. > -- Jeffrey Kleykamp
Re: [pygame] BUG: LayeredUpdate 'layer' vs '_layer'
Yeah I understand that. It's just the docs make it seem that the add function will add your sprite to whatever your sprite.layer attribute is if you don't specify a karg layer. But that's not true. If you then use change_layer you end up doing twice as much work since with 'add' and 'change_layer' it's doing a bisect search each time. The point I'm making is that yes, '_layer' is an internal variable but 'layer' is never used. If you initialize a sprite and you want it to be added correctly then you have to set '_layer' before adding. Yes, don't change the '_layer' attribute after adding. If we wanted to keep '_layer' strictly an internal variable then we need to add a bit that gets the 'layer' attribute as it says it will in the docs. Below it looks for a karg layer, '_layer' and then 'layer' before using the default. if layer is None: try: layer = sprite._layer except AttributeError: try: layer = sprite._layer = sprite.layer except AttributeError: layer = sprite._layer = self._default_layer elif hasattr(sprite, '_layer'): sprite._layer = layer I hope that clarifies my point. Jeffrey On Wed, Mar 19, 2014 at 3:48 PM, DR0ID wrote: > Am 19.03.2014 07:29, schrieb Jeffrey Kleykamp: > > Hi all, >> >> In pygame.sprite.LayeredUpdate.add documentation it says >> >> "If the sprite(s) have an attribute layer then that is used for the layer. >> If **kwargs contains 'layer' then the sprite(s) will be added to that >> argument (overriding the sprite layer attribute). If neither is passed >> then >> the sprite(s) will be added to the default layer." >> >> This implies it relies on sprite.layer. But by looking at the source I saw >> if you want to affect which layer your sprite will get added to, you have >> to set sprite._layer before calling add(). So the documentation and the >> code doesn't match. >> >> Not so much a bug; more of a clarification. >> >> Sincerely, >> Jeffrey >> >> > > Hi > > In my version of sprites.py it looks like the code beneath (it might be > outdated). The sprite._layer is an internal variable that should not be > used directly (sprite._layer is read only). > > If you want to change a layer of a sprite use 'change_layer(self, sprite, > new_layer)'. So 'layer' will be handled correctly from the kwargs. > > LayeredUpdates: > > def add_internal(self, sprite, layer=None): > """Do not use this method directly. > > It is used by the group to add a sprite internally. > > """ > self.spritedict[sprite] = Rect(0, 0, 0, 0) # add a old rect > > if layer is None: > try: > layer = sprite._layer > except AttributeError: > layer = sprite._layer = self._default_layer > elif hasattr(sprite, '_layer'): > sprite._layer = layer > > sprites = self._spritelist # speedup > sprites_layers = self._spritelayers > sprites_layers[sprite] = layer > > > > Hope that helps > > ~DR0ID > -- Jeffrey Kleykamp
[pygame] BUG: LayeredUpdate 'layer' vs '_layer'
Hi all, In pygame.sprite.LayeredUpdate.add documentation it says "If the sprite(s) have an attribute layer then that is used for the layer. If **kwargs contains 'layer' then the sprite(s) will be added to that argument (overriding the sprite layer attribute). If neither is passed then the sprite(s) will be added to the default layer." This implies it relies on sprite.layer. But by looking at the source I saw if you want to affect which layer your sprite will get added to, you have to set sprite._layer before calling add(). So the documentation and the code doesn't match. Not so much a bug; more of a clarification. Sincerely, Jeffrey -- Jeffrey Kleykamp
Re: [pygame] (Yet Another) Super Mario Bros project
Looks really good! Great job :D -Jeffrey On Wed, Mar 5, 2014 at 7:36 AM, Guillaume227 wrote: > Dear pygame users, > > I coded up a version of Super Mario Bros in pygame back in 2012 and only > got > to tidying it up a bit recently. > It's now up on Sourceforge.net : Super Coco > <http://sourceforge.net/projects/supercoco/> . > First level is a replica of the original game and then it forks off in a > custom way. > I know there has been other attempts at implementing SMB but it was a lot > of > fun to develop so I wanted to put a link up to that project on pygame.orgas > other people might find it interesting. And also so I could learn from > feedback. > > Is there a way to put it up on pygame.org even though new registrations > are > locked? > > > Best, > Guillaume > > > > > -- > View this message in context: > http://pygame-users.25799.x6.nabble.com/Yet-Another-Super-Mario-Bros-project-tp1091.html > Sent from the pygame-users mailing list archive at Nabble.com. > -- Jeffrey Kleykamp
