[pygame] Why does pygame.sndarray.make_sound seemingly quadruple the sound duration?
The following code: import pygame, numpy pygame.mixer.pre_init(frequency=96000,size=-16,channels=1) pygame.init() a = numpy.random.randn(96000) sound = pygame.sndarray.make_sound(a) print sound.get_length() yields a print-out of 4.0, suggesting that the specified duration of 96000 samples at a 96000kHz sampling rate was somehow quadrupled somewhere along the way. Any idea what I'm missing here? Or is this a bug?
Re: [pygame] Why does pygame.sndarray.make_sound seemingly quadruple the sound duration?
Thanks for your response. Support for your suggestion comes from observation that changing the size from -16 to -8 yields an octupling of the duration. So it seems that pygame.sndarray.make_sound isn't properly accounting for the bit depth of the numpy array. On Mon, May 21, 2012 at 3:03 PM, Nicholas Seward nicholas.sew...@gmail.com wrote: Could it be that a is an array of 64bit floats and each array element becomes 4 16-bit samples? On Mon, May 21, 2012 at 12:54 PM, Mike Lawrence mike.lw...@gmail.com wrote: The following code: import pygame, numpy pygame.mixer.pre_init(frequency=96000,size=-16,channels=1) pygame.init() a = numpy.random.randn(96000) sound = pygame.sndarray.make_sound(a) print sound.get_length() yields a print-out of 4.0, suggesting that the specified duration of 96000 samples at a 96000kHz sampling rate was somehow quadrupled somewhere along the way. Any idea what I'm missing here? Or is this a bug?
Re: [pygame] Why does pygame.sndarray.make_sound seemingly quadruple the sound duration?
good call, thanks! On Mon, May 21, 2012 at 3:59 PM, Nicholas Seward nicholas.sew...@gmail.com wrote: a = a.astype(numpy.float16) should convert the array over for you. Note: float16 did not exist prior to numpy1.6. The default version of numpy that I got from the ubuntu repo was only version 1.5.1. On Mon, May 21, 2012 at 1:29 PM, Mike Lawrence mike.lw...@gmail.com wrote: Thanks for your response. Support for your suggestion comes from observation that changing the size from -16 to -8 yields an octupling of the duration. So it seems that pygame.sndarray.make_sound isn't properly accounting for the bit depth of the numpy array. On Mon, May 21, 2012 at 3:03 PM, Nicholas Seward nicholas.sew...@gmail.com wrote: Could it be that a is an array of 64bit floats and each array element becomes 4 16-bit samples? On Mon, May 21, 2012 at 12:54 PM, Mike Lawrence mike.lw...@gmail.com wrote: The following code: import pygame, numpy pygame.mixer.pre_init(frequency=96000,size=-16,channels=1) pygame.init() a = numpy.random.randn(96000) sound = pygame.sndarray.make_sound(a) print sound.get_length() yields a print-out of 4.0, suggesting that the specified duration of 96000 samples at a 96000kHz sampling rate was somehow quadrupled somewhere along the way. Any idea what I'm missing here? Or is this a bug?
[pygame] Modified SDL1.2/pygame1.9.1 with event timestamps available
Hi folks, I ended up paying someone to backport SDL2's high-precision timer and event-timestamping to SDL1.2 then modify pygame1.9.1 to access these modifications. The source code is available here: http://www.filedropper.com/sdlpygame Cheers, Mike -- Mike Lawrence Graduate Student Department of Psychology Dalhousie University Looking to arrange a meeting? Check my public calendar: http://goo.gl/BYH99 ~ Certainty is folly... I think. ~
Re: [pygame] Pygame 2.0
Not to mention support for SDL 1.3/2.0 ... On Sun, Feb 12, 2012 at 9:21 PM, Zack Baker zbaker1...@gmail.com wrote: I've only been on the mailing list for a few months now so forgive me but is pygame 2.0 anywhere on the horizon? I would be very willing to do tests on I with Mac sox lion because my dream would be Mac with pygame on python 3.0 sigh Zack
Re: [pygame] Render font and usging \n
Attached is an example that handles line breaks manually; it also handles text wrapping. 2009/11/2 leo kirotawa kirot...@gmail.com: ok, thanks a lot On Mon, Nov 2, 2009 at 11:29 PM, Ian Mallett geometr...@gmail.com wrote: No; PyGame does not support that. You must handle line breaks manually, rendering as separate surfaces. Use .get_linesize() to space the surfaces appropriately. -Ian -- Leônidas S. Barbosa (Kirotawa) [DesenvolvedorWeb/CEFET/RN] [Ciências da Computação/UFRN] [pós-graduando em Inteligência Computacional/Processamento Gráfico /UFRN [Estudante de japonês nível 8 - Japanese Student] [Desenvolvedor em python, PyGame] blog: corecode.wordpress.com/ Mais sábio é aquele que sabe que não sabe (Sócrates) 日本語の学生です。 コンピュータサイエンスの学位. -- Mike Lawrence Graduate Student Department of Psychology Dalhousie University Looking to arrange a meeting? Check my public calendar: http://tr.im/mikes_public_calendar ~ Certainty is folly... I think. ~ draw_text.py Description: Binary data
[pygame] Efficient circles
Hi all, Now that pygame includes the (experimental) gfxdraw module for drawing shapes, I thought it might interest some to hear about an efficient circle drawing algorithm I came across: http://slabode.exofire.net/circle_draw.shtml (mirror: http://www.mmsguru.com/mirror/circle_cached.html) The link discusses it in the context of OpenGL, but where the algorithm is simply about finding out where to put the circle's vertices, it generalizes rather widely. Below I include a timing example of using it in pygame with gfxdraw. I know gfxdraw has a built-in circle drawing function; indeed, as you'll see at the end of the code, the built-in function is rather faster than either manual function I create (possibly because it wraps compiled code for determining the vertices?). However, I thought this example might still be of use to some, for example those that want to make their own version of the pie function that draws a filled pie, etc. It's even possible that whatever compiled code achieves the built-in circle functions may achieve speed-ups by implementing the more efficient vertex locating algorithm. A final note of interest, when polygon() is replaced by aapolygon() in the manual functions below, the traditional trig approach slows down quite a bit whereas SiegeLord's approach doesn't seem to slow down much at all. Not sure why this would be though. #START CODE# #import requisite libraries import pygame , math , time from pygame.locals import * from pygame.gfxdraw import * pygame.init() screen_size = (500,500) screen = pygame.display.set_mode(screen_size) screen_rect = screen.get_rect() screen_x_center = screen_size[0]/2 screen_y_center = screen_size[1]/2 BLACK = (0,0,0) WHITE = (255,255,255) screen.fill(BLACK) radius = 200 #define the standard (slow) circle function def draw_circle(cx,cy,radius): points = [] for angle in range(361): points.append(( \ cx + math.sin(angle) * radius \ , cy + math.cos(angle) * radius \ )) polygon(screen,points,WHITE) #time the standard circle function start=time.time() for i in range(1000): draw_circle( \ screen_x_center \ , screen_y_center \ , radius \ ) print time.time()-start #define SiegeLord's (faster) circle function def draw_circle_fast(cx, cy, radius): theta = 2 * math.pi / 361 tangetial_factor = math.tan(theta) radial_factor = math.cos(theta) x = radius y = 0 points = [] for ii in range(361): points.append((x + cx, y + cy)) tx = -y ty = x x = x + tx * tangetial_factor y = y + ty * tangetial_factor x = x * radial_factor y = y * radial_factor polygon(screen,points,WHITE) #time SiegeLord's function start=time.time() for i in range(1000): draw_circle_fast( \ screen_x_center \ , screen_y_center \ , radius \ ) print time.time()-start #time the built-in function start=time.time() for i in range(1000): circle( \ screen \ , screen_x_center \ , screen_y_center \ , radius \ , WHITE \ ) print time.time()-start #END CODE# -- Mike Lawrence Graduate Student Department of Psychology Dalhousie University Looking to arrange a meeting? Check my public calendar: http://tr.im/mikes_public_calendar ~ Certainty is folly... I think. ~
Re: [pygame] font alpha
Rendering the semi-transparent text with the appropriate background 'seems' to make it work again. #- # Mike's Code modified to use non-black screen import pygame import time pygame.init() screen = pygame.display.set_mode((640,480), pygame.SRCALPHA) screen.fill((255,0,255)) myFont = pygame.font.Font(None, 30) nonTransparent = myFont.render(This text should be fully opaque, 1, (255,255,255)) screen.blit(nonTransparent, (0,0)) myText = 'This text should be somewhat transparent' semiTransparent = myFont.render(myText, 1, (255,255,255), (255,0,255)) newSurf = pygame.Surface(myFont.size(myText)) newSurf.blit(semiTransparent,(0,0)) newSurf.set_alpha(100) screen.blit(newSurf, (0,100)) pygame.display.flip() time.sleep(5) -- Mike Lawrence Graduate Student, Department of Psychology, Dalhousie University Website: http://memetic.ca Public calendar: http://icalx.com/public/informavore/Public The road to wisdom? Well, it's plain and simple to express: Err and err and err again, but less and less and less. - Piet Hein
Re: [pygame] font alpha
Ah, well eventually I'll be overlaying different font layers over top of one another so maybe you're right in that my solution is still unsatisfactory. On 6-Sep-07, at 2:00 PM, Brian Fisher wrote: haha... I assumed you wanted something font letters with alpha - so you had something that could be drawn over something other than a solid color - but I guess you could always grab the background behind where you want the text in a surface, blit the text over the piece of the background you grabbed in the surface, then set alpha on the background surface and blit that, and it would work for the effect you want no matter the background. On 9/6/07, Mike Lawrence [EMAIL PROTECTED] wrote: Rendering the semi-transparent text with the appropriate background 'seems' to make it work again. #- # Mike's Code modified to use non-black screen import pygame import time pygame.init() screen = pygame.display.set_mode((640,480), pygame.SRCALPHA) screen.fill((255,0,255)) myFont = pygame.font.Font(None, 30) nonTransparent = myFont.render(This text should be fully opaque, 1, (255,255,255)) screen.blit(nonTransparent, (0,0)) myText = 'This text should be somewhat transparent' semiTransparent = myFont.render(myText, 1, (255,255,255), (255,0,255)) newSurf = pygame.Surface(myFont.size(myText)) newSurf.blit(semiTransparent,(0,0)) newSurf.set_alpha(100) screen.blit(newSurf, (0,100)) pygame.display.flip() time.sleep(5) -- Mike Lawrence Graduate Student, Department of Psychology, Dalhousie University Website: http://memetic.ca Public calendar: http://icalx.com/public/informavore/Public The road to wisdom? Well, it's plain and simple to express: Err and err and err again, but less and less and less. - Piet Hein -- Mike Lawrence Graduate Student, Department of Psychology, Dalhousie University Website: http://memetic.ca Public calendar: http://icalx.com/public/informavore/Public The road to wisdom? Well, it's plain and simple to express: Err and err and err again, but less and less and less. - Piet Hein
[pygame] font alpha
Hi all, Apologies for the seemingly newb help request but I can't seem to figure out how to vary the alpha value of rendered font surfaces. Here are my attempts thusfar: import pygame pygame.init() screen = pygame.display.set_mode((640,480), pygame.SRCALPHA) screen.fill((0,0,0)) myFont = pygame.font.Font(None, 30) nonTransparent = myFont.render(This text should be fully opaque, 1, (255,255,255)) screen.blit(nonTransparent, (0,0)) semiTransparent = myFont.render(This text should be somewhat transparent, 1, (255,255,255)) semiTransparent.set_alpha(100) screen.blit(semiTransparent, (0,100)) pygame.display.flip() #When I flip, both messages are the same color, indicating that the transparency on the second failed -- Mike Lawrence Graduate Student, Department of Psychology, Dalhousie University Website: http://memetic.ca Public calendar: http://icalx.com/public/informavore/Public The road to wisdom? Well, it's plain and simple to express: Err and err and err again, but less and less and less. - Piet Hein
Re: [pygame] font alpha
Good call Luke. Removing antialiasing did indeed result in a surface with a usable set_alpha component. However, I'd really like to have antialiased text. Inserting 'semiTransparent.convert_alpha()' between lines 9 and 10 didn't seem to help either. On 5-Sep-07, at 9:18 PM, Luke Paireepinart wrote: Mike Lawrence wrote: Hi all, Apologies for the seemingly newb help request but I can't seem to figure out how to vary the alpha value of rendered font surfaces. Here are my attempts thusfar: import pygame pygame.init() screen = pygame.display.set_mode((640,480), pygame.SRCALPHA) screen.fill((0,0,0)) myFont = pygame.font.Font(None, 30) nonTransparent = myFont.render(This text should be fully opaque, 1, (255,255,255)) screen.blit(nonTransparent, (0,0)) semiTransparent = myFont.render(This text should be somewhat transparent, 1, (255,255,255)) semiTransparent.set_alpha(100) screen.blit(semiTransparent, (0,100)) pygame.display.flip() #When I flip, both messages are the same color, indicating that the transparency on the second failed I don't think that fonts are rendered with surface alpha to start. does set_alpha apply surface alpha if they don't have it already? Maybe try convert_alpha first? It's possible that since you're aliasing the fonts they might be using per-pixel alpha which might conflict with surface alpha. Just some suggestions, I've never tried this. -Luke -- Mike Lawrence Graduate Student, Department of Psychology, Dalhousie University Website: http://memetic.ca Public calendar: http://icalx.com/public/informavore/Public The road to wisdom? Well, it's plain and simple to express: Err and err and err again, but less and less and less. - Piet Hein -- Mike Lawrence Graduate Student, Department of Psychology, Dalhousie University Website: http://memetic.ca Public calendar: http://icalx.com/public/informavore/Public The road to wisdom? Well, it's plain and simple to express: Err and err and err again, but less and less and less. - Piet Hein
Re: [pygame] font alpha
Got it. You need to blit the rendered text to a new surface then change the alpha value of that new surface before blitting it to screen. import pygame pygame.init() screen = pygame.display.set_mode((640,480), pygame.SRCALPHA) screen.fill((0,0,0)) myFont = pygame.font.Font(None, 30) nonTransparent = myFont.render(This text should be fully opaque, 1, (255,255,255)) screen.blit(nonTransparent, (0,0)) myText = 'This text should be somewhat transparent' semiTransparent = myFont.render(myText, 1, (255,255,255)) newSurf = pygame.Surface(myFont.size(myText)) newSurf.blit(semiTransparent,(0,0)) newSurf.set_alpha(100) screen.blit(newSurf, (0,100)) pygame.display.flip() On 5-Sep-07, at 9:47 PM, Mike Lawrence wrote: Good call Luke. Removing antialiasing did indeed result in a surface with a usable set_alpha component. However, I'd really like to have antialiased text. Inserting 'semiTransparent.convert_alpha()' between lines 9 and 10 didn't seem to help either. On 5-Sep-07, at 9:18 PM, Luke Paireepinart wrote: Mike Lawrence wrote: Hi all, Apologies for the seemingly newb help request but I can't seem to figure out how to vary the alpha value of rendered font surfaces. Here are my attempts thusfar: import pygame pygame.init() screen = pygame.display.set_mode((640,480), pygame.SRCALPHA) screen.fill((0,0,0)) myFont = pygame.font.Font(None, 30) nonTransparent = myFont.render(This text should be fully opaque, 1, (255,255,255)) screen.blit(nonTransparent, (0,0)) semiTransparent = myFont.render(This text should be somewhat transparent, 1, (255,255,255)) semiTransparent.set_alpha(100) screen.blit(semiTransparent, (0,100)) pygame.display.flip() #When I flip, both messages are the same color, indicating that the transparency on the second failed I don't think that fonts are rendered with surface alpha to start. does set_alpha apply surface alpha if they don't have it already? Maybe try convert_alpha first? It's possible that since you're aliasing the fonts they might be using per-pixel alpha which might conflict with surface alpha. Just some suggestions, I've never tried this. -Luke -- Mike Lawrence Graduate Student, Department of Psychology, Dalhousie University Website: http://memetic.ca Public calendar: http://icalx.com/public/informavore/Public The road to wisdom? Well, it's plain and simple to express: Err and err and err again, but less and less and less. - Piet Hein -- Mike Lawrence Graduate Student, Department of Psychology, Dalhousie University Website: http://memetic.ca Public calendar: http://icalx.com/public/informavore/Public The road to wisdom? Well, it's plain and simple to express: Err and err and err again, but less and less and less. - Piet Hein -- Mike Lawrence Graduate Student, Department of Psychology, Dalhousie University Website: http://memetic.ca Public calendar: http://icalx.com/public/informavore/Public The road to wisdom? Well, it's plain and simple to express: Err and err and err again, but less and less and less. - Piet Hein