Re: [pygame] Noob question: playing sounds
On Thu, Jun 4, 2015 at 12:03 PM, Philip Le Riche wrote: > Thank you for that, but still no joy whatsoever. I also tried uninstalling > python-pygame and installing python3-pygame instead, but that gave the same > error and furthermore, wouldn't recognise the existence of my wav file. I > also tried installing pulseaudio, python-alsaaudio and python-pyalsa, > thinking that it looked like pygame was failing to connect to the underlying > sound system, but nothing made any difference. > > Are people successfully using pygame on the Raspberry Pi, or is it just > broken? > I think you'll have more luck asking in the RPi forums. Looking at the last post in this thread it seems to be a problem with pulseaudio: https://www.raspberrypi.org/forums/viewtopic.php?t=45548&p=360197 Are you able to run other sound applications?
Re: [pygame] image conversion in memory
On Thu, Aug 14, 2014 at 12:07 PM, diliup gabadamudalige wrote: > I am reading up on creating and using zip files and may possibly use it, > What I am trying to do here is to hide the images on disk so that a user of > the program will not be able to manipulate or change the images. What other > way can you suggest? > Thanks for all the help so far. > That's a pretty hard thing to do. If the user is supposed to be able to open and see the images from the program, then they can still PrintScreen and grab the image. All I can suggest there is adding a watermark, so you at least know if they are grabbing it from the screen. If you zip the images with a password, then that password will still be in the script, the user will be able to obtain it. You can try to obfuscate the password but that only goes so far, anyone with some python knowledge would be able to find it out. Maybe compile the sensitive parts with cython and hope the users are not curious?
Re: [pygame] Updating the pygame.org news section with an intro video to pygame?
On Sat, May 24, 2014 at 12:43 AM, Michael Lutynski wrote: > So can someone connect me with the person or persons who are in charge of > the pygame.org site to get Pygame news posted? I really want to see Pygame > get some love, and I'd be willing to help. > Try tweeting it to @pygame_org. There was going to be a planet to aggregate blogpost but I don't know if it's implemented yet.
Re: [pygame] preview of new pygame website... HiFi part
On Mon, Apr 7, 2014 at 5:53 AM, Sam Bull wrote: > On lun, 2014-04-07 at 18:07 +1200, Greg Ewing wrote: >> Al Sweigart wrote: >> > Oh, also, we should keep the Pygame logo. It's familiar branding, and it >> > doesn't look bad at all. > > Actually, I think that's another bug. If you zoom in (Ctrl + > scrollwheel), at some point the logo appears. So, that's something that > needs to be fixed, so it displays at all times. Perhaps using a vector > graphic for the logo, so it scales nicely? It doesn't appear for me even trying all kinds of zooming. I am using Chromium Version 33.0.1750.152 Debian jessie/sid If I change this `` for this `` in the dev console then it works :) I like the content of the columns, but not a fan of the horizontal scrolling. If you plan to keep this design though, I'd like it if the columns were a bit wider. My screen fits 4.5 columns. I think 3 columns + a bit more white space between them would look better. I also think it should tell you what Pygame is, maybe add a short description under the logo, something along the lines of: "PyGame allows you to make games with Python." Also, to add playfulness, maybe use the Comic Neue font for headers? http://comicneue.com/ -- Carlos
Re: [pygame] New utility and library for pygame users in final BETA - simple support for multi-celled animation sheets - Tiallists needed.
On Fri, Feb 22, 2013 at 3:58 PM, DR0ID wrote: >... > > Hi > > Your idea is nice and I'm sure it works perfectly for grid based sprite > sheets. Its simple and uses only one file. > > In my opinion there are following cons: > > many sprite sheets you can find might be grid base, but there are also many > that are not (copy the images into a grid might work, but has it's drawbacks > too) > if you have a separate file you could define your animation sequences > reusing the same sprite over and over (example: you have a standing > character image, that image you want to use in a walk, jump, idle animation, > one image instead of copy it three times to each grid based sprite sheet, > what if you have to change it?) > if the image offset is wrong in a grid based sprite sheet you need to move > it in a image editor, but using a different file you just change a (magic) > number > the image size limits are only set by the image edit, your (video) ram, your > hardware speed > > > It would be useful if there would be a visual tool to generate the extra > files and and a python module to facilitate the loading of such files and > sprite sheets. I have given it myself some thoughts for some time now. I > would be happy to elaborate. > It would be awesome if there was a pygame plugin for this tool: http://www.brashmonkey.com/spriter.htm It uses an open sourced xml format called scml that allows skeletal animation and there are several implementations being developed by the community for various languages and engines: http://www.brashmonkey.com/forum/viewforum.php?f=3 Spriter itself isn't open source, but there's a free beta here for Windows, Mac and Linux: http://www.brashmonkey.com/forum/viewtopic.php?f=2&t=1235 -- Carlos Z
Re: [pygame] Rect attribute on pygame.draw.rect(screen, color, Rect, width=0)
On Sun, Sep 2, 2012 at 3:52 PM, mr_Roboman4321 wrote: > Hello. I'm trying to assign the rect attribute in a pygame.draw.rect() > statement to a mouse position. here's my code (it's inside a while True: > loop): > > Mouse = pygame.mouse.get_pos() > MouseRect = pygame.draw.rect(screen, RED, (Mouse, 100, 100), 1) Since mouse.get_post returns a tuple and as rect you can pass a 4 item tuple, you might want to use (Mouse +(100, 100)) instead > > what I am trying to do with this is to see if the mouse has passed over any > of my sprite rects. If there is an easier way to do this, show that way. > Thanks for all the help! Rects themselves have collide methods, see: http://www.pygame.org/docs/ref/rect.html#Rect.collidepoint -- Carlos Z
Re: [pygame] Pygame, pyglet, 2d, 3d, and performance (reflexions/discussion)
On Sun, Feb 12, 2012 at 5:25 PM, Santiago Romero wrote: > > Pygame performance (and SDL, and almost any 2D-programming technology before > it) it's a bit about CPU power. Ok, GPU cards help blitting, but notice that > almost all SDL/pygame games are medium resolution (640x480, 800x600), > usually fullscreen, and maybe higher resolutions for more static/non > scrolling games. > > 3D games work nicely with either FullHD/HDready resolutions and you can > select easily the playing resolution and everything scales nicely. Also, 3D > games benefit a lot from GPUs acceleration and you can run them at high > resolutions at 60 fps and the GPU makes a lot of the job. > > 2D games are a "pain in the ass" to make them multiresolution and scale very > bad to high resolutions (in terms of speed). > > I'm starting to wonder how many time can I continue writing 2D programs with > the classical 2D approach. I'm wondering if maybe I have to write 2D games > by using 3D technology (opengl) to render sprites as faces in cubes with a > background-cube and a camera pointing in a "2d view". Some libraries, like > pyglet / cocos2d use this approach. > > My problem is that I like and prefer the "romantic-classic" pure 2d > approach. The pyglet/cocos idea of actors, scenes and 2d-3d modelling is not > as nice for me than the classic "oldstyle" approach... but that 3d approach > really works and their 3D-2D games work in high resolutions at full speed > and in pygame you can suffer creating a hires multilayer scrolling game at > 60 fps... Another nice library you can use is PySFML, programming in it is somewhat similar to pygame (compared to pyglet which I have tried just a little, no idea about cocos) but with opengl behind it. www.sfml-dev.org -- Carlosz