Re: [pygame] Resolution for a 2d game
Then query the monitor sizes using pygame.display.list_modes or make it a configurable option, and use math that works independently of the resolution. On Sun, May 15, 2011 at 3:37 PM, BIAGINI wrote: > So my game will run in 640*480... I m not sure to understand. I really want > to make my game is an higher resolution than 640*480. > > Le 15 mai 2011 à 20:49, Christopher Arndt a écrit : > >> On 15.05.11 19:47, BIAGINI wrote: >>> I really dont know how to handle several resolution especially for my >>> online game. >> >> Just make your game fullscreen and choose a fixed resolution that will >> fit on the smallest supported monitor. >> >> Chris >
Re: [pygame] converting "object position" to "view position" in (py)opengl
The rows and columns don't matter since the part of the matrix you're
changing is symmetric. ;) I am pretty sure that the first index is the
the column and the second is the row.
Yes, just make sure you do the translate _before_ the billboarding
code is done. Otherwise, the translate would be relative to the camera
and not the world.
On Thu, Jul 2, 2009 at 11:45 PM, Astan Chee wrote:
> Thanks for that.
> The thing is that I'm trying to do that in python and I'm stuck at
> modelview[16] in python because it is in [4][4] array in python and I'm not
> sure which one is rows and cols from c++ to python.
> Also, when I draw the quad at the object's center, do I need to do a
> glTranslatef? I'm guessing I do, right?
> Thanks again.
> Astan
>
> Forrest Voight wrote:
>
> I meant after the modelview matrix was tranformed to the camera position.
>
> This is the only code you need for billboarding - transforming the
> matrix to make the object always face the camera:
>
>
> float modelview[16];
> int i,j;
>
> // save the current modelview matrix
> glPushMatrix();
>
> // get the current modelview matrix
> glGetFloatv(GL_MODELVIEW_MATRIX , modelview);
>
> // undo all rotations
> // beware all scaling is lost as well
> for( i=0; i<3; i++ )
> for( j=0; j<3; j++ ) {
> if ( i==j )
> modelview[i*4+j] = 1.0;
> else
> modelview[i*4+j] = 0.0;
> }
>
> // set the modelview with no rotations and scaling
> glLoadMatrixf(modelview);
>
> drawObject();
>
> // restores the modelview matrix
> glPopMatrix();
>
>
> drawObject would be replaced by the code that draws a quad at the
> object's center. You would need to store the aspect ratio of the
> output of font.render (aspect = width/height) and use it to draw a
> correctly sized quad - for example, with a height of 1 and a width of
> aspect. The quad would need the appropriate texcoords - just 0,0 0,1
> 1,1 and 1,0 for the corners of the texture with the rendered text.
>
>
> On Thu, Jul 2, 2009 at 10:41 PM, Astan Chee wrote:
>
>
> What do you mean "after the matrices are set"? is it when I'm doing an
> "initgl" like this:
> glShadeModel(GL_SMOOTH)
> glClearColor(0.0, 0.0, 0.0, 0.0)
> glClearDepth(1.0)
> glEnable(GL_DEPTH_TEST)
> glDepthFunc(GL_LEQUAL)
> glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST)
> glEnable(GL_COLOR_MATERIAL)
> glEnable(GL_TEXTURE_2D)
> or when the window resize is being called:
> def resize(self,(width, height)):
> if height==0:
> height=1
> glViewport(0, 0, width, height)
> glMatrixMode(GL_PROJECTION)
> glLoadIdentity()
> gluPerspective(45, 1.0*width/height, 1.0, 1.0)
> glMatrixMode(GL_MODELVIEW)
> glLoadIdentity()
> also, you lost me at your last sentence...I have no idea what that means but
> I'll google around.
> thanks again
>
> Forrest Voight wrote:
>
> When are you doing the gluProject? It should be after the matrices are
> set for the frame. Can you paste the code for that?
>
> To billboard text, you'd render it to a texture.
>
> Something like:
>
> surface = self.font.render(s, True, (255, 255, 255))
> gluBuild2DMipmaps(GL_TEXTURE_2D, GL_RGBA, surface.get_width(),
> surface.get_height(), GL_RGBA, GL_UNSIGNED_BYTE,
> pygame.image.tostring(surface, "RGBA", True)
>
> Then, when rendering, transform the modelview matrix as in that link,
> and draw a quad with the correct aspect ratio.
>
> On Wed, Jul 1, 2009 at 10:58 PM, Astan Chee wrote:
>
>
> Thanks for that, but it doesn't seem to work. Well, it gives coordinates of
> x,y(,z) but when the camera changes angle (but not position), the
> coordinates don't change. What else do I need to be doing in this?
> Anyway, I also forgot to mention this is how I make the text images:
> def __init__(self):
> pygame.font.init()
> self.font = pygame.font.Font(FONT,18)
> self.char = []
> for c in range(256):
> self.char.append(self.CreateCharacter(chr(c)))
> self.char = tuple(self.char)
>
> def CreateCharacter(self,s):
> try:
> letter_render = self.font.render(s,1,(255,255,255), (0,0,0))
> letter = pygame.image.tostring(letter_render,'RGBA',1)
> letter_w,letter_h = letter_render.get_size()
> except:
> letter = None
> letter_w = letter_h= 0
> return (letter,letter_w,letter_h)
> Since I make t
Re: [pygame] converting "object position" to "view position" in (py)opengl
I meant after the modelview matrix was tranformed to the camera position.
This is the only code you need for billboarding - transforming the
matrix to make the object always face the camera:
float modelview[16];
int i,j;
// save the current modelview matrix
glPushMatrix();
// get the current modelview matrix
glGetFloatv(GL_MODELVIEW_MATRIX , modelview);
// undo all rotations
// beware all scaling is lost as well
for( i=0; i<3; i++ )
for( j=0; j<3; j++ ) {
if ( i==j )
modelview[i*4+j] = 1.0;
else
modelview[i*4+j] = 0.0;
}
// set the modelview with no rotations and scaling
glLoadMatrixf(modelview);
drawObject();
// restores the modelview matrix
glPopMatrix();
drawObject would be replaced by the code that draws a quad at the
object's center. You would need to store the aspect ratio of the
output of font.render (aspect = width/height) and use it to draw a
correctly sized quad - for example, with a height of 1 and a width of
aspect. The quad would need the appropriate texcoords - just 0,0 0,1
1,1 and 1,0 for the corners of the texture with the rendered text.
On Thu, Jul 2, 2009 at 10:41 PM, Astan Chee wrote:
> What do you mean "after the matrices are set"? is it when I'm doing an
> "initgl" like this:
> glShadeModel(GL_SMOOTH)
> glClearColor(0.0, 0.0, 0.0, 0.0)
> glClearDepth(1.0)
> glEnable(GL_DEPTH_TEST)
> glDepthFunc(GL_LEQUAL)
> glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST)
> glEnable(GL_COLOR_MATERIAL)
> glEnable(GL_TEXTURE_2D)
> or when the window resize is being called:
> def resize(self,(width, height)):
> if height==0:
> height=1
> glViewport(0, 0, width, height)
> glMatrixMode(GL_PROJECTION)
> glLoadIdentity()
> gluPerspective(45, 1.0*width/height, 1.0, 1.0)
> glMatrixMode(GL_MODELVIEW)
> glLoadIdentity()
> also, you lost me at your last sentence...I have no idea what that means but
> I'll google around.
> thanks again
>
> Forrest Voight wrote:
>
> When are you doing the gluProject? It should be after the matrices are
> set for the frame. Can you paste the code for that?
>
> To billboard text, you'd render it to a texture.
>
> Something like:
>
> surface = self.font.render(s, True, (255, 255, 255))
> gluBuild2DMipmaps(GL_TEXTURE_2D, GL_RGBA, surface.get_width(),
> surface.get_height(), GL_RGBA, GL_UNSIGNED_BYTE,
> pygame.image.tostring(surface, "RGBA", True)
>
> Then, when rendering, transform the modelview matrix as in that link,
> and draw a quad with the correct aspect ratio.
>
> On Wed, Jul 1, 2009 at 10:58 PM, Astan Chee wrote:
>
>
> Thanks for that, but it doesn't seem to work. Well, it gives coordinates of
> x,y(,z) but when the camera changes angle (but not position), the
> coordinates don't change. What else do I need to be doing in this?
> Anyway, I also forgot to mention this is how I make the text images:
> def __init__(self):
> pygame.font.init()
> self.font = pygame.font.Font(FONT,18)
> self.char = []
> for c in range(256):
> self.char.append(self.CreateCharacter(chr(c)))
> self.char = tuple(self.char)
>
> def CreateCharacter(self,s):
> try:
> letter_render = self.font.render(s,1,(255,255,255), (0,0,0))
> letter = pygame.image.tostring(letter_render,'RGBA',1)
> letter_w,letter_h = letter_render.get_size()
> except:
> letter = None
> letter_w = letter_h= 0
> return (letter,letter_w,letter_h)
> Since I make the text this way, I'm thinking of just doing it billboard but
> I'm not sure how to implement half of this.
> Thanks again for any help.
> Cheers
> Astan
>
>
> Ian Mallett wrote:
>
> Er, the last three arguments return the data in C. In Python, the syntax is
> different:
>
> C: gluProject(objx,objy,objz,model,proj,view,winx,winy,winz)
> Python: winx,winy,winz = gluProject(objx,objy,objz,model,proj)
>
> And yes, it returns a z-coord, which should take into account the near
> clipping plane. As long as the plane is ~0, (x,y) should be fairly
> accurate.
>
> Keep in mind that the (x,y) coordinates are *real* coordinates, (i.e., the y
> is not flipped). (0,0) is the bottom left. If you rasterize the font as
> you were, it shouldn't be a problem.
>
> Ian
>
>
>
>
Re: [pygame] converting "object position" to "view position" in (py)opengl
When are you doing the gluProject? It should be after the matrices are set for the frame. Can you paste the code for that? To billboard text, you'd render it to a texture. Something like: surface = self.font.render(s, True, (255, 255, 255)) gluBuild2DMipmaps(GL_TEXTURE_2D, GL_RGBA, surface.get_width(), surface.get_height(), GL_RGBA, GL_UNSIGNED_BYTE, pygame.image.tostring(surface, "RGBA", True) Then, when rendering, transform the modelview matrix as in that link, and draw a quad with the correct aspect ratio. On Wed, Jul 1, 2009 at 10:58 PM, Astan Chee wrote: > Thanks for that, but it doesn't seem to work. Well, it gives coordinates of > x,y(,z) but when the camera changes angle (but not position), the > coordinates don't change. What else do I need to be doing in this? > Anyway, I also forgot to mention this is how I make the text images: > def __init__(self): > pygame.font.init() > self.font = pygame.font.Font(FONT,18) > self.char = [] > for c in range(256): > self.char.append(self.CreateCharacter(chr(c))) > self.char = tuple(self.char) > > def CreateCharacter(self,s): > try: > letter_render = self.font.render(s,1,(255,255,255), (0,0,0)) > letter = pygame.image.tostring(letter_render,'RGBA',1) > letter_w,letter_h = letter_render.get_size() > except: > letter = None > letter_w = letter_h= 0 > return (letter,letter_w,letter_h) > Since I make the text this way, I'm thinking of just doing it billboard but > I'm not sure how to implement half of this. > Thanks again for any help. > Cheers > Astan > > > Ian Mallett wrote: > > Er, the last three arguments return the data in C. In Python, the syntax is > different: > > C: gluProject(objx,objy,objz,model,proj,view,winx,winy,winz) > Python: winx,winy,winz = gluProject(objx,objy,objz,model,proj) > > And yes, it returns a z-coord, which should take into account the near > clipping plane. As long as the plane is ~0, (x,y) should be fairly > accurate. > > Keep in mind that the (x,y) coordinates are *real* coordinates, (i.e., the y > is not flipped). (0,0) is the bottom left. If you rasterize the font as > you were, it shouldn't be a problem. > > Ian >
Re: [pygame] converting "object position" to "view position" in (py)opengl
The Python syntax defaults to the current matrices, so you only need the 3 coordinates. On 7/1/09, Ian Mallett wrote: > Er, the last three arguments return the data in C. In Python, the syntax is > different: > > C: gluProject(objx,objy,objz,model,proj,view,winx,winy,winz) > Python: winx,winy,winz = gluProject(objx,objy,objz,model,proj) > > And yes, it returns a z-coord, which should take into account the near > clipping plane. As long as the plane is ~0, (x,y) should be fairly > accurate. > > Keep in mind that the (x,y) coordinates are *real* coordinates, (i.e., the y > is not flipped). (0,0) is the bottom left. If you rasterize the font as > you were, it shouldn't be a problem. > > Ian >
Re: [pygame] converting "object position" to "view position" in (py)opengl
The z doesn't matter, but the x and y are pixel coordinates like pygame.mouse.get_pos(). Also, gluProject has defaults for the last 3 params, so they aren't needed. On Wed, Jul 1, 2009 at 3:10 AM, Astan Chee wrote: > Thanks for that. How do I convert x,y,z to the x,y coordinates of a pygame > surface window? Kinda like the coordinates that pygame.mouse.get_pos() > returns? > Thanks again > > Ian Mallett wrote: > > You'll definitely want to use glu somewhere. gluLookAt(...) comes to > mind... > > Anyway, for gluProject, try this (not tested, but should work) > > x,y,z = gluProject(object.x,object.y,object.z,\ > glGetDoublev(GL_MODELVIEW_MATRIX),glGetDoublev(GL_PROJECTION_MATRIX),\ > glGetIntegerv(GL_VIEWPORT)) > > HTH, > Ian >
Re: [pygame] converting "object position" to "view position" in (py)opengl
You can have dynamic text on a billboard ... just update the texture when you need to. How are you currently rendering text? Why not use GLU? It's almost sure to be there if GL is. GLUT isn't on the other hand ... You could reimplement the glProject function in Python, but billboarding would be easiest. On Wed, Jul 1, 2009 at 1:19 AM, Astan Chee wrote: > Also, I'm trying not to use glu or glut functions. > > Forrest Voight wrote: > > Why does the cross-section matter? > > Just display it at the object's center... > > On Wed, Jul 1, 2009 at 1:01 AM, Astan Chee wrote: > > > Yes, this is what I'm trying to do but how do I calculate cross-section of > the object at a given distance? > Thanks again > > Tyler Laing wrote: > > Hmm, I'm not 100% familiar with 3d programming, but wouldn't the best way be > to find the cross-section of the object at some distance from the camera, > which would be a 2d shape, and then you can center the text on that shape? > > On Tue, Jun 30, 2009 at 9:26 PM, Astan Chee wrote: > > > Hi, > Im relatively new to opengl and I'm not familiat with its jargon but what > I have is objects in a 3D world in various positions and a camera that can > "move" around. What I'm trying to do is if the distance between object and > camera is close enough, display some information on the screen on the > object. > I know how to calculate distance and I know how to print/display text in > opengl (I'm using glOrtho and glRasterPos2i to map out the characters one at > a time). > Anyway, what I'm having problems with is how do I calculate where to > display these information on the screen so that it overlaps the object > (assuming I know the distance and the angle of the camera and the object > relative to the camera). Does this make sense? I've attached an image that I > photoshopped to look like what I'm trying to do. > Thanks for any help > Astan > > > -- > Visit my blog at http://oddco.ca/zeroth/zblog > > > >
Re: [pygame] converting "object position" to "view position" in (py)opengl
Why does the cross-section matter? Just display it at the object's center... On Wed, Jul 1, 2009 at 1:01 AM, Astan Chee wrote: > Yes, this is what I'm trying to do but how do I calculate cross-section of > the object at a given distance? > Thanks again > > Tyler Laing wrote: > > Hmm, I'm not 100% familiar with 3d programming, but wouldn't the best way be > to find the cross-section of the object at some distance from the camera, > which would be a 2d shape, and then you can center the text on that shape? > > On Tue, Jun 30, 2009 at 9:26 PM, Astan Chee wrote: >> >> Hi, >> Im relatively new to opengl and I'm not familiat with its jargon but what >> I have is objects in a 3D world in various positions and a camera that can >> "move" around. What I'm trying to do is if the distance between object and >> camera is close enough, display some information on the screen on the >> object. >> I know how to calculate distance and I know how to print/display text in >> opengl (I'm using glOrtho and glRasterPos2i to map out the characters one at >> a time). >> Anyway, what I'm having problems with is how do I calculate where to >> display these information on the screen so that it overlaps the object >> (assuming I know the distance and the angle of the camera and the object >> relative to the camera). Does this make sense? I've attached an image that I >> photoshopped to look like what I'm trying to do. >> Thanks for any help >> Astan > > > > -- > Visit my blog at http://oddco.ca/zeroth/zblog >
Re: [pygame] converting "object position" to "view position" in (py)opengl
I would just billboard a texture with the text at the object's center with DEPTH_TEST disabled, so it draws over it. See http://www.lighthouse3d.com/opengl/billboarding/index.php3?billCheat Alternatively, you could use gluProject to get the window coordinates of the object's center, but I think it's best to not do pixel operations. On Wed, Jul 1, 2009 at 12:31 AM, Tyler Laing wrote: > Hmm, I'm not 100% familiar with 3d programming, but wouldn't the best way be > to find the cross-section of the object at some distance from the camera, > which would be a 2d shape, and then you can center the text on that shape? > > On Tue, Jun 30, 2009 at 9:26 PM, Astan Chee wrote: >> >> Hi, >> Im relatively new to opengl and I'm not familiat with its jargon but what >> I have is objects in a 3D world in various positions and a camera that can >> "move" around. What I'm trying to do is if the distance between object and >> camera is close enough, display some information on the screen on the >> object. >> I know how to calculate distance and I know how to print/display text in >> opengl (I'm using glOrtho and glRasterPos2i to map out the characters one at >> a time). >> Anyway, what I'm having problems with is how do I calculate where to >> display these information on the screen so that it overlaps the object >> (assuming I know the distance and the angle of the camera and the object >> relative to the camera). Does this make sense? I've attached an image that I >> photoshopped to look like what I'm trying to do. >> Thanks for any help >> Astan > > > > -- > Visit my blog at http://oddco.ca/zeroth/zblog >
Re: [pygame] VideoCapture, PIL, and PyGame
Why not just reverse the string in order to do the BGR->RGB conversion? This will also vertically and horizontally flip it, so you'll just need to horizontally flip it. On Sun, Jun 14, 2009 at 2:25 AM, René Dudfield wrote: > hi, > > take a look at svn pygame. There is an implementation of > pygame.camera which uses the VideoCapture module. > > cheers, > > > > On Sun, Jun 14, 2009 at 2:35 PM, Ian Mallett wrote: >> Hi, >> >> So, I'm trying to get VideoCapture working with PyGame. I've modified the >> standard VideoCapture.py file to make it simpler and easier to read. I've >> attached it as well as my program, main.py. >> >> VideoCapture.py defines a class Device. Device has two functions that I'm >> concerned with: .getBuffer(), which returns (string_data,width,height), and >> .getImage(), which returns a PIL image made with .getBuffer(). >> >> I'm trying to get a PyGame surface from all this. Every code sample I've >> seen converts the PIL image (returned from .getImage()) back into a string, >> and then makes a PyGame image with pygame.image.frombuffer(...): >> im = Camera.getImage() >> image = pygame.image.frombuffer(im.tostring(), im.size, im.mode) >> >> Though this works nicely, it seems terribly inefficient--VideoCapture.py >> takes the data as a string from .getBuffer(), and makes a PIL image. The >> main, main.py, must then change this PIL image back into a string again, and >> then make a PyGame surface from that. (Basically: >> STRING->PIL->STRING->PYGAME). This setup doesn't fly realtime. Moreover, >> it requires an extra dependency, PIL. >> >> So, I tried just converting the original string from .getBuffer() directly >> into a PyGame surface. (Basically: STRING->PYGAME): >> data = Camera.getBuffer() >> image = pygame.image.frombuffer(data[0],(data[1],data[2]),"RGB") >> >> But this has problems. It doesn't crash, but the image is upsidedown and >> the red and blue color channels appear to be flopped. I tried fixing it >> with surfarray, which didn't work. Then I tried finding what was wrong, and >> got inconsistent results. >> >> How can I get the second method (method 2: STRING->PYGAME) to look like the >> first method (method 1: STRING->PIL->STRING->PYGAME)? main.py lets you >> switch back and forth (press 1 for method 1, 2 for method 2). >> >> Ian >> >
Re: [pygame] vector type: mutable or immutable
I'm for immutable. I used numpy arrays as vectors for a while but had all kinds of bugs. I can't think of any use case for mutable vectors. In reference to sharing a mutable vector to syncronize objects, there are much better ways to do that. What happens if each object's update method changes pos? It just doesn't make sense. Also, for naming it would might be better to just have one object that can be multiple sizes. I attached a vector class that works like this pretty well. On Mon, May 4, 2009 at 7:27 PM, René Dudfield wrote: > On Tue, May 5, 2009 at 4:17 AM, Casey Duncan wrote: >> >> Just to clarify my position, performance is a secondary concern, primarily >> I'm concerned about intuitiveness and convenience. I suspect an immutable >> vector type will cause a regular amount of mail traffic asking how to mutate >> them and why that is not possible. I could be wrong, but I think many folks >> will be surprised by an immutable vector class. >> >> I'm +0 on immutable vectors, they're certainly much better than nothing, >> but I personally would prefer mutable. >> >> To make immutable types more performant, you should look at the >> implementation of tuples in Python. tuple instances are pooled so they can >> be recycled, saving a lot of memory management overhead. I did a similar >> thing for vectors in Lepton with good results. >> >> -Casey > > +1 for memory pools. Memory is the main overhead for performance these > days. Anything to avoid a copy or a malloc/mmap, and to group areas of > memory together for reading. > > Mutable vectors fail the use cases: > - use Vector as a proxy for some values in a larger array. > eg, in numpy I can do reference_to_big_array = bigarray[1:3] > - consistency with Rect, list, numpy/Numeric arrays, python arrays. > > > Another use case is consistency with most other Vector types in CS. I think > most Vectors are mutable. > - allow people to use vectors like how they are used in most graphics > literature. > > > cu, > vector.py Description: Binary data
Re: [pygame] A* module using surfaces for walkability data
> I guess in pygame.pathfinding ? It'd probably be part of the AI module. > I guess you'd want a way of determining which pixels are path, and > which are not. Either a color key, or color range. In a lot of maps, > there are multiple colors which are path... and multiple colors which > are blockers. I was thinking that you'd probably have a seperate surface just for pathfinding. This lets you have per-pixel attributes such as variable costs. > Often in a map, you have different tiles represented with different > colors. eg, (0,0,2) could be grass, so could (0,0,3), and (0,0,4) > could be sand. So the colors could be used for travel cost > optionally. I was thinking just the value would be the cost. 0 for unwalkable, 1 for easily walkable, 2 for harder ... and so on. > It doesn't look like you can pass in your own heuristic function? Is > this needed? Right now it uses the euclidean distance and precalculates all the costs to make it really fast. There definitely could be an option for a callback, but that would slow it down greatly. Perhaps different options like manhattan distance and multiples of both types of distances. > A future optimization might be to use it with the masks, as well as > surfaces. For 1 bit data, they can be a pretty quick way to do > things... since you've got 32 times less data to operate on. Sure, though I haven't worked with masks much. This restricts having costs per node though. > How could this be used with platformers, where you go left to right? > Where the AI can't fly, but they can jump. In the current state it can't be used for that, but I think it could be changed to work with some assumptions of the physics, like having the children of a node be up, left, and right if the node under the current one isn't walkable, and down-left, down-center, and down-right if the node under the current one is walkable. This doesn't take into account speed and acceleration however. For that you need a more than 2D search space (other dimensions are the speed) or some kind of hack. These expansions would need either special modes for the restrictions on children or optional callbacks. Maybe it would work to allow code to subclass the pathfinder and implement methods which would be used.
Re: [pygame] Re: weird problem with pygame.mouse.get_pos() and print
Then why'd he have that effect in the original message? On Thu, Mar 26, 2009 at 6:51 PM, Ian Mallett wrote: > On Thu, Mar 26, 2009 at 3:40 PM, Forrest Voight wrote: >> >> print pumps the queue? Why would it do that? > > It doesn't. pygame.event.get() empties the list, returning the events. > >
Re: [pygame] Re: weird problem with pygame.mouse.get_pos() and print
print pumps the queue? Why would it do that? On Fri, Mar 6, 2009 at 11:39 PM, Ian Mallett wrote: > Cool--yeah I'd recommend looking into events and event processing. > > As I understand it, when things happen (mouse moves, press button, etc.), > they're added to the event queue. If you don't retrieve values from the > event queue, then you'll only be dealing with the first value in the list. > > I find the following code useful for event handling: > > for event in pygame.event.get(): > if event.type == QUIT: > pygame.quit(); sys.exit() > if event.type == KEYDOWN and event.key == K_ESCAPE: > pygame.quit(); sys.exit() > > This will keep your event queue current and quit if you click the little "X" > or press ESCAPE. Notice that an event is only sent once, and so will not > continue to be in the queue on the next check (for example, you wouldn't > want to use code like this to move a character by holding a key down). If > you want continuous querying, check attributes, not events, like > pygame.mouse.get_pressed(), pygame.key.get_pressed(), etc. This is what you > were doing, but you left out the event processing, which is necessary in all > cases. > > This should get you started > Ian >
Re: [pygame] multi-width aalines and aacircles
One idea was to bind SDL_gfx ... there's a patch for a binding a few months back on this list. On Mon, Mar 23, 2009 at 12:41 PM, Thiago Chaves wrote: > I'd be very happy to see those too, specially because I've been doing > lots of drawing with primitives on SSoF. =D > > -Thiago > > On Mon, Mar 23, 2009 at 6:32 PM, pymike wrote: >> PyGame desperately needs multi-width aalines and aacircles. Are there any >> plans to implement these during GSoC or the next PyGame release? >> >> It'd really open up possibilities for pretty apps, vector art, and even SVG >> libraries. >> >> -- >> - pymike >> "Python eggs me on." >> >
Re: [pygame] Re: a gsoc idea: networking
You need a centralized server ... even if all it does is provide the addresses of several hosts. How else would you find even one host? On Thu, Mar 19, 2009 at 7:27 PM, Michael George wrote: > Tyler Laing wrote: >> >> Haha, point taken. Sorry about that. As a student, I think that one or >> the other would make a good project, as both would be too much work. >> >> -Tyler >> > > I totally agree. > > --Mike > >
Re: [pygame] Python - Pygame - PyOpenGL performance
That's called a texture atlas, but be careful with the mipmaps. They usually have to be generated specially I think. http://http.download.nvidia.com/developer/NVTextureSuite/Atlas_Tools/Texture_Atlas_Whitepaper.pdf On Mon, Mar 16, 2009 at 1:49 PM, Zack Schilling wrote: > If someone did this and I could drop it in to my code, that would be very > nice. But for right now, PyOpenGL is serving my needs just fine. I can use > about 600 independently textured and animated sprites onscreen, scaled and > rotated, without stressing a low-end system more than 40%. > > 40% is a significant amount of overhead, but Peter is wrong of a few points. > You certainly can animate a sprite in OpenGL using texture coords. Just load > all your animation frames, convert to strings, stick them all together, and > pass to OpenGL as one very tall texture. This works perfectly fine. That > means VBOs are definitely suitable. You can also push a VBO up piecemeal, > changing the active texture between parts (and achieving the expected > effect). > > Everything you see here is done with pygame and PyOpenGL: > http://www.youtube.com/watch?v=cBFoXqKrBa8 > > Positioning the quads directly doesn't seem to be too much of an issue, > since in my game, they move each frame anyway. The cost of adding > coordinates in Python and pushing them into a numpy array is much less than > an OpenGL push, translate/rotate, pop call for each and every sprite. It > makes a lot of sense to me that this would be the case in other languages as > well. > > -Zack > > On Mar 16, 2009, at 1:00 PM, Forrest Voight wrote: > >> Would writing a replacement for PyOpenGL in C instead of in Python >> with ctypes help? I think it really would ... PyOpenGL is internally >> pretty complex, sometimes when I get tracebacks the error is 5 or 6 >> levels into PyOpenGL. Even a C library that only implemented the >> common functions and relied on PyOpenGL for the constants and >> functions that do complex things like handling strings would probably >> help a lot. >> >> On Fri, Feb 27, 2009 at 11:19 AM, Peter Gebauer >> wrote: >>> >>> Hi! >>> >>> I've done a few sprite thingies in OpenGL here are some pointers: >>> >>> Afaik display lists and VBO's can't bind different textures (?) >>> per list/array. You can't animate lists by changing texcoords >>> independently per element, so no go. VBO's have texture coords, >>> but only one texture. Again, I'm no expert, might be wrong. >>> >>> With the quad aproach you should try >>> to make the number of calls as few as possible. If you get >>> rid of the push and translate for each sprite you'll get some >>> extra speed. Try positioning each quads directly. The downside >>> with sharing matrix over all sprites is the obvious lack of >>> using OpenGL transformations, but some vector math aplied to >>> the quads has been faster for me than having one transformed >>> matrix per quad. >>> >>> Since I haven't been able to animate a list/vbo with independent >>> textures and texture coords for each element/buffer object I've only >>> used it for backdrops. The speed increase is tremendous. >>> I also partition the elements so only one list/vbo is displayed per >>> visible section, if you're screen display is smaller than the >>> entire scene, this helps even more. >>> >>> If you put all your sprites and their animation frames into one >>> big texture you could use VBO's, but I've never had the tenacity >>> to try that aproach. >>> >>> Another way to increase speed is to write an opengl rendering engine >>> in C and call and make it available as a Python extension. This is >>> a major speed boost, in particular for a large number of iterations. >>> Iirc PyOpenGL bindings are generated, many times this is suboptimal >>> code for what you're trying to do, writing the Python extension in C >>> manually have been faster for me many times. This is indeed true >>> if you put your iterations inside a C loop instead of calling the >>> C function from Python many times. >>> >>> In any case, still waiting for that OO 2D game engine with tons of >>> OpenGL features and effects, including simple things like frame >>> animation, >>> LERP-like features and a simple 2D scenegraph. No luck yet, all attempts >>> I've tried so far lack at least one "must have" feature. :) >>> >>> /Peter >>> >>> On 2009
Re: [pygame] Python - Pygame - PyOpenGL performance
Would writing a replacement for PyOpenGL in C instead of in Python with ctypes help? I think it really would ... PyOpenGL is internally pretty complex, sometimes when I get tracebacks the error is 5 or 6 levels into PyOpenGL. Even a C library that only implemented the common functions and relied on PyOpenGL for the constants and functions that do complex things like handling strings would probably help a lot. On Fri, Feb 27, 2009 at 11:19 AM, Peter Gebauer wrote: > Hi! > > I've done a few sprite thingies in OpenGL here are some pointers: > > Afaik display lists and VBO's can't bind different textures (?) > per list/array. You can't animate lists by changing texcoords > independently per element, so no go. VBO's have texture coords, > but only one texture. Again, I'm no expert, might be wrong. > > With the quad aproach you should try > to make the number of calls as few as possible. If you get > rid of the push and translate for each sprite you'll get some > extra speed. Try positioning each quads directly. The downside > with sharing matrix over all sprites is the obvious lack of > using OpenGL transformations, but some vector math aplied to > the quads has been faster for me than having one transformed > matrix per quad. > > Since I haven't been able to animate a list/vbo with independent > textures and texture coords for each element/buffer object I've only > used it for backdrops. The speed increase is tremendous. > I also partition the elements so only one list/vbo is displayed per > visible section, if you're screen display is smaller than the > entire scene, this helps even more. > > If you put all your sprites and their animation frames into one > big texture you could use VBO's, but I've never had the tenacity > to try that aproach. > > Another way to increase speed is to write an opengl rendering engine > in C and call and make it available as a Python extension. This is > a major speed boost, in particular for a large number of iterations. > Iirc PyOpenGL bindings are generated, many times this is suboptimal > code for what you're trying to do, writing the Python extension in C > manually have been faster for me many times. This is indeed true > if you put your iterations inside a C loop instead of calling the > C function from Python many times. > > In any case, still waiting for that OO 2D game engine with tons of > OpenGL features and effects, including simple things like frame animation, > LERP-like features and a simple 2D scenegraph. No luck yet, all attempts > I've tried so far lack at least one "must have" feature. :) > > /Peter > > On 2009-02-26 (Thu) 11:29, Casey Duncan wrote: >> Immediate mode calls (glVertex et al) are the very slowest way to use >> OpenGL. In fact they are deprecated in OpenGL 3.0 and will eventually be >> removed. >> >> The display list is better as you discovered, but you still are making a >> few OpenGL state changes per sprite, which is likely slowing you down. >> Also there is some overhead for the display list call, which makes them >> sub-optimal for just drawing a single quad. >> >>> glPushMatrix() >>> glTranslate(self.positionx,self.positiony,0) >>> glCallList(self.displist) >>> glPopMatrix() >> >> You really need to batch the quads up into a few vertex arrays or vbos >> to stream them to the card in one go. pyglet has a high-level python >> sprite api that automates this for you fwiw. >> >> -Casey >> >> On Feb 26, 2009, at 11:04 AM, Zack Schilling wrote: >> >>> I know the PyOpenGL mailing list might be a better place to ask this >>> question, but I've had a lot of luck talking to the experienced people >>> here so I figured I'd try it first. >>> >>> I'm trying to migrate a game I created from using the Pygame / SDL >>> software rendering to OpenGL. Before attempting the massive and >>> complex conversion involved with moving the whole game, I decided to >>> make a little test program while I learned OpenGL. >>> >>> In this test, I set up OpenGL to work in 2D and began loading images >>> into texture objects and drawing textured quads as sprites. I created a >>> little glSprite class to handle the drawing and translation. At first >>> its draw routine looked like this: >>> >>> glPushMatrix() >>> glTranslate(self.positionx,self.positiony,0) >>> glBindTexture(GL_TEXTURE_2D, self.texture) >>> glBegin(GL_QUADS) >>> glTexCoord2f(0, 1) >>> glVertex2f(0, 0) >>> glTexCoord2f(1, 1) >>> glVertex2f(w, 0) >>> glTexCoord2f(1, 0) >>> glVertex2f(w, h) >>> glTexCoord2f(0, 0) >>> glVertex2f(0, h) >>> glEnd() >>> glPopMatrix() >>> >>> Note: self.texture is a texture ID of a loaded OpenGL texture object. >>> My sprite class keeps a dictionary cache and only loads the sprite's >>> image into a texture if it needs to. >>> >>> I'd get maybe 200 identical sprites (same texture) onscreen and my CPU >>> would hit 100% load from Python execution. I looked in
Re: [pygame] SDL_gfx integration
I think I was wrong ... I don't remember what I was thinking. :) Anyway, the next major version of pygame already has sdl_gfx integrated I think, so this might be moot. :( On Sun, Nov 9, 2008 at 5:57 AM, Lorenz Quack <[EMAIL PROTECTED]> wrote: > Hi Forrest, > > sorry for being silent so long. > Anyway, I don't think that my version creates a memory leak. And if it does > then so does the original version, IMHO. > The way I see it the PyArg_ParseTuple doesn't INCREF the refcount on any of > the parameters so there is no need to DECREF on either "points" nor its > content. > The only things that need to be DECREFed are the "x-/ylist" and the > individual "item" extracted from "points" via PySequence_GetItem which > returns a new Reference > according to the docs (http://docs.python.org/c-api/sequence.html) and I do > that if there is an error before returning the exception. > > If I'm missing something about the refcounting and I DO have a memory leak > then doesn't the same memory leak apply to the original implementation in > case the very first > point isn't a sequence of two ints (which is for some reason special-cased)? > > yours > //Lorenz > > > Forrest Voight wrote: >> If there's an error, points past the bad point aren't deref'd. >> >> On Thu, Oct 30, 2008 at 7:24 AM, <[EMAIL PROTECTED]> wrote: >>> Hi Forrest, >>> >>> could you tell me how exactly my version leaks and which variable is >>> leaking? I don't see it. >>> >>> I also think that vert/horiz lines could be dropped. >>> >>> //Lorenz >>> >>> >>> >>> On Mon, 27 Oct 2008 23:03:32 -0400, "Forrest Voight" <[EMAIL PROTECTED]> >>> wrote: >>>> Lorenz: the polygon function is almost a direct copy from draw.c and >>>> your way creates a memory leak if there is an error in a point past >>>> the first one. >>>> >>>> I think we should just remove the vert/horiz lines... just use line. >>>> >>>> On Mon, Oct 27, 2008 at 10:21 AM, James Hancock <[EMAIL PROTECTED]> >>>> wrote: >>>>> A year(or two) ago I found sdl-gfx when I was trying to find ways to get >>>>> anti-aliased circles( I worked on GASP, a beginners game creating api). >>>> My >>>>> understanding then was sdl-gfx was licensed GPL so pygame could not use >>>> it. >>>>> I just checked and now it is LGPL. Yay :) >>>>> >>>>> http://www.ferzkopp.net/joomla/content/view/19/14/ >>>>> >>>>> I talked with Andreas back than and it seemed like he was willing to >>>> help >>>>> the pygame community with integration and possible future work. His >>>> email is >>>>> on the site mentioned above. I would love to see pygame take advantage >>>> of >>>>> some of his work. Good luck, It looks like the ball is already started >>>> on >>>>> this one so lets keep moving forward >>>>> >>>>> Cheers! >>>>> James Hancock >>>>> >>>>> >>>>> >>>>> On Sun, Oct 26, 2008 at 4:34 PM, Lenard Lindstrom <[EMAIL PROTECTED]> >>>> wrote: >>>>>> Here are some more suggestions for the horizontal_line/vertical_line >>>>>> issue. Since they take integer positions I can think of two >>>> alternatives to >>>>>> "(surface, (x1, x2), y, color) and (surface, x, (y1, y2), color)". The >>>> first >>>>>> is to have no horizontal_line and vertical_line. Hide the the calls to >>>> the >>>>>> hlineRGBA and vlineRGBA gfx functions in the generic line function. A >>>> few >>>>>> extra tests to determine if a line is horizontal or vertical probably >>>> won't >>>>>> add much additional overhead to a Python function call. The other >>>>>> alternative is to use a start, length approach: (surface, (x1, y1), >>>> length, >>>>>> color). The length can be negative. This keeps the signature consistent >>>> for >>>>>> both the horizontal and vertical line functions. >>>>>> >>>>>> Lenard >>>>>> >>>>>> Lorenz Quack wrote: >>>>>>> Thanks a lot! >>>>>>> >>>>>>> I just looked through your patch and I have some remarks: >>>>>>> >>>>>>> >>>>>> [snip] >>>>>>> 2) you grouped the arguments to horizontal and vertical line like >>>> this: >>>>>>> (surface, (x1, x2), y, color) and (surface, x, (y1, y2), color) >>>>>>> respectively >>>>>>> I find this grouping not very intuitive. normally we group a pair of x >>>>>>> and y >>>>>>> coordinates which makes sense because they represent one point but I >>>>>>> can't see >>>>>>> such an interpretation here. one could argue to group them (surface, >>>> (x1, >>>>>>> y), >>>>>>> x2, color) but that looks strange as well so I would suggest to not >>>> group >>>>>>> them >>>>>>> at all >>>>>>> >>>>>>> >>>>>> [snip] >>>>>>> Forrest Voight wrote: >>>>>>> >>>>>>>> Hi! >>>>>>>> >>>>>>>> I'm posting the patch at http://im.forre.st/pygame-sdl_gfx.diff , so >>>>>>>> that won't happen again. >>>>>>>> >>>>>>>> It's pretty much a full binding of the shape drawing functions, but >>>>>>>> there's some other stuff in SDL_gfx. >>>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> Lenard Lindstrom >>>>>> <[EMAIL PROTECTED]> >>>>>> >>>>> >>> > >
Re: [pygame] SDL_gfx integration
If there's an error, points past the bad point aren't deref'd. On Thu, Oct 30, 2008 at 7:24 AM, <[EMAIL PROTECTED]> wrote: > > Hi Forrest, > > could you tell me how exactly my version leaks and which variable is leaking? > I don't see it. > > I also think that vert/horiz lines could be dropped. > > //Lorenz > > > > On Mon, 27 Oct 2008 23:03:32 -0400, "Forrest Voight" <[EMAIL PROTECTED]> > wrote: >> Lorenz: the polygon function is almost a direct copy from draw.c and >> your way creates a memory leak if there is an error in a point past >> the first one. >> >> I think we should just remove the vert/horiz lines... just use line. >> >> On Mon, Oct 27, 2008 at 10:21 AM, James Hancock <[EMAIL PROTECTED]> >> wrote: >>> A year(or two) ago I found sdl-gfx when I was trying to find ways to get >>> anti-aliased circles( I worked on GASP, a beginners game creating api). >> My >>> understanding then was sdl-gfx was licensed GPL so pygame could not use >> it. >>> I just checked and now it is LGPL. Yay :) >>> >>> http://www.ferzkopp.net/joomla/content/view/19/14/ >>> >>> I talked with Andreas back than and it seemed like he was willing to >> help >>> the pygame community with integration and possible future work. His >> email is >>> on the site mentioned above. I would love to see pygame take advantage >> of >>> some of his work. Good luck, It looks like the ball is already started >> on >>> this one so lets keep moving forward >>> >>> Cheers! >>> James Hancock >>> >>> >>> >>> On Sun, Oct 26, 2008 at 4:34 PM, Lenard Lindstrom <[EMAIL PROTECTED]> >> wrote: >>>> >>>> Here are some more suggestions for the horizontal_line/vertical_line >>>> issue. Since they take integer positions I can think of two >> alternatives to >>>> "(surface, (x1, x2), y, color) and (surface, x, (y1, y2), color)". The >> first >>>> is to have no horizontal_line and vertical_line. Hide the the calls to >> the >>>> hlineRGBA and vlineRGBA gfx functions in the generic line function. A >> few >>>> extra tests to determine if a line is horizontal or vertical probably >> won't >>>> add much additional overhead to a Python function call. The other >>>> alternative is to use a start, length approach: (surface, (x1, y1), >> length, >>>> color). The length can be negative. This keeps the signature consistent >> for >>>> both the horizontal and vertical line functions. >>>> >>>> Lenard >>>> >>>> Lorenz Quack wrote: >>>>> >>>>> Thanks a lot! >>>>> >>>>> I just looked through your patch and I have some remarks: >>>>> >>>>> >>>> >>>> [snip] >>>>> >>>>> 2) you grouped the arguments to horizontal and vertical line like >> this: >>>>> (surface, (x1, x2), y, color) and (surface, x, (y1, y2), color) >>>>> respectively >>>>> I find this grouping not very intuitive. normally we group a pair of x >>>>> and y >>>>> coordinates which makes sense because they represent one point but I >>>>> can't see >>>>> such an interpretation here. one could argue to group them (surface, >> (x1, >>>>> y), >>>>> x2, color) but that looks strange as well so I would suggest to not >> group >>>>> them >>>>> at all >>>>> >>>>> >>>> >>>> [snip] >>>>> >>>>> Forrest Voight wrote: >>>>> >>>>>> >>>>>> Hi! >>>>>> >>>>>> I'm posting the patch at http://im.forre.st/pygame-sdl_gfx.diff , so >>>>>> that won't happen again. >>>>>> >>>>>> It's pretty much a full binding of the shape drawing functions, but >>>>>> there's some other stuff in SDL_gfx. >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Lenard Lindstrom >>>> <[EMAIL PROTECTED]> >>>> >>> >>> > >
Re: [pygame] Patch - Re-add music support for file-like objects
I realised today that the docs say: "Music can only be loaded from filenames, not python file objects like the other pygame loading functions." So here's a patch to correct the docs. On Tue, Jul 22, 2008 at 7:38 AM, René Dudfield <[EMAIL PROTECTED]> wrote: > cool, thanks! > > Committed revision 1524. > > cu, > > On Mon, Jul 21, 2008 at 12:26 PM, Forrest Voight <[EMAIL PROTECTED]> wrote: >> Fixed both Brian and I's deadlocking problem. >> >> Biran's program works all the way up to the last music (house_lo.mp3) >> which has an odd header (SDL_mixer's fault, patch send in.) >> >> The ogg get_busy() problem is SDL_mixer's fault. >> pygame.mixer.music.get_busy() directly calls SDL_mixer. >> >> On Sun, Jul 20, 2008 at 9:55 PM, Forrest Voight <[EMAIL PROTECTED]> wrote: >>> For the deadlock on reloading a sound, I'm working on it, I earlier >>> discovered the problem (threaded rwops deadlocks on exception in >>> file-like due to bug). >>> >>> For the mp3 not loading, it is another magic problem. It is not an ID3 >>> tag but some other weird header not caught. >>> >>> The MID file doesn't play when loading it normally, right? I'm not >>> sure what the problem is here, but it works for me and Lenard. >>> >>> Lenard, I'll look into the ogg problem. >>> >>> On Sun, Jul 20, 2008 at 7:50 PM, René Dudfield <[EMAIL PROTECTED]> wrote: >>>> hi, >>>> >>>> nice testing :) >>>> >>>> I think this will have to be ifdef'd out for 1.8.1, unless someone can >>>> fix it in the next couple of days. >>>> >>>> cu, >>>> >>>> >>>> On Mon, Jul 21, 2008 at 4:26 AM, Brian Fisher <[EMAIL PROTECTED]> wrote: >>>>> I got some time to play with this more, testing both on my Vista machine >>>>> and >>>>> OS X 10.5. >>>>> >>>>> with SDL_Mixer 1.2.8, ogg and mp3 and mid and mod all seem to be able to >>>>> load from a file or file-like object on my windows machine, so I think >>>>> Forrest is right about the level of support in SDL_Mixer 1.2.8 >>>>> >>>>> ...but there were a few of issues... >>>>> >>>>> 1. if I try to call mixer.music.load again after having tried to play a >>>>> song >>>>> from a file or file-like object, it hangs on the loading >>>>> 2. the pygame examples/data/house_lo.mp3 plays silence when I try to play >>>>> it >>>>> from a filename, but loading from a file or file-like object I get an >>>>> exception of unrecognized file type (which must be the ID3 tag thing >>>>> Forrest >>>>> called out earlier?) >>>>> 3. the mid file claims to load but plays nothing, regardless of how I load >>>>> it >>>>> >>>>> 2 and 3 may be issues with the file, and are not likely to be problem's >>>>> with >>>>> loading from rw_objects at all, but issue 1 (hanging on trying to load a >>>>> different piece of music after loading from a file-like object) seems >>>>> like a >>>>> serious problem that is the responsibility of the loading from rwobject >>>>> code >>>>> to fix. >>>>> >>>>> I have no idea what the cause of it is - from the prints for a file-like >>>>> object loader, it seems to do the exact same sequence of seek, tell and >>>>> read >>>>> as when it doesn't hang, except that the load call simply doesn't return. >>>>> I >>>>> had to rebuild pygame with the mixer version check changed of course, but >>>>> It >>>>> happens for both my Leopard and Vista machines, so I don't think it's >>>>> anything about my builds in particular. >>>>> >>>>> here's the code I was running (with Forrest's sound files and the files >>>>> from >>>>> pygame) >>>>> - >>>>> import pygame >>>>> import time >>>>> >>>>> pygame.init() >>>>> pygame.display.set_mode((320,200)) >>>>> pygame.event.pump() >>>>> files = ["sound.ogg", "sound.mp3", "sound.mod", "sound.mid", >>>>>
Re: [pygame] SDL_gfx integration
Lorenz: the polygon function is almost a direct copy from draw.c and your way creates a memory leak if there is an error in a point past the first one. I think we should just remove the vert/horiz lines... just use line. On Mon, Oct 27, 2008 at 10:21 AM, James Hancock <[EMAIL PROTECTED]> wrote: > A year(or two) ago I found sdl-gfx when I was trying to find ways to get > anti-aliased circles( I worked on GASP, a beginners game creating api). My > understanding then was sdl-gfx was licensed GPL so pygame could not use it. > I just checked and now it is LGPL. Yay :) > > http://www.ferzkopp.net/joomla/content/view/19/14/ > > I talked with Andreas back than and it seemed like he was willing to help > the pygame community with integration and possible future work. His email is > on the site mentioned above. I would love to see pygame take advantage of > some of his work. Good luck, It looks like the ball is already started on > this one so lets keep moving forward > > Cheers! > James Hancock > > > > On Sun, Oct 26, 2008 at 4:34 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote: >> >> Here are some more suggestions for the horizontal_line/vertical_line >> issue. Since they take integer positions I can think of two alternatives to >> "(surface, (x1, x2), y, color) and (surface, x, (y1, y2), color)". The first >> is to have no horizontal_line and vertical_line. Hide the the calls to the >> hlineRGBA and vlineRGBA gfx functions in the generic line function. A few >> extra tests to determine if a line is horizontal or vertical probably won't >> add much additional overhead to a Python function call. The other >> alternative is to use a start, length approach: (surface, (x1, y1), length, >> color). The length can be negative. This keeps the signature consistent for >> both the horizontal and vertical line functions. >> >> Lenard >> >> Lorenz Quack wrote: >>> >>> Thanks a lot! >>> >>> I just looked through your patch and I have some remarks: >>> >>> >> >> [snip] >>> >>> 2) you grouped the arguments to horizontal and vertical line like this: >>> (surface, (x1, x2), y, color) and (surface, x, (y1, y2), color) >>> respectively >>> I find this grouping not very intuitive. normally we group a pair of x >>> and y >>> coordinates which makes sense because they represent one point but I >>> can't see >>> such an interpretation here. one could argue to group them (surface, (x1, >>> y), >>> x2, color) but that looks strange as well so I would suggest to not group >>> them >>> at all >>> >>> >> >> [snip] >>> >>> Forrest Voight wrote: >>> >>>> >>>> Hi! >>>> >>>> I'm posting the patch at http://im.forre.st/pygame-sdl_gfx.diff , so >>>> that won't happen again. >>>> >>>> It's pretty much a full binding of the shape drawing functions, but >>>> there's some other stuff in SDL_gfx. >>>> >>>> >>> >> >> >> -- >> Lenard Lindstrom >> <[EMAIL PROTECTED]> >> > >
Re: [pygame] SDL_gfx integration
Hi! I'm posting the patch at http://im.forre.st/pygame-sdl_gfx.diff , so that won't happen again. It's pretty much a full binding of the shape drawing functions, but there's some other stuff in SDL_gfx. I think there is some kind of licensing problem, I'm not sure. There was talk about putting it into the pygame tree, or making it a requirement. Making it optional isn't really an option. Also, it would probably be combined into the draw module instead of being in its own module. On Sat, Oct 25, 2008 at 6:00 AM, Lorenz Quack <[EMAIL PROTECTED]> wrote: > Hi pygamers, > > I was reading the mailinglist archive the other day and found two threads ([1] > and [2]) about integrating SDL_gfx into pygame. > > So my questions are: > 1) Is someone still working on this? > 2) How far are you with your efforts? > 3) Is there a place I could take a look at the progress like a svn branch? > 4) Is there anyway I can help out with this? > > sincerely yours > //Lorenz > > PS: unfortunately the patch isn't preserved in the gmane archive so I can't > even look at that :( > > > [1] http://thread.gmane.org/gmane.comp.python.pygame/14790/ > [2] http://thread.gmane.org/gmane.comp.python.pygame/15846/ >
Re: [pygame] pygame on iPhone
It seems the NDA was dropped, just a little while ago, FYI. On Fri, Oct 3, 2008 at 7:22 AM, Greg Ewing <[EMAIL PROTECTED]> wrote: > Jack Nutting wrote: > >> However, the fact is that what you *can* write with, Objective-C, is >> not too shabby at all. > > You can write it, and maybe run it on your own phone, > but nobody else can run it unless you go begging to > Apple for approval (and pay them for the privilege). > Or unless they're willing to hack their phone and > risk the ire of Apple and/or AT&T. > >> So far, Apple's position on the iPhone has been a continual >> loosening/expansion of what is possible... I am pretty hopeful >> about the prospects of Apple removing the onerous clause that rules >> out language interpreters in the iPhone. > > That would help, but to become truly enlightened, > they'll have to abandon all attempt to restrict what > people can run. It's that fundamental attitude that > disappoints me more than the details of the restrictions. > > I rather like Google's "Don't be evil" motto, and wish > Apple would take it to heart as well. > > -- > Greg > >
Re: [pygame] surfarray.pixels3d() bug?
You're probably doing something wrong. It helps a lot to post code samples. :) On Tue, Sep 30, 2008 at 3:18 PM, Mark S <[EMAIL PROTECTED]> wrote: > Hi all, > > I am trying to use surfarray.pixels3d() to copy a surface to an array but it > doesn't seem to be working properly. If I call that function and then blit > the array right back to the surface (after first clearing it) what is > produced is a 90 degree rotation of the original image that is repeated a > few times with a vertical offset. Also, the array generated image is > missing periodic vertical strips of the original image. > > If I do the exact same thing with surfarray.pixels2d() it works perfectly. > > I'm wondering if there is something wrong with the 3d function or if I'm > actually doing something wrong. > > Thanks a lot, > > mark
[pygame] Proposal - Improved Version Checks
Version checks like this are very bad: #if MIX_MAJOR_VERSION>=1 && MIX_MINOR_VERSION>=2 && MIX_PATCHLEVEL>=3 (line 98 src/music.c) This is a proposal to fix them. They would be changed to something like this: #if MIX_VERSION_ATLEAST(1, 2, 3) All that needs to be done to implement this is to add this to pygame.h. #ifndef MIX_COMPILEDVERSION #define MIX_COMPILEDVERSION SDL_VERSIONNUM(MIX_MAJOR_VERSION, MIX_MINOR_VERSION, MIX_PATCHLEVEL) #endif #ifndef MIX_VERSION_ATLEAST #define MIX_VERSION_ATLEAST(X, Y, Z) (MIX_COMPILEDVERSION >= SDL_VERSIONNUM(X, Y, Z)) #endif
Re: [pygame] pygame web plugin
> also, i frogot to suggest that we build ClamAV into PWS for virus scanning of > the python program Umm... I'm really not sure how to respond to this.
Re: [pygame] pygame web plugin
PyGame isn't really built for untrusted code... there are many ways to crash PyGame if you are intent on it... PyGame and Python weren't meant at all for web apps. On Mon, Sep 8, 2008 at 2:22 AM, Bob Ippolito <[EMAIL PROTECTED]> wrote: > On Sun, Sep 7, 2008 at 1:56 PM, Ron Dippold <[EMAIL PROTECTED]> wrote: >> This is something Java actually does pretty well. I dislike it for the most >> part, but its sandboxing is better than anything I've ever seen (except >> certain secure OSes). Flash actually does it pretty well now too, though >> holes keep turning up occasionally. Interestingly, unless they've changed >> Flash or Java recently, I don't think there's anything that limits the >> amount of cpu or memory usage since I still see one occasionally running off >> into the weeds. The solution is just 'fix or don't run that jar/swf'. > > The memory usage is unbounded IIRC but the CPU usage is bounded, at > least insofar as it will do a pop-up warning and allow the user to > stop code execution if the code doesn't yield to the main event loop > often enough. You can get around that by burning through lots of CPU > incrementally with a timer, if you were intentionally trying to be > annoying. > > -bob >
Re: [pygame] problem - movie in pygame
I think PyGame could use a new movie module... a binding of libavcodec probably. For one of my games, I gave up and decided to write my own video codec in Cython instead of messing with PyMedia. On Wed, Sep 3, 2008 at 8:16 PM, bhaaluu <[EMAIL PROTECTED]> wrote: > I run a Debian GNU/Linux system, Python 2.4.4 and PyGame 1.7. > > I use this script to play movies. Maybe you can modify it for your game? > > #!/usr/bin/python > """Usage: python playMovie.py movie.mpg > 'q' = Quit > """ > import pygame > from pygame.locals import * > > def main(filepath): > pygame.init() > pygame.mixer.quit() > movie = pygame.movie.Movie(filepath) > screen = pygame.display.set_mode(movie.get_size()) > movie.set_display(screen) > > pygame.event.set_allowed((QUIT, KEYDOWN)) > movie.play() > while movie.get_busy(): > evt = pygame.event.wait() > if evt.type == QUIT: > break > if evt.type == KEYDOWN and evt.unicode == u'q': > break > if movie.get_busy(): > movie.stop() > > if __name__ == '__main__': > import sys > main(sys.argv[1]) > > Hopefully helpful, > -- > b h a a l u u at g m a i l dot c o m > Kid on Bus: What are you gonna do today, Napoleon? > Napoleon Dynamite: Whatever I feel like I wanna do. Gosh! > > On Wed, Sep 3, 2008 at 11:40 AM, pesvieira <[EMAIL PROTECTED]> wrote: >> Hi. >> >> I'm wanting to play a movie when I start my game, but I'm having a >> problem at playing a video in pygame. I already used pygame.movie and >> pymedia to do that, but they didn't work. >> >> The pygame.movie only supports MPEG1 encode, and the video is being >> displayed with low quality. >> >> Using pymedia the problem is when I use the player.py module. The >> video and audio aren't in sync. I tried to limit the FPS for that the >> images don't be displayed too quickly, but I didn't find how to do >> this in pymedia. >> >> Somebody knows how to solve this problem? Or, Is there any another >> libary to play a movie in python? >> >> >> Thanks. >> >
Re: SDL_gfx todo. Re: [pygame] Transparency and pygame.draw
>>> - include SDL_gfx in a pygame sub directory, and make the pygame build system build SDL_gfx. What did you mean by that? Also, would SDL_gfx be a dependency or optional? It will probably be optional, so maybe a separate module would make more sense... On Tue, Aug 26, 2008 at 10:24 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > On Wed, Aug 27, 2008 at 12:16 PM, Forrest Voight <[EMAIL PROTECTED]> wrote: >> Thanks, I'll help with that soon... >> > > cool. > >> You're planning on including the SDL_gfx codebase in pygame? Don't the >> licenses conflict? > > No. Why do you say that? > >> >> I agree it should be combined with pygame.draw though. This was just a >> demonstration. > > > cu, >
Re: SDL_gfx todo. Re: [pygame] Transparency and pygame.draw
Thanks, I'll help with that soon... You're planning on including the SDL_gfx codebase in pygame? Don't the licenses conflict? I agree it should be combined with pygame.draw though. This was just a demonstration. On Tue, Aug 26, 2008 at 8:25 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > hi, > > ah, nice one. I missed this patch. > > So the todo list for this would be: > > - unit tests for all of these functions. > - include SDL_gfx in a pygame sub directory, and make the pygame build > system build SDL_gfx. > - implement pygame.draw using the gfx module. > - any bugfixes in the pygame draw/transform code should go into gfx module. > - a review by other developers of code, and docs. > > > cheers, > > > > On Tue, Aug 19, 2008 at 2:08 PM, Forrest Voight <[EMAIL PROTECTED]> wrote: >> I might have written the patch he was talking about... It's attached. >> >> On Mon, Aug 18, 2008 at 6:26 PM, Luca <[EMAIL PROTECTED]> wrote: >>> Maybe... I find this with google (but I don't find the patch Noah was >>> talink about...) >>> >>> http://www.pygame.org/wiki/gsoc2008ideas#Better%20drawing%20primitives >>> >>> On Mon, Aug 18, 2008 at 11:43 PM, PyMike <[EMAIL PROTECTED]> wrote: >>>> Will SDL_gfx ever be actually included in pygame? >>>> >>>> On Mon, Aug 18, 2008 at 11:38 AM, Noah Kantrowitz <[EMAIL PROTECTED]> >>>> wrote: >>>>> >>>>> No, but someone made bindings for SDL_gfx which does allow for this (and a >>>>> lot more). Check the list archives. >>>>> >>>>> --Noah >>>>> >>>>> > -Original Message- >>>>> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >>>>> > On Behalf Of Luca >>>>> > Sent: Monday, August 18, 2008 5:28 AM >>>>> > To: pygame-users@seul.org >>>>> > Subject: [pygame] Transparency and pygame.draw >>>>> > >>>>> > Hi all. >>>>> > >>>>> > Is possible to get transparency using primitive pygame.draw functions? >>>>> > >>>>> > For me something like... >>>>> > pygame.draw.ellipse(screen, (0, 127, 0, 140), (300, 150, 80, 40), 0) >>>>> > ... where the color is given with a rgb+alpha value, simply doesn't >>>>> > work. >>>>> > >>>>> > -- >>>>> > -- luca >>>>> >>>> >>>> >>>> >>>> -- >>>> - pymike (http://pymike.4rensics.org/) >>>> >>> >>> >>> >>> -- >>> -- luca >>> >> >
Re: [pygame] The Giant - 'cool project I'm working on now' - thread.
Opencraft, a Starcraft clone. http://forre.st/opencraft Still pretty simple, but all of the graphics are done. Just lots of logic and networking left :( On Fri, Aug 8, 2008 at 12:27 PM, Dan Krol <[EMAIL PROTECTED]> wrote: > My friends commissioned me to write a 2D engine for a platforming game > they were making (called Singe). They wanted to be able to script it. > I decided I wanted to make it as unbound as possible, so it could be > used for any game in the future. As it turns out, they don't have > their stuff together yet, but I've made a little progress on this > Engine. I intend to have Actors, Message Passing, Visual Effects > (programmed in C), Scripting, Panning, and a level editor. I was > originally going to use SDL and just have Python for scripting, then I > decided to use Pygame to prototype the whole thing, then I decided I > liked Pygame :) so I'm sticking with it until it turns out to be too > slow for some reason. I can always optimize parts with C meanwhile. > > Anyway, it's still pretty primitive, I don't have panning yet, but I > do have Actors, Scripting, and Message Passing. I decided to make a > game along with the engine, just to test out its capabilities and make > sure it was working properly. I chose a funny game idea I already had > sitting around. This game is certainly not the sort of game the engine > will ultimately be tailored for, but it works for now. > > I present to you: Differential Equation Munchers > > http://orblivion.specialkevin.com/projects/diffEqMunchers/ > > If you played Number Munchers as a kid, you should get the joke. This > game has some things to be filled in, as you may see, but it does work > from start to finish. > > On 8/8/08, Michael George <[EMAIL PROTECTED]> wrote: >> It's still somewhat on the back burner, but I've been working on a >> library to allow you to drag and drop irregularly shaped objects (esp. >> circles and polygons) while preventing interpenetration. It's a >> surprisingly hard problem and I'm reading a lot of computational >> geometry papers to find an algorithm to solve it. >> >> This is a subproject/distraction from my game, PEN (puzzles from the >> engineer's notebook) which was loosely inspired by the incredible >> machine: http://sourceforge.net/projects/pen/. You can see a buggy, >> circles-only version of the dragging problem in the code there if you're >> curious. I'm hoping a library would be something useful to other game >> designers. What do you think? >> >> --Mike >> >
Re: [pygame] Old pygame tutorial not working
Here is a decorator that speeds up a function using screen lists: def screen_list(func): func.sl = None def x(): if not func.sl: func.sl = glGenLists(1) glNewList(func.sl, GL_COMPILE) func() glEndList() glCallList(func.sl) return x On Mon, Aug 4, 2008 at 4:15 PM, Ian Mallett <[EMAIL PROTECTED]> wrote: > On Mon, Aug 4, 2008 at 12:48 PM, Casey Duncan <[EMAIL PROTECTED]> wrote: >> >> What type of interpolation? Linear interpolation between points would >> require no extra vertices. > > That was what I was doing at the outset, but it gives the "stepping" effect. >> >> You may need to implement some sort of variable LOD to get acceptable >> performance (farther things approximated using far fewer vertices). > > That's easier said than done, but I agree that that would be a good idea. >> >> You may also be able to achieve much better performance by reducing the >> detail expressed via vertices and using a normal map instead. You could also >> use normal mapping to simulate fancy non-linear interpolation between >> vertices without more polygons. > > I know the basic theory of normal mapping, but not how to actually do it. I > had considered that though. >> >> How is the display list being built? You can optimize this much like other >> OpenGL drawing, using fewer calls is always better, but doubly so from >> Python. So try to use things like vertex arrays instead of immediate mode >> calls, etc. > > Vertex arrays aren't widely supported, but VBOs are. I can do vertex > arrays, but not vertex buffer objects. Thus, the map is being made from > quad or triangle strips (can't remember which). >> >> I assume that by "passing pointers" you really mean copying/transforming >> data. Just passing an array pointer back and forth has basically no cost, so >> try and arrange your data structures so that they don't need to be >> transformed to be used by different parts of the program, and in particular >> steer clear of doing those types of transforms in Python code wherever >> possible. > > Right, that is what I'm doing externally. The height data is precalculated > as opengl units, then stored in a separate module. When I run the game, > this module is used by Objects.py (which makes the landscape from the > data--the only data processed before the game runs) and the main, which then > uses it as collision detection. > > Presently, this making of the landscape takes some time. Certainly, not as > much as making the heightdata on the fly would be, but still some time. > Currently, I'm not making/using any normal data, but when I do, it will be > slower still. That is why the landscape loader must be in C. By > transferring data, I mean sending heightmap data (from the premade .py file) > to C, then getting the display list back. > > Ian >
Re: [pygame] No pygame.mixer.Sound.get_current()?
There is no function that does this, but if there was it would be in pygame.mixer.Channel. Sounds are immutable. They each just the data of the sound. Also, pygame.mixer.music has functions for getting the position and seeking. On Tue, Jul 29, 2008 at 10:51 PM, Tyler Distad <[EMAIL PROTECTED]> wrote: > There is no function in pygame.mixer.Sound to return the current > position in the track. A get_length() function is available, so I > would assume that a get_current() position would be a simple addition. > > Of course, I could be wrong. I looked at the code to see about adding > it, but in a few minutes of looking, was unable to easily find a > position marker. > > Tyler Distad >
Re: [pygame] problem - out of frequency
You can't change the frequency, but that should not be even related to pygame. What kind of problem are you having? Changing the frequency is not going to help (unless it is something weird like aliasing). On Tue, Jul 22, 2008 at 11:50 AM, pesvieira <[EMAIL PROTECTED]> wrote: > Hi. > > I have a problem with my pygame project because of the frequency of > the monitor. How do I change the refresh rate in fullscreen mode? > > > Thanks. >
Re: [pygame] Patch - Re-add music support for file-like objects
Fixed both Brian and I's deadlocking problem. Biran's program works all the way up to the last music (house_lo.mp3) which has an odd header (SDL_mixer's fault, patch send in.) The ogg get_busy() problem is SDL_mixer's fault. pygame.mixer.music.get_busy() directly calls SDL_mixer. On Sun, Jul 20, 2008 at 9:55 PM, Forrest Voight <[EMAIL PROTECTED]> wrote: > For the deadlock on reloading a sound, I'm working on it, I earlier > discovered the problem (threaded rwops deadlocks on exception in > file-like due to bug). > > For the mp3 not loading, it is another magic problem. It is not an ID3 > tag but some other weird header not caught. > > The MID file doesn't play when loading it normally, right? I'm not > sure what the problem is here, but it works for me and Lenard. > > Lenard, I'll look into the ogg problem. > > On Sun, Jul 20, 2008 at 7:50 PM, René Dudfield <[EMAIL PROTECTED]> wrote: >> hi, >> >> nice testing :) >> >> I think this will have to be ifdef'd out for 1.8.1, unless someone can >> fix it in the next couple of days. >> >> cu, >> >> >> On Mon, Jul 21, 2008 at 4:26 AM, Brian Fisher <[EMAIL PROTECTED]> wrote: >>> I got some time to play with this more, testing both on my Vista machine and >>> OS X 10.5. >>> >>> with SDL_Mixer 1.2.8, ogg and mp3 and mid and mod all seem to be able to >>> load from a file or file-like object on my windows machine, so I think >>> Forrest is right about the level of support in SDL_Mixer 1.2.8 >>> >>> ...but there were a few of issues... >>> >>> 1. if I try to call mixer.music.load again after having tried to play a song >>> from a file or file-like object, it hangs on the loading >>> 2. the pygame examples/data/house_lo.mp3 plays silence when I try to play it >>> from a filename, but loading from a file or file-like object I get an >>> exception of unrecognized file type (which must be the ID3 tag thing Forrest >>> called out earlier?) >>> 3. the mid file claims to load but plays nothing, regardless of how I load >>> it >>> >>> 2 and 3 may be issues with the file, and are not likely to be problem's with >>> loading from rw_objects at all, but issue 1 (hanging on trying to load a >>> different piece of music after loading from a file-like object) seems like a >>> serious problem that is the responsibility of the loading from rwobject code >>> to fix. >>> >>> I have no idea what the cause of it is - from the prints for a file-like >>> object loader, it seems to do the exact same sequence of seek, tell and read >>> as when it doesn't hang, except that the load call simply doesn't return. I >>> had to rebuild pygame with the mixer version check changed of course, but It >>> happens for both my Leopard and Vista machines, so I don't think it's >>> anything about my builds in particular. >>> >>> here's the code I was running (with Forrest's sound files and the files from >>> pygame) >>> - >>> import pygame >>> import time >>> >>> pygame.init() >>> pygame.display.set_mode((320,200)) >>> pygame.event.pump() >>> files = ["sound.ogg", "sound.mp3", "sound.mod", "sound.mid", "house_lo.ogg", >>> "house_lo.mp3"] >>> >>> class file_like_wrapper(): >>> def __init__(self, fname): >>> self.my_fname = fname >>> self.my_file = file(fname, "rb") >>> >>> def read(self, size=None): >>> print self.my_fname,"read", size >>> if size != None: >>> return self.my_file.read(size) >>> else: >>> return self.my_file.read() >>> >>> def seek(self, offset, whence): >>> print self.my_fname,"seek",offset, whence >>> return self.my_file.seek(offset, whence) >>> >>> def tell(self): >>> tell_pos = self.my_file.tell() >>> print self.my_fname,"tell", tell_pos >>> return tell_pos >>> >>> def close(self): >>> print self.my_fname,"close" >>> return self.my_file.close() >>> >>> for filename in files: >>> print "loading",filename,"..." >>> >>> print "from filename", >>> sound = pygame.mixer.music.load(filename) >>> print "loaded!" >>> pygame.mixer.music.play() >>> print "playing!" >>> time.sleep(3) >>> pygame.event.pump() >>> pygame.mixer.music.stop() >>> >>> print "loading from file-like object", >>> sound = pygame.mixer.music.load(file_like_wrapper(filename)) >>> print "loaded!" >>> pygame.mixer.music.play() >>> print "playing!" >>> time.sleep(3) >>> pygame.event.pump() >>> print "done playing!" >>> pygame.mixer.music.stop() >>> >>> print "loading from file object", >>> sound = pygame.mixer.music.load(file(filename, "rb")) >>> print "loaded!" >>> pygame.mixer.music.play() >>> print "playing!" >>> time.sleep(3) >>> pygame.event.pump() >>> print "done playing!" >>> pygame.mixer.music.stop() >>> >>> >>> >> > music_fixed_reload.diff Description: Binary data
Re: [pygame] Patch - Re-add music support for file-like objects
For the deadlock on reloading a sound, I'm working on it, I earlier discovered the problem (threaded rwops deadlocks on exception in file-like due to bug). For the mp3 not loading, it is another magic problem. It is not an ID3 tag but some other weird header not caught. The MID file doesn't play when loading it normally, right? I'm not sure what the problem is here, but it works for me and Lenard. Lenard, I'll look into the ogg problem. On Sun, Jul 20, 2008 at 7:50 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > hi, > > nice testing :) > > I think this will have to be ifdef'd out for 1.8.1, unless someone can > fix it in the next couple of days. > > cu, > > > On Mon, Jul 21, 2008 at 4:26 AM, Brian Fisher <[EMAIL PROTECTED]> wrote: >> I got some time to play with this more, testing both on my Vista machine and >> OS X 10.5. >> >> with SDL_Mixer 1.2.8, ogg and mp3 and mid and mod all seem to be able to >> load from a file or file-like object on my windows machine, so I think >> Forrest is right about the level of support in SDL_Mixer 1.2.8 >> >> ...but there were a few of issues... >> >> 1. if I try to call mixer.music.load again after having tried to play a song >> from a file or file-like object, it hangs on the loading >> 2. the pygame examples/data/house_lo.mp3 plays silence when I try to play it >> from a filename, but loading from a file or file-like object I get an >> exception of unrecognized file type (which must be the ID3 tag thing Forrest >> called out earlier?) >> 3. the mid file claims to load but plays nothing, regardless of how I load >> it >> >> 2 and 3 may be issues with the file, and are not likely to be problem's with >> loading from rw_objects at all, but issue 1 (hanging on trying to load a >> different piece of music after loading from a file-like object) seems like a >> serious problem that is the responsibility of the loading from rwobject code >> to fix. >> >> I have no idea what the cause of it is - from the prints for a file-like >> object loader, it seems to do the exact same sequence of seek, tell and read >> as when it doesn't hang, except that the load call simply doesn't return. I >> had to rebuild pygame with the mixer version check changed of course, but It >> happens for both my Leopard and Vista machines, so I don't think it's >> anything about my builds in particular. >> >> here's the code I was running (with Forrest's sound files and the files from >> pygame) >> - >> import pygame >> import time >> >> pygame.init() >> pygame.display.set_mode((320,200)) >> pygame.event.pump() >> files = ["sound.ogg", "sound.mp3", "sound.mod", "sound.mid", "house_lo.ogg", >> "house_lo.mp3"] >> >> class file_like_wrapper(): >> def __init__(self, fname): >> self.my_fname = fname >> self.my_file = file(fname, "rb") >> >> def read(self, size=None): >> print self.my_fname,"read", size >> if size != None: >> return self.my_file.read(size) >> else: >> return self.my_file.read() >> >> def seek(self, offset, whence): >> print self.my_fname,"seek",offset, whence >> return self.my_file.seek(offset, whence) >> >> def tell(self): >> tell_pos = self.my_file.tell() >> print self.my_fname,"tell", tell_pos >> return tell_pos >> >> def close(self): >> print self.my_fname,"close" >> return self.my_file.close() >> >> for filename in files: >> print "loading",filename,"..." >> >> print "from filename", >> sound = pygame.mixer.music.load(filename) >> print "loaded!" >> pygame.mixer.music.play() >> print "playing!" >> time.sleep(3) >> pygame.event.pump() >> pygame.mixer.music.stop() >> >> print "loading from file-like object", >> sound = pygame.mixer.music.load(file_like_wrapper(filename)) >> print "loaded!" >> pygame.mixer.music.play() >> print "playing!" >> time.sleep(3) >> pygame.event.pump() >> print "done playing!" >> pygame.mixer.music.stop() >> >> print "loading from file object", >> sound = pygame.mixer.music.load(file(filename, "rb")) >> print "loaded!" >> pygame.mixer.music.play() >> print "playing!" >> time.sleep(3) >> pygame.event.pump() >> print "done playing!" >> pygame.mixer.music.stop() >> >> >> >
Re: [pygame] Patch - Re-add music support for file-like objects
Sorry for lack of detail. All are tested on Linux. Test files: http://im.forre.st/sound.ogg http://im.forre.st/sound.mp3 http://im.forre.st/sound.mid http://im.forre.st/sound.mod I'm not sure what your problem is, but I had only looked in the ChangeLog, not the source for SDL_mixer 1.2.8. On Wed, Jul 16, 2008 at 9:55 PM, Forrest Voight <[EMAIL PROTECTED]> wrote: > I installed 1.2.8 and confirm OGG, MP3, MID and MOD are working. > > On Wed, Jul 16, 2008 at 9:09 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: >> I've tested loading MP3 and OGG as music from file-objects on both Windows >> and Mac OS X using pygame SDL_Mixer 1.2.8, and SDL_Mixer failed to load >> them. >> >> So if SDL_Mixer 1.2.8 is supposed to support them, then something else is >> broken. >> >> >> Forrest, you said earlier on this list you were able to load & play Wav & >> OGG with SDL_mixer SVN and that the current SDL_Mixer (1.2.8 at the time) >> only supports MikMod (meaning MOD), which matches my experience and >> indicates that the uncoming 1.2.9 is required for WAV & OGG & MP3 support... >> has something changed your mind since you posted about mixer's level of >> support? >> >> Also, can you confirm that you have successfully loaded MP3, OGG & MID from >> a file using pygame over SDL_Mixer 1.2.8? If so, what platforms and what >> specific music files? >> >> >> On Wed, Jul 16, 2008 at 5:36 PM, Forrest Voight <[EMAIL PROTECTED]> wrote: >>> >>> I think it should be >=1.2.8. >>> There is support for MP3, OGG, MID, and MOD in 1.2.8. All 1.2.9 will add >>> is WAV. >>> >> >> >
Re: [pygame] Patch - Re-add music support for file-like objects
I installed 1.2.8 and confirm OGG, MP3, MID and MOD are working. On Wed, Jul 16, 2008 at 9:09 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: > I've tested loading MP3 and OGG as music from file-objects on both Windows > and Mac OS X using pygame SDL_Mixer 1.2.8, and SDL_Mixer failed to load > them. > > So if SDL_Mixer 1.2.8 is supposed to support them, then something else is > broken. > > > Forrest, you said earlier on this list you were able to load & play Wav & > OGG with SDL_mixer SVN and that the current SDL_Mixer (1.2.8 at the time) > only supports MikMod (meaning MOD), which matches my experience and > indicates that the uncoming 1.2.9 is required for WAV & OGG & MP3 support... > has something changed your mind since you posted about mixer's level of > support? > > Also, can you confirm that you have successfully loaded MP3, OGG & MID from > a file using pygame over SDL_Mixer 1.2.8? If so, what platforms and what > specific music files? > > > On Wed, Jul 16, 2008 at 5:36 PM, Forrest Voight <[EMAIL PROTECTED]> wrote: >> >> I think it should be >=1.2.8. >> There is support for MP3, OGG, MID, and MOD in 1.2.8. All 1.2.9 will add >> is WAV. >> > >
Re: [pygame] Patch - Re-add music support for file-like objects
I think it should be >=1.2.8. There is support for MP3, OGG, MID, and MOD in 1.2.8. All 1.2.9 will add is WAV. On Wed, Jul 16, 2008 at 7:43 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > hi, > > Aliens took out my brain and inserted a pumpkin instead... makes it > kind of hard to code. > > I meant to update all of the version checks before release... but > forgot about it. > > That check should be "> 1.2.8" right? Since we're hoping that the > goodies will be in 1.2.9. > > I guess that means a rc3 is needed once the new version checks are > in... there's that pygame.movie bug report to check out too. > > > cu, > > > On Thu, Jul 17, 2008 at 6:16 AM, Forrest Voight <[EMAIL PROTECTED]> wrote: >> Rene: Why'd you change the version check and why did you change it like this? >> >> /* >>#if (MIX_MAJOR_VERSION*100*100 + MIX_MINOR_VERSION*100 + >> MIX_PATCHLEVEL) > 010207 >> */ >> #if MIX_MAJOR_VERSION>=1 && MIX_MINOR_VERSION>=2 && MIX_PATCHLEVEL>=8 >> >> What is going to happen when SDL_mixer 1.3.0 comes out? >> >> On Tue, Jul 15, 2008 at 12:35 AM, Brian Fisher >> <[EMAIL PROTECTED]> wrote: >>> sweet, you rock. >>> >>> >>> On Mon, Jul 14, 2008 at 9:27 PM, Forrest Voight <[EMAIL PROTECTED]> wrote: >>>> >>>> I submitted a patch to SDL_mixer to fix the mp3 problem. >>>> >>>> On Sat, Jul 12, 2008 at 7:29 PM, René Dudfield <[EMAIL PROTECTED]> wrote: >>>> > hi, >>>> > >>>> > I changed the version check to 1.2.9 instead... since support is in >>>> > sdl_mixer svn is getting better. >>>> > >>>> > The tests are disabled for loading from file-likes -- so all tests >>>> > pass again (at least they do here). >>>> > >>>> > cheers, >>>> > >>>> > >>>> > >>>> > On Sun, Jul 13, 2008 at 6:58 AM, Forrest Voight <[EMAIL PROTECTED]> >>>> > wrote: >>>> >> I'm also able to play FLAC audio. >>>> >> >>>> >> I think the problem is that SDL_mixer detects MP3 files through the >>>> >> first and second bytes (the first is '\xff'), and files with ID3 tags >>>> >> have a special header first, so SDL_mixer defaults to mikmod decoding, >>>> >> which determines it is invalid. >>>> >> >>>> >> So, some MP3 files work and some don't. I was able to find an MP3 file >>>> >> without tags and it worked. This is an SDL_mixer bug. >>>> >> >>>> >> On Sat, Jul 12, 2008 at 4:44 PM, Forrest Voight <[EMAIL PROTECTED]> >>>> >> wrote: >>>> >>> Using SDL_mixer SVN, I'm able to load & play WAV and OGG. >>>> >>> >>>> >>> MP3 gives me the 'Module format not recognized' error. I'm looking >>>> >>> into that now... >>>> >>> >>>> >>> On Sat, Jul 12, 2008 at 3:58 PM, Brian Fisher >>>> >>> <[EMAIL PROTECTED]> wrote: >>>> >>>> My automated build machines both use 1.2.8, and they both fail to >>>> >>>> load mp3 >>>> >>>> (what the test is currently trying) >>>> >>>> >>>> >>>> so it seems that 1.2.8 doesn't support MP3. This post seems to >>>> >>>> indicate that >>>> >>>> OGG and MOD should be supported: >>>> >>>> >>>> >>>> http://listas.apesol.org/pipermail/sdl-libsdl.org/2007-December/063633.html >>>> >>>> I tried OGG on my Mac though, and it just seemed to hang :( I don't >>>> >>>> have a >>>> >>>> mod file to try at the moment. >>>> >>>> >>>> >>>> So Forrest, what formats were you able to load when you were testing >>>> >>>> the >>>> >>>> patch? >>>> >>>> >>>> >>>> >>>> >>>> On Sat, Jul 12, 2008 at 12:13 PM, Forrest Voight <[EMAIL PROTECTED]> >>>> >>>> wrote: >>>> >>>>> >>>> >>>>> Rene: what version of SDL_mixer are you using? >>>> >>>>> >>>> &g
Re: [pygame] Patch - Re-add music support for file-like objects
Rene: Why'd you change the version check and why did you change it like this? /* #if (MIX_MAJOR_VERSION*100*100 + MIX_MINOR_VERSION*100 + MIX_PATCHLEVEL) > 010207 */ #if MIX_MAJOR_VERSION>=1 && MIX_MINOR_VERSION>=2 && MIX_PATCHLEVEL>=8 What is going to happen when SDL_mixer 1.3.0 comes out? On Tue, Jul 15, 2008 at 12:35 AM, Brian Fisher <[EMAIL PROTECTED]> wrote: > sweet, you rock. > > > On Mon, Jul 14, 2008 at 9:27 PM, Forrest Voight <[EMAIL PROTECTED]> wrote: >> >> I submitted a patch to SDL_mixer to fix the mp3 problem. >> >> On Sat, Jul 12, 2008 at 7:29 PM, René Dudfield <[EMAIL PROTECTED]> wrote: >> > hi, >> > >> > I changed the version check to 1.2.9 instead... since support is in >> > sdl_mixer svn is getting better. >> > >> > The tests are disabled for loading from file-likes -- so all tests >> > pass again (at least they do here). >> > >> > cheers, >> > >> > >> > >> > On Sun, Jul 13, 2008 at 6:58 AM, Forrest Voight <[EMAIL PROTECTED]> >> > wrote: >> >> I'm also able to play FLAC audio. >> >> >> >> I think the problem is that SDL_mixer detects MP3 files through the >> >> first and second bytes (the first is '\xff'), and files with ID3 tags >> >> have a special header first, so SDL_mixer defaults to mikmod decoding, >> >> which determines it is invalid. >> >> >> >> So, some MP3 files work and some don't. I was able to find an MP3 file >> >> without tags and it worked. This is an SDL_mixer bug. >> >> >> >> On Sat, Jul 12, 2008 at 4:44 PM, Forrest Voight <[EMAIL PROTECTED]> >> >> wrote: >> >>> Using SDL_mixer SVN, I'm able to load & play WAV and OGG. >> >>> >> >>> MP3 gives me the 'Module format not recognized' error. I'm looking >> >>> into that now... >> >>> >> >>> On Sat, Jul 12, 2008 at 3:58 PM, Brian Fisher >> >>> <[EMAIL PROTECTED]> wrote: >> >>>> My automated build machines both use 1.2.8, and they both fail to >> >>>> load mp3 >> >>>> (what the test is currently trying) >> >>>> >> >>>> so it seems that 1.2.8 doesn't support MP3. This post seems to >> >>>> indicate that >> >>>> OGG and MOD should be supported: >> >>>> >> >>>> http://listas.apesol.org/pipermail/sdl-libsdl.org/2007-December/063633.html >> >>>> I tried OGG on my Mac though, and it just seemed to hang :( I don't >> >>>> have a >> >>>> mod file to try at the moment. >> >>>> >> >>>> So Forrest, what formats were you able to load when you were testing >> >>>> the >> >>>> patch? >> >>>> >> >>>> >> >>>> On Sat, Jul 12, 2008 at 12:13 PM, Forrest Voight <[EMAIL PROTECTED]> >> >>>> wrote: >> >>>>> >> >>>>> Rene: what version of SDL_mixer are you using? >> >>>>> >> >>>>> I think I was wrong... SDL_mixer 1.2.8 supports OGG, MP3, MID, and >> >>>>> MOD >> >>>>> music. >> >>>>> >> >>>>> Only SVN supports WAV. >> >>>>> >> >>>>> On Sat, Jul 12, 2008 at 1:40 PM, Brian Fisher >> >>>>> <[EMAIL PROTECTED]> >> >>>>> wrote: >> >>>>> > by svn version do you mean 1.3, or an upcoming bug-fix release of >> >>>>> > 1.2? >> >>>>> > >> >>>>> > >> >>>>> > On Sat, Jul 12, 2008 at 9:27 AM, Forrest Voight >> >>>>> > <[EMAIL PROTECTED]> >> >>>>> > wrote: >> >>>>> >> >> >>>>> >> The current sdl_mixer svn only supports mikmod. The svn version >> >>>>> >> supports all of those formats. >> >>>>> >> >> >>>>> >> On Sat, Jul 12, 2008 at 4:55 AM, René Dudfield <[EMAIL PROTECTED]> >> >>>>> >> wrote: >> >>>>> >> > hi, >> >>>>> >> > >> >>>>> >> > I just wrote a test for it (see test/mixer_test.py). >>
Re: [pygame] Obtain actual volume of sample being played
sound = pygame.mixer.Sound('x.wav')
array = pygame.sndarray.samples(sound)
On Tue, Jul 15, 2008 at 3:16 PM, Wyatt Olson <[EMAIL PROTECTED]> wrote:
> How do you access the sndarray for a sound loaded from a .wav sample? From
> what I can tell, you can either create a Sound object from a .wav file, or
> from a sndarray object, but I don't see how you can access the backing
> sndarray from a .wav Sound...
>
> Sorry if I am missing something obvious.
>
> Cheers
>
> Forrest Voight wrote:
>>
>> You could access a sndarray and average the current portion of it. You
>> could probably even use numpy to do a fourier transform on it.
>>
>> On Tue, Jul 15, 2008 at 12:26 PM, Wyatt Olson <[EMAIL PROTECTED]>
>> wrote:
>>
>>>
>>> Hello,
>>>
>>> Does anyone know if it is possible to obtain the actual volume of the
>>> sample
>>> being played at a given moment? This is not the same as getting the
>>> volume
>>> level which was set earlier, on either the sample or the channel.
>>>
>>> For instance, assume that I am playing a sample which starts at low
>>> volume
>>> (-70dB), increases to 0dB after 5 seconds, then fades out to -70dB again.
>>> If I play that sample at volume = 1.0, I would want to be able to return
>>> an
>>> approximation of the actual dB value at the given time. For instance, if
>>> I
>>> were to query it at 0 seconds, I would get 0.01; querying at 5
>>> seconds
>>> would return 1.0; querying at 7.5 seconds would give 0.5 or something.
>>> Make sense? I would want to have this controllable at the channel and /
>>> or
>>> sample level, not the mixer - I need to show each channel separately. I
>>> don't care about linear / logarithmic conversions or anything... I
>>> essentially just need a number from 0 to 9 indicating very approximately
>>> how
>>> loud the sound is.
>>>
>>> I want this information to display semi-accurate VU / peak meter
>>> information, based on actual samples. This is for my slave software for
>>> an
>>> electronic drum set. Currently I show VU information based on the
>>> velocity
>>> of a drum pad hit, which is decent, but it would be nice to use the
>>> actual
>>> sample information as well.
>>>
>>> I have looked through the documentation, and I don't think it can be
>>> done,
>>> but I figured I may as well submit this question to the gurus on teh
>>> interwebs. 8-)
>>>
>>> Cheers
>>>
>>>
>
>
Re: [pygame] Obtain actual volume of sample being played
You could access a sndarray and average the current portion of it. You could probably even use numpy to do a fourier transform on it. On Tue, Jul 15, 2008 at 12:26 PM, Wyatt Olson <[EMAIL PROTECTED]> wrote: > Hello, > > Does anyone know if it is possible to obtain the actual volume of the sample > being played at a given moment? This is not the same as getting the volume > level which was set earlier, on either the sample or the channel. > > For instance, assume that I am playing a sample which starts at low volume > (-70dB), increases to 0dB after 5 seconds, then fades out to -70dB again. > If I play that sample at volume = 1.0, I would want to be able to return an > approximation of the actual dB value at the given time. For instance, if I > were to query it at 0 seconds, I would get 0.01; querying at 5 seconds > would return 1.0; querying at 7.5 seconds would give 0.5 or something. > Make sense? I would want to have this controllable at the channel and / or > sample level, not the mixer - I need to show each channel separately. I > don't care about linear / logarithmic conversions or anything... I > essentially just need a number from 0 to 9 indicating very approximately how > loud the sound is. > > I want this information to display semi-accurate VU / peak meter > information, based on actual samples. This is for my slave software for an > electronic drum set. Currently I show VU information based on the velocity > of a drum pad hit, which is decent, but it would be nice to use the actual > sample information as well. > > I have looked through the documentation, and I don't think it can be done, > but I figured I may as well submit this question to the gurus on teh > interwebs. 8-) > > Cheers >
Re: [pygame] Patch - Re-add music support for file-like objects
I submitted a patch to SDL_mixer to fix the mp3 problem. On Sat, Jul 12, 2008 at 7:29 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > hi, > > I changed the version check to 1.2.9 instead... since support is in > sdl_mixer svn is getting better. > > The tests are disabled for loading from file-likes -- so all tests > pass again (at least they do here). > > cheers, > > > > On Sun, Jul 13, 2008 at 6:58 AM, Forrest Voight <[EMAIL PROTECTED]> wrote: >> I'm also able to play FLAC audio. >> >> I think the problem is that SDL_mixer detects MP3 files through the >> first and second bytes (the first is '\xff'), and files with ID3 tags >> have a special header first, so SDL_mixer defaults to mikmod decoding, >> which determines it is invalid. >> >> So, some MP3 files work and some don't. I was able to find an MP3 file >> without tags and it worked. This is an SDL_mixer bug. >> >> On Sat, Jul 12, 2008 at 4:44 PM, Forrest Voight <[EMAIL PROTECTED]> wrote: >>> Using SDL_mixer SVN, I'm able to load & play WAV and OGG. >>> >>> MP3 gives me the 'Module format not recognized' error. I'm looking >>> into that now... >>> >>> On Sat, Jul 12, 2008 at 3:58 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: >>>> My automated build machines both use 1.2.8, and they both fail to load mp3 >>>> (what the test is currently trying) >>>> >>>> so it seems that 1.2.8 doesn't support MP3. This post seems to indicate >>>> that >>>> OGG and MOD should be supported: >>>> http://listas.apesol.org/pipermail/sdl-libsdl.org/2007-December/063633.html >>>> I tried OGG on my Mac though, and it just seemed to hang :( I don't have a >>>> mod file to try at the moment. >>>> >>>> So Forrest, what formats were you able to load when you were testing the >>>> patch? >>>> >>>> >>>> On Sat, Jul 12, 2008 at 12:13 PM, Forrest Voight <[EMAIL PROTECTED]> wrote: >>>>> >>>>> Rene: what version of SDL_mixer are you using? >>>>> >>>>> I think I was wrong... SDL_mixer 1.2.8 supports OGG, MP3, MID, and MOD >>>>> music. >>>>> >>>>> Only SVN supports WAV. >>>>> >>>>> On Sat, Jul 12, 2008 at 1:40 PM, Brian Fisher <[EMAIL PROTECTED]> >>>>> wrote: >>>>> > by svn version do you mean 1.3, or an upcoming bug-fix release of 1.2? >>>>> > >>>>> > >>>>> > On Sat, Jul 12, 2008 at 9:27 AM, Forrest Voight <[EMAIL PROTECTED]> >>>>> > wrote: >>>>> >> >>>>> >> The current sdl_mixer svn only supports mikmod. The svn version >>>>> >> supports all of those formats. >>>>> >> >>>>> >> On Sat, Jul 12, 2008 at 4:55 AM, René Dudfield <[EMAIL PROTECTED]> >>>>> >> wrote: >>>>> >> > hi, >>>>> >> > >>>>> >> > I just wrote a test for it (see test/mixer_test.py). >>>>> >> > >>>>> >> > Unfortunately it doesn't seem to be able to load from a file like >>>>> >> > object for mp3, ogg, or wav files. >>>>> >> > >>>>> >> > Any ideas? >>>>> >> > >>>>> >> > >>>>> >> > == >>>>> >> > ERROR: test_mixer_music__load (__main__.MixerModuleTest) >>>>> >> > >>>>> >> > -- >>>>> >> > Traceback (most recent call last): >>>>> >> > File "test\mixer_test.py", line 207, in test_mixer_music__load >>>>> >> >pygame.mixer.music.load(open(musfn)) >>>>> >> > error: Module format not recognized >>>>> >> > >>>>> >> > >>>>> >> > cu, >>>>> >> > >>>>> >> > On Thu, Jul 10, 2008 at 11:33 PM, René Dudfield <[EMAIL PROTECTED]> >>>>> >> > wrote: >>>>> >> >> Cool, thanks. >>>>> >> >> >>>>> >> >> Committed revision 1482. >>>>> >
Re: [pygame] image-loading path
Yes, but the path is relative to where you are running the script from, not where the script is. On Mon, Jul 14, 2008 at 11:43 AM, Olaf Nowacki <[EMAIL PROTECTED]> wrote: > hi everyone, > is it possible to load an image with pygame.image.load() that is not in the > same folder (or a subfolder), but higher up in the file-tree? i tried giving > "../data/images/image.png" as argument, but it didn't work. > here i tried to illustrate what i mean: > [game] > |- [engine] > |- tools.load_image() > |- [data] > |-[images] > |- image.png > thanks in advance! > olaf >
Re: [pygame] Patch - Re-add music support for file-like objects
Using SDL_mixer SVN, I'm able to load & play WAV and OGG. MP3 gives me the 'Module format not recognized' error. I'm looking into that now... On Sat, Jul 12, 2008 at 3:58 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: > My automated build machines both use 1.2.8, and they both fail to load mp3 > (what the test is currently trying) > > so it seems that 1.2.8 doesn't support MP3. This post seems to indicate that > OGG and MOD should be supported: > http://listas.apesol.org/pipermail/sdl-libsdl.org/2007-December/063633.html > I tried OGG on my Mac though, and it just seemed to hang :( I don't have a > mod file to try at the moment. > > So Forrest, what formats were you able to load when you were testing the > patch? > > > On Sat, Jul 12, 2008 at 12:13 PM, Forrest Voight <[EMAIL PROTECTED]> wrote: >> >> Rene: what version of SDL_mixer are you using? >> >> I think I was wrong... SDL_mixer 1.2.8 supports OGG, MP3, MID, and MOD >> music. >> >> Only SVN supports WAV. >> >> On Sat, Jul 12, 2008 at 1:40 PM, Brian Fisher <[EMAIL PROTECTED]> >> wrote: >> > by svn version do you mean 1.3, or an upcoming bug-fix release of 1.2? >> > >> > >> > On Sat, Jul 12, 2008 at 9:27 AM, Forrest Voight <[EMAIL PROTECTED]> >> > wrote: >> >> >> >> The current sdl_mixer svn only supports mikmod. The svn version >> >> supports all of those formats. >> >> >> >> On Sat, Jul 12, 2008 at 4:55 AM, René Dudfield <[EMAIL PROTECTED]> >> >> wrote: >> >> > hi, >> >> > >> >> > I just wrote a test for it (see test/mixer_test.py). >> >> > >> >> > Unfortunately it doesn't seem to be able to load from a file like >> >> > object for mp3, ogg, or wav files. >> >> > >> >> > Any ideas? >> >> > >> >> > >> >> > == >> >> > ERROR: test_mixer_music__load (__main__.MixerModuleTest) >> >> > >> >> > ------ >> >> > Traceback (most recent call last): >> >> > File "test\mixer_test.py", line 207, in test_mixer_music__load >> >> >pygame.mixer.music.load(open(musfn)) >> >> > error: Module format not recognized >> >> > >> >> > >> >> > cu, >> >> > >> >> > On Thu, Jul 10, 2008 at 11:33 PM, René Dudfield <[EMAIL PROTECTED]> >> >> > wrote: >> >> >> Cool, thanks. >> >> >> >> >> >> Committed revision 1482. >> >> >> >> >> >> On Wed, Jul 9, 2008 at 12:39 PM, Forrest Voight <[EMAIL PROTECTED]> >> >> >> wrote: >> >> >>> All we need to do is make RwopsFromPythonThreaded not try to make a >> >> >>> standard rwop, because it shouldn't. >> >> >>> >> >> >>> And it is correct, RwopsFromPythonThreaded is obviously meant to be >> >> >>> used like this (hence the threaded). >> >> >>> >> >> >>> Attached is the updated patch. >> >> >>> >> >> >>> Forrest >> >> >>> >> >> >>> On Tue, Jul 8, 2008 at 9:38 PM, René Dudfield <[EMAIL PROTECTED]> >> >> >>> wrote: >> >> >>>> I guess we need to store a reference to the file object somewhere, >> >> >>>> and >> >> >>>> release the reference at cleanup. >> >> >>>> >> >> >>>> >> >> >>>> On Wed, Jul 9, 2008 at 9:40 AM, Brian Fisher >> >> >>>> <[EMAIL PROTECTED]> wrote: >> >> >>>>> Hmmm... from looking at the patch, it seems that it does not fix >> >> >>>>> the >> >> >>>>> crash >> >> >>>>> that Forrest discovered (where the file object falls out of scope >> >> >>>>> and gets >> >> >>>>> deleted so the rwobject ends up having bad pointers) - Is that >> >> >>>>> correct >> >> >>>>> Forrest? >> >> >>>>> >> >> >>>>> If that is the case, it seems to me that the fe
Re: [pygame] Patch - Re-add music support for file-like objects
I'm also able to play FLAC audio. I think the problem is that SDL_mixer detects MP3 files through the first and second bytes (the first is '\xff'), and files with ID3 tags have a special header first, so SDL_mixer defaults to mikmod decoding, which determines it is invalid. So, some MP3 files work and some don't. I was able to find an MP3 file without tags and it worked. This is an SDL_mixer bug. On Sat, Jul 12, 2008 at 4:44 PM, Forrest Voight <[EMAIL PROTECTED]> wrote: > Using SDL_mixer SVN, I'm able to load & play WAV and OGG. > > MP3 gives me the 'Module format not recognized' error. I'm looking > into that now... > > On Sat, Jul 12, 2008 at 3:58 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: >> My automated build machines both use 1.2.8, and they both fail to load mp3 >> (what the test is currently trying) >> >> so it seems that 1.2.8 doesn't support MP3. This post seems to indicate that >> OGG and MOD should be supported: >> http://listas.apesol.org/pipermail/sdl-libsdl.org/2007-December/063633.html >> I tried OGG on my Mac though, and it just seemed to hang :( I don't have a >> mod file to try at the moment. >> >> So Forrest, what formats were you able to load when you were testing the >> patch? >> >> >> On Sat, Jul 12, 2008 at 12:13 PM, Forrest Voight <[EMAIL PROTECTED]> wrote: >>> >>> Rene: what version of SDL_mixer are you using? >>> >>> I think I was wrong... SDL_mixer 1.2.8 supports OGG, MP3, MID, and MOD >>> music. >>> >>> Only SVN supports WAV. >>> >>> On Sat, Jul 12, 2008 at 1:40 PM, Brian Fisher <[EMAIL PROTECTED]> >>> wrote: >>> > by svn version do you mean 1.3, or an upcoming bug-fix release of 1.2? >>> > >>> > >>> > On Sat, Jul 12, 2008 at 9:27 AM, Forrest Voight <[EMAIL PROTECTED]> >>> > wrote: >>> >> >>> >> The current sdl_mixer svn only supports mikmod. The svn version >>> >> supports all of those formats. >>> >> >>> >> On Sat, Jul 12, 2008 at 4:55 AM, René Dudfield <[EMAIL PROTECTED]> >>> >> wrote: >>> >> > hi, >>> >> > >>> >> > I just wrote a test for it (see test/mixer_test.py). >>> >> > >>> >> > Unfortunately it doesn't seem to be able to load from a file like >>> >> > object for mp3, ogg, or wav files. >>> >> > >>> >> > Any ideas? >>> >> > >>> >> > >>> >> > ====== >>> >> > ERROR: test_mixer_music__load (__main__.MixerModuleTest) >>> >> > >>> >> > -- >>> >> > Traceback (most recent call last): >>> >> > File "test\mixer_test.py", line 207, in test_mixer_music__load >>> >> >pygame.mixer.music.load(open(musfn)) >>> >> > error: Module format not recognized >>> >> > >>> >> > >>> >> > cu, >>> >> > >>> >> > On Thu, Jul 10, 2008 at 11:33 PM, René Dudfield <[EMAIL PROTECTED]> >>> >> > wrote: >>> >> >> Cool, thanks. >>> >> >> >>> >> >> Committed revision 1482. >>> >> >> >>> >> >> On Wed, Jul 9, 2008 at 12:39 PM, Forrest Voight <[EMAIL PROTECTED]> >>> >> >> wrote: >>> >> >>> All we need to do is make RwopsFromPythonThreaded not try to make a >>> >> >>> standard rwop, because it shouldn't. >>> >> >>> >>> >> >>> And it is correct, RwopsFromPythonThreaded is obviously meant to be >>> >> >>> used like this (hence the threaded). >>> >> >>> >>> >> >>> Attached is the updated patch. >>> >> >>> >>> >> >>> Forrest >>> >> >>> >>> >> >>> On Tue, Jul 8, 2008 at 9:38 PM, René Dudfield <[EMAIL PROTECTED]> >>> >> >>> wrote: >>> >> >>>> I guess we need to store a reference to the file object somewhere, >>> >> >>>> and >>> >> >>>> release the reference at cleanup. >>> >> >>>>
Re: [pygame] Patch - Re-add music support for file-like objects
Rene: what version of SDL_mixer are you using? I think I was wrong... SDL_mixer 1.2.8 supports OGG, MP3, MID, and MOD music. Only SVN supports WAV. On Sat, Jul 12, 2008 at 1:40 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: > by svn version do you mean 1.3, or an upcoming bug-fix release of 1.2? > > > On Sat, Jul 12, 2008 at 9:27 AM, Forrest Voight <[EMAIL PROTECTED]> wrote: >> >> The current sdl_mixer svn only supports mikmod. The svn version >> supports all of those formats. >> >> On Sat, Jul 12, 2008 at 4:55 AM, René Dudfield <[EMAIL PROTECTED]> wrote: >> > hi, >> > >> > I just wrote a test for it (see test/mixer_test.py). >> > >> > Unfortunately it doesn't seem to be able to load from a file like >> > object for mp3, ogg, or wav files. >> > >> > Any ideas? >> > >> > == >> > ERROR: test_mixer_music__load (__main__.MixerModuleTest) >> > -- >> > Traceback (most recent call last): >> > File "test\mixer_test.py", line 207, in test_mixer_music__load >> >pygame.mixer.music.load(open(musfn)) >> > error: Module format not recognized >> > >> > >> > cu, >> > >> > On Thu, Jul 10, 2008 at 11:33 PM, René Dudfield <[EMAIL PROTECTED]> >> > wrote: >> >> Cool, thanks. >> >> >> >> Committed revision 1482. >> >> >> >> On Wed, Jul 9, 2008 at 12:39 PM, Forrest Voight <[EMAIL PROTECTED]> >> >> wrote: >> >>> All we need to do is make RwopsFromPythonThreaded not try to make a >> >>> standard rwop, because it shouldn't. >> >>> >> >>> And it is correct, RwopsFromPythonThreaded is obviously meant to be >> >>> used like this (hence the threaded). >> >>> >> >>> Attached is the updated patch. >> >>> >> >>> Forrest >> >>> >> >>> On Tue, Jul 8, 2008 at 9:38 PM, René Dudfield <[EMAIL PROTECTED]> >> >>> wrote: >> >>>> I guess we need to store a reference to the file object somewhere, >> >>>> and >> >>>> release the reference at cleanup. >> >>>> >> >>>> >> >>>> On Wed, Jul 9, 2008 at 9:40 AM, Brian Fisher >> >>>> <[EMAIL PROTECTED]> wrote: >> >>>>> Hmmm... from looking at the patch, it seems that it does not fix the >> >>>>> crash >> >>>>> that Forrest discovered (where the file object falls out of scope >> >>>>> and gets >> >>>>> deleted so the rwobject ends up having bad pointers) - Is that >> >>>>> correct >> >>>>> Forrest? >> >>>>> >> >>>>> If that is the case, it seems to me that the feature implementation >> >>>>> isn't >> >>>>> finished yet, so the patch as sent is not ready to be applied to >> >>>>> pygame >> >>>>> 1.8.1. >> >>>>> >> >>>>> I would imagine that in most cases, people wouldn't be keeping >> >>>>> around a >> >>>>> python reference to the file object they would pass in (cause it >> >>>>> loads the >> >>>>> music up in some other function or something), which means most >> >>>>> attempts to >> >>>>> use this feature would get crashes and bad behavior as the mixer >> >>>>> tries to >> >>>>> stream the music, but the file object falls out of scope - and the >> >>>>> crash >> >>>>> would happen at what seems like a random point in time. >> >>>>> >> >>>>> Also, as I said in an earlier email, I don't think this patch is >> >>>>> exposing an >> >>>>> existing bug, I think it uses rwobject in a way that's not intended, >> >>>>> as >> >>>>> other "load-from-file" pygame uses don't require the file-object to >> >>>>> exist >> >>>>> longer than it takes for the load function to return. >> >>>>> >> >>>>> >> >>>>> >> >>>>> On
Re: [pygame] Patch - Re-add music support for file-like objects
The current sdl_mixer svn only supports mikmod. The svn version
supports all of those formats.
On Sat, Jul 12, 2008 at 4:55 AM, René Dudfield <[EMAIL PROTECTED]> wrote:
> hi,
>
> I just wrote a test for it (see test/mixer_test.py).
>
> Unfortunately it doesn't seem to be able to load from a file like
> object for mp3, ogg, or wav files.
>
> Any ideas?
>
> ==
> ERROR: test_mixer_music__load (__main__.MixerModuleTest)
> --
> Traceback (most recent call last):
> File "test\mixer_test.py", line 207, in test_mixer_music__load
>pygame.mixer.music.load(open(musfn))
> error: Module format not recognized
>
>
> cu,
>
> On Thu, Jul 10, 2008 at 11:33 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
>> Cool, thanks.
>>
>> Committed revision 1482.
>>
>> On Wed, Jul 9, 2008 at 12:39 PM, Forrest Voight <[EMAIL PROTECTED]> wrote:
>>> All we need to do is make RwopsFromPythonThreaded not try to make a
>>> standard rwop, because it shouldn't.
>>>
>>> And it is correct, RwopsFromPythonThreaded is obviously meant to be
>>> used like this (hence the threaded).
>>>
>>> Attached is the updated patch.
>>>
>>> Forrest
>>>
>>> On Tue, Jul 8, 2008 at 9:38 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
>>>> I guess we need to store a reference to the file object somewhere, and
>>>> release the reference at cleanup.
>>>>
>>>>
>>>> On Wed, Jul 9, 2008 at 9:40 AM, Brian Fisher <[EMAIL PROTECTED]> wrote:
>>>>> Hmmm... from looking at the patch, it seems that it does not fix the crash
>>>>> that Forrest discovered (where the file object falls out of scope and gets
>>>>> deleted so the rwobject ends up having bad pointers) - Is that correct
>>>>> Forrest?
>>>>>
>>>>> If that is the case, it seems to me that the feature implementation isn't
>>>>> finished yet, so the patch as sent is not ready to be applied to pygame
>>>>> 1.8.1.
>>>>>
>>>>> I would imagine that in most cases, people wouldn't be keeping around a
>>>>> python reference to the file object they would pass in (cause it loads the
>>>>> music up in some other function or something), which means most attempts
>>>>> to
>>>>> use this feature would get crashes and bad behavior as the mixer tries to
>>>>> stream the music, but the file object falls out of scope - and the crash
>>>>> would happen at what seems like a random point in time.
>>>>>
>>>>> Also, as I said in an earlier email, I don't think this patch is exposing
>>>>> an
>>>>> existing bug, I think it uses rwobject in a way that's not intended, as
>>>>> other "load-from-file" pygame uses don't require the file-object to exist
>>>>> longer than it takes for the load function to return.
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 8, 2008 at 3:20 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
>>>>>>
>>>>>> Cool, thanks. I'll try and patch it tonight (+ 9 hours).
>>>>>>
>>>>>> cu,
>>>>>>
>>>>>> On Wed, Jul 9, 2008 at 1:09 AM, Forrest Voight <[EMAIL PROTECTED]> wrote:
>>>>>> > I did the version checks.
>>>>>> >
>>>>>> > There are currently no tests for pygame.mixer.music, but I'll try to
>>>>>> > make a test for this.
>>>>>> >
>>>>>> > Also, I found a bug in rwobject. It makes a standard SDL_RWops from
>>>>>> > python file objects but doesn't hold a reference to them.
>>>>>> > This is shown by doing something like:
>>>>>> >
>>>>>> > pygame.mixer.music.load(open('x.mp3'))
>>>>>> >
>>>>>> > Then playing it, and pygame crashes.
>>>>>> > This is not my patch's fault, it just exposes it.
>>>>>> >
>>>>>> > Forrest Voight
>>>>>> >
>>>>>> > On Tue, Jul 8, 2008 at 2:08 AM, René Dudfield <[EMAIL PROTECTED]>
>>>>>> > wrote:
>>>>>> >> hi,
Re: [pygame] Patch - Re-add music support for file-like objects
Hmm, that was not clear at all.
What I'm doing is correct.
What happened was I provided an actual file object (not a file-like
object), and pygame took the fp and made a normal sdl rwops object
(not a threaded python calling one). The fp was then released and sdl
tried to keep reading from it. With _file-like_ objects, the rwops
does keep a reference to the object, and everything is fine.
This issue is fixed in the above patch.
Anyway, this patch will help enormously, making things like streaming
music and movie players possible.
On Tue, Jul 8, 2008 at 10:39 PM, Forrest Voight <[EMAIL PROTECTED]> wrote:
> All we need to do is make RwopsFromPythonThreaded not try to make a
> standard rwop, because it shouldn't.
>
> And it is correct, RwopsFromPythonThreaded is obviously meant to be
> used like this (hence the threaded).
>
> Attached is the updated patch.
>
> Forrest
>
> On Tue, Jul 8, 2008 at 9:38 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
>> I guess we need to store a reference to the file object somewhere, and
>> release the reference at cleanup.
>>
>>
>> On Wed, Jul 9, 2008 at 9:40 AM, Brian Fisher <[EMAIL PROTECTED]> wrote:
>>> Hmmm... from looking at the patch, it seems that it does not fix the crash
>>> that Forrest discovered (where the file object falls out of scope and gets
>>> deleted so the rwobject ends up having bad pointers) - Is that correct
>>> Forrest?
>>>
>>> If that is the case, it seems to me that the feature implementation isn't
>>> finished yet, so the patch as sent is not ready to be applied to pygame
>>> 1.8.1.
>>>
>>> I would imagine that in most cases, people wouldn't be keeping around a
>>> python reference to the file object they would pass in (cause it loads the
>>> music up in some other function or something), which means most attempts to
>>> use this feature would get crashes and bad behavior as the mixer tries to
>>> stream the music, but the file object falls out of scope - and the crash
>>> would happen at what seems like a random point in time.
>>>
>>> Also, as I said in an earlier email, I don't think this patch is exposing an
>>> existing bug, I think it uses rwobject in a way that's not intended, as
>>> other "load-from-file" pygame uses don't require the file-object to exist
>>> longer than it takes for the load function to return.
>>>
>>>
>>>
>>> On Tue, Jul 8, 2008 at 3:20 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
>>>>
>>>> Cool, thanks. I'll try and patch it tonight (+ 9 hours).
>>>>
>>>> cu,
>>>>
>>>> On Wed, Jul 9, 2008 at 1:09 AM, Forrest Voight <[EMAIL PROTECTED]> wrote:
>>>> > I did the version checks.
>>>> >
>>>> > There are currently no tests for pygame.mixer.music, but I'll try to
>>>> > make a test for this.
>>>> >
>>>> > Also, I found a bug in rwobject. It makes a standard SDL_RWops from
>>>> > python file objects but doesn't hold a reference to them.
>>>> > This is shown by doing something like:
>>>> >
>>>> > pygame.mixer.music.load(open('x.mp3'))
>>>> >
>>>> > Then playing it, and pygame crashes.
>>>> > This is not my patch's fault, it just exposes it.
>>>> >
>>>> > Forrest Voight
>>>> >
>>>> > On Tue, Jul 8, 2008 at 2:08 AM, René Dudfield <[EMAIL PROTECTED]> wrote:
>>>> >> hi,
>>>> >>
>>>> >> I think this will have to wait until we put the version checks in and
>>>> >> have unittests... ie for pygame 1.9. Unless someone can get around to
>>>> >> it in the next week.
>>>> >>
>>>> >>
>>>> >> cu,
>>>> >>
>>>> >>
>>>> >> On Wed, Jun 18, 2008 at 2:44 PM, Forrest Voight <[EMAIL PROTECTED]>
>>>> >> wrote:
>>>> >>> OK, I'll work on unit tests and a version check.
>>>> >>>
>>>> >>> On Mon, Jun 16, 2008 at 11:52 AM, Lenard Lindstrom <[EMAIL PROTECTED]>
>>>> >>> wrote:
>>>> >>>> Maybe the test could write a sine wave to a StringIO, load it, then
>>>> >>>> use
>>>> >>>> get_buffer (sound objects do have get_buffer now, right?*) to check
>>>> >>>&
Re: [pygame] Patch - Re-add music support for file-like objects
All we need to do is make RwopsFromPythonThreaded not try to make a
standard rwop, because it shouldn't.
And it is correct, RwopsFromPythonThreaded is obviously meant to be
used like this (hence the threaded).
Attached is the updated patch.
Forrest
On Tue, Jul 8, 2008 at 9:38 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
> I guess we need to store a reference to the file object somewhere, and
> release the reference at cleanup.
>
>
> On Wed, Jul 9, 2008 at 9:40 AM, Brian Fisher <[EMAIL PROTECTED]> wrote:
>> Hmmm... from looking at the patch, it seems that it does not fix the crash
>> that Forrest discovered (where the file object falls out of scope and gets
>> deleted so the rwobject ends up having bad pointers) - Is that correct
>> Forrest?
>>
>> If that is the case, it seems to me that the feature implementation isn't
>> finished yet, so the patch as sent is not ready to be applied to pygame
>> 1.8.1.
>>
>> I would imagine that in most cases, people wouldn't be keeping around a
>> python reference to the file object they would pass in (cause it loads the
>> music up in some other function or something), which means most attempts to
>> use this feature would get crashes and bad behavior as the mixer tries to
>> stream the music, but the file object falls out of scope - and the crash
>> would happen at what seems like a random point in time.
>>
>> Also, as I said in an earlier email, I don't think this patch is exposing an
>> existing bug, I think it uses rwobject in a way that's not intended, as
>> other "load-from-file" pygame uses don't require the file-object to exist
>> longer than it takes for the load function to return.
>>
>>
>>
>> On Tue, Jul 8, 2008 at 3:20 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
>>>
>>> Cool, thanks. I'll try and patch it tonight (+ 9 hours).
>>>
>>> cu,
>>>
>>> On Wed, Jul 9, 2008 at 1:09 AM, Forrest Voight <[EMAIL PROTECTED]> wrote:
>>> > I did the version checks.
>>> >
>>> > There are currently no tests for pygame.mixer.music, but I'll try to
>>> > make a test for this.
>>> >
>>> > Also, I found a bug in rwobject. It makes a standard SDL_RWops from
>>> > python file objects but doesn't hold a reference to them.
>>> > This is shown by doing something like:
>>> >
>>> > pygame.mixer.music.load(open('x.mp3'))
>>> >
>>> > Then playing it, and pygame crashes.
>>> > This is not my patch's fault, it just exposes it.
>>> >
>>> > Forrest Voight
>>> >
>>> > On Tue, Jul 8, 2008 at 2:08 AM, René Dudfield <[EMAIL PROTECTED]> wrote:
>>> >> hi,
>>> >>
>>> >> I think this will have to wait until we put the version checks in and
>>> >> have unittests... ie for pygame 1.9. Unless someone can get around to
>>> >> it in the next week.
>>> >>
>>> >>
>>> >> cu,
>>> >>
>>> >>
>>> >> On Wed, Jun 18, 2008 at 2:44 PM, Forrest Voight <[EMAIL PROTECTED]>
>>> >> wrote:
>>> >>> OK, I'll work on unit tests and a version check.
>>> >>>
>>> >>> On Mon, Jun 16, 2008 at 11:52 AM, Lenard Lindstrom <[EMAIL PROTECTED]>
>>> >>> wrote:
>>> >>>> Maybe the test could write a sine wave to a StringIO, load it, then
>>> >>>> use
>>> >>>> get_buffer (sound objects do have get_buffer now, right?*) to check
>>> >>>> it.
>>> >>>>
>>> >>>> Lenard
>>> >>>>
>>> >>>> * Sorry, I don't have access to latest Python/Pygame at the moment.
>>> >>>>
>>> >>>> Quoting René Dudfield <[EMAIL PROTECTED]>:
>>> >>>>
>>> >>>>> Hi,
>>> >>>>>
>>> >>>>> nice patch! This will be very useful :)
>>> >>>>>
>>> >>>>> Do you know which version of sdl_mixer allows rwops for music
>>> >>>>> (Mix_LoadMUS_RW)? Does it require an SDL_mixer version check?
>>> >>>>>
>>> >>>>> Are you able to make make any unit tests for using file likes with
>>> >>>>> the
>>> >>>>> music mixer? We're using un
Re: [pygame] Patch - Re-add music support for file-like objects
Also, many of the version checks in pygame are faulty, and I think
mine is a good way to do it.
Things like:
#if MIX_MAJOR_VERSION>=1 && MIX_MINOR_VERSION>=2 && MIX_PATCHLEVEL>=3
Are very bad, right? That will fail when the version rolls over...
Forrest Voigth
On Tue, Jul 8, 2008 at 11:09 AM, Forrest Voight <[EMAIL PROTECTED]> wrote:
> I did the version checks.
>
> There are currently no tests for pygame.mixer.music, but I'll try to
> make a test for this.
>
> Also, I found a bug in rwobject. It makes a standard SDL_RWops from
> python file objects but doesn't hold a reference to them.
> This is shown by doing something like:
>
> pygame.mixer.music.load(open('x.mp3'))
>
> Then playing it, and pygame crashes.
> This is not my patch's fault, it just exposes it.
>
> Forrest Voight
>
> On Tue, Jul 8, 2008 at 2:08 AM, René Dudfield <[EMAIL PROTECTED]> wrote:
>> hi,
>>
>> I think this will have to wait until we put the version checks in and
>> have unittests... ie for pygame 1.9. Unless someone can get around to
>> it in the next week.
>>
>>
>> cu,
>>
>>
>> On Wed, Jun 18, 2008 at 2:44 PM, Forrest Voight <[EMAIL PROTECTED]> wrote:
>>> OK, I'll work on unit tests and a version check.
>>>
>>> On Mon, Jun 16, 2008 at 11:52 AM, Lenard Lindstrom <[EMAIL PROTECTED]>
>>> wrote:
>>>> Maybe the test could write a sine wave to a StringIO, load it, then use
>>>> get_buffer (sound objects do have get_buffer now, right?*) to check it.
>>>>
>>>> Lenard
>>>>
>>>> * Sorry, I don't have access to latest Python/Pygame at the moment.
>>>>
>>>> Quoting René Dudfield <[EMAIL PROTECTED]>:
>>>>
>>>>> Hi,
>>>>>
>>>>> nice patch! This will be very useful :)
>>>>>
>>>>> Do you know which version of sdl_mixer allows rwops for music
>>>>> (Mix_LoadMUS_RW)? Does it require an SDL_mixer version check?
>>>>>
>>>>> Are you able to make make any unit tests for using file likes with the
>>>>> music mixer? We're using unittests for all new code now, and it'd
>>>>> make us feel more safe about adding it in for the 1.8.1 release.
>>>>>
>>>>> Not really sure how best to test it. I guess just loading the music
>>>>> from different filename, and from a python file object would be ok for
>>>>> now.
>>>>>
>>>>> here's a start on a test for it...
>>>>>
>>>>> data_fname = os.path.join('..', 'examples', 'data')
>>>>> #note, I just added house_lo.ogg to svn.
>>>>> oggfn = os.path.join(data_fname, 'house_lo.ogg')
>>>>>
>>>>> pygame.mixer.music.load(oggfn)
>>>>> pygame.mixer.music.load(open(oggfn))
>>>>> oggf = open(oggfn)
>>>>> pygame.mixer.music.load(oggf)
>>>>>
>>>>>
>>>>>
>>>>> cheers,
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Jun 14, 2008 at 9:53 AM, Forrest Voight <[EMAIL PROTECTED]> wrote:
>>>>> > Thanks!
>>>>> >
>>>>> > On Fri, Jun 13, 2008 at 7:31 PM, Lenard Lindstrom <[EMAIL PROTECTED]>
>>>>> > wrote:
>>>>> >> This is interesting. I am having a look at it. No promise it can go
>>>>> >> into
>>>>> >> 1.8.1 though as this is supposed to be a bug fix.
>>>>> >>
>>>>> >> Lenard
>>>>> >>
>>>>> >>
>>>>> >> Forrest Voight wrote:
>>>>> >>>
>>>>> >>> This patch re-adds support for playing (and queueing) music from
>>>>> >>> python file-like objects.
>>>>> >>>
>>>>> >>> While support for WAV music streams is still in SDL_mixer svn, there
>>>>> >>> is support for mp3, mikmod and other formats already.
>>>>> >>>
>>>>> >>>
>>>>> >>
>>>>> >>
>>>>> >
>>>>>
>>>>
>>>>
>>>> --
>>>> Lenard Lindstrom
>>>> <[EMAIL PROTECTED]>
>>>>
>>>>
>>>
>>
>
Re: [pygame] Patch - Re-add music support for file-like objects
I did the version checks.
There are currently no tests for pygame.mixer.music, but I'll try to
make a test for this.
Also, I found a bug in rwobject. It makes a standard SDL_RWops from
python file objects but doesn't hold a reference to them.
This is shown by doing something like:
pygame.mixer.music.load(open('x.mp3'))
Then playing it, and pygame crashes.
This is not my patch's fault, it just exposes it.
Forrest Voight
On Tue, Jul 8, 2008 at 2:08 AM, René Dudfield <[EMAIL PROTECTED]> wrote:
> hi,
>
> I think this will have to wait until we put the version checks in and
> have unittests... ie for pygame 1.9. Unless someone can get around to
> it in the next week.
>
>
> cu,
>
>
> On Wed, Jun 18, 2008 at 2:44 PM, Forrest Voight <[EMAIL PROTECTED]> wrote:
>> OK, I'll work on unit tests and a version check.
>>
>> On Mon, Jun 16, 2008 at 11:52 AM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
>>> Maybe the test could write a sine wave to a StringIO, load it, then use
>>> get_buffer (sound objects do have get_buffer now, right?*) to check it.
>>>
>>> Lenard
>>>
>>> * Sorry, I don't have access to latest Python/Pygame at the moment.
>>>
>>> Quoting René Dudfield <[EMAIL PROTECTED]>:
>>>
>>>> Hi,
>>>>
>>>> nice patch! This will be very useful :)
>>>>
>>>> Do you know which version of sdl_mixer allows rwops for music
>>>> (Mix_LoadMUS_RW)? Does it require an SDL_mixer version check?
>>>>
>>>> Are you able to make make any unit tests for using file likes with the
>>>> music mixer? We're using unittests for all new code now, and it'd
>>>> make us feel more safe about adding it in for the 1.8.1 release.
>>>>
>>>> Not really sure how best to test it. I guess just loading the music
>>>> from different filename, and from a python file object would be ok for
>>>> now.
>>>>
>>>> here's a start on a test for it...
>>>>
>>>> data_fname = os.path.join('..', 'examples', 'data')
>>>> #note, I just added house_lo.ogg to svn.
>>>> oggfn = os.path.join(data_fname, 'house_lo.ogg')
>>>>
>>>> pygame.mixer.music.load(oggfn)
>>>> pygame.mixer.music.load(open(oggfn))
>>>> oggf = open(oggfn)
>>>> pygame.mixer.music.load(oggf)
>>>>
>>>>
>>>>
>>>> cheers,
>>>>
>>>>
>>>>
>>>> On Sat, Jun 14, 2008 at 9:53 AM, Forrest Voight <[EMAIL PROTECTED]> wrote:
>>>> > Thanks!
>>>> >
>>>> > On Fri, Jun 13, 2008 at 7:31 PM, Lenard Lindstrom <[EMAIL PROTECTED]>
>>>> > wrote:
>>>> >> This is interesting. I am having a look at it. No promise it can go into
>>>> >> 1.8.1 though as this is supposed to be a bug fix.
>>>> >>
>>>> >> Lenard
>>>> >>
>>>> >>
>>>> >> Forrest Voight wrote:
>>>> >>>
>>>> >>> This patch re-adds support for playing (and queueing) music from
>>>> >>> python file-like objects.
>>>> >>>
>>>> >>> While support for WAV music streams is still in SDL_mixer svn, there
>>>> >>> is support for mp3, mikmod and other formats already.
>>>> >>>
>>>> >>>
>>>> >>
>>>> >>
>>>> >
>>>>
>>>
>>>
>>> --
>>> Lenard Lindstrom
>>> <[EMAIL PROTECTED]>
>>>
>>>
>>
>
pymusic.diff
Description: Binary data
Re: [pygame] 1.8.1rc1 coming soon... any last minute patches?
Any chance the music from python file-like objects can go in? See conversation "Patch - Re-add music support for file-like objects" for it. Forrest On Wed, Jun 25, 2008 at 8:41 PM, Lamonte(Scheols/Demonic) <[EMAIL PROTECTED]> wrote: > pygame 1.9 pff I'm waiting for Pygame 2.0 B-) > > On Wed, Jun 25, 2008 at 7:21 AM, PyMike <[EMAIL PROTECTED]> wrote: >> >> I can't wait for pygame 1.9 :D Longer as in longer than the 1.8.0 release >> took to come out? >> >> On Wed, Jun 25, 2008 at 5:46 AM, René Dudfield <[EMAIL PROTECTED]> wrote: >>> >>> hi, >>> >>> I think we're almost ready to get 1.8.1rc1 out. Which means about two >>> weeks before pygame 1.8.1 is released (assuming no problems found). >>> >>> The main things I can think of left to do at the moment are: >>> - weird crash on windows tests (to do with surflocks or maybe >>> pygame.image.save). >>> >>> If you have anything else you'd like to get in 1.8.1 please let me know. >>> >>> >>> 1.8.1 is mostly a bug release, and the 1.9 release is going to include >>> a whole bunch of new fun stuff. However 1.9 will probably take longer >>> since there's more new stuff to polish up. >>> >>> >>> cu, >> >> >> >> -- >> - pymike (http://pymike.pyedpypers.org/) > > > -- > Join cleanscript.com Come here for professional PHP coding.
Re: [pygame] Re: Patch to add SDL_gfx support to pygame
I don't see why there would be issues. It would be optional... It wraps 2.0.15. On Wed, Jun 18, 2008 at 6:32 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote: > Weren't there licensing issues. Which version of SDL_gfx does the new module > wrap? Otherwise I say "awesome!" as well. > > Lenard > > > René Dudfield wrote: >> >> awesome! >> >> I haven't seen this before... Maybe the other email didn't make it to >> the mailing list? >> >> Can you please resend the patch? >> >> cheers, >> >> >> On Wed, Jun 18, 2008 at 2:14 PM, Forrest Voight <[EMAIL PROTECTED]> wrote: >> >>> >>> Any interest in this? Shapes with alpha blending would be very nice >>> for simple games. >>> >>> On Sat, Jun 14, 2008 at 10:22 PM, Forrest Voight <[EMAIL PROTECTED]> >>> wrote: >>> >>>> >>>> This patch adds complete support for SDL_gfx primitive drawing to >>>> pygame. It adds a new module named gfx which has many functions to >>>> draw shapes to surfaces. >>>> >>>> The code is complete, but only has limited documentation with no >>>> extended documentation on any of the functions. >>>> >>>> Attached is a patch without the generated reference material >>>> (gfxnoref.diff) and one with reference material (glxref.diff). >>>> >>>> Thanks for any testing or comments! >>>> >>>> > >
Re: [pygame] Patch - Re-add music support for file-like objects
OK, I'll work on unit tests and a version check.
On Mon, Jun 16, 2008 at 11:52 AM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
> Maybe the test could write a sine wave to a StringIO, load it, then use
> get_buffer (sound objects do have get_buffer now, right?*) to check it.
>
> Lenard
>
> * Sorry, I don't have access to latest Python/Pygame at the moment.
>
> Quoting René Dudfield <[EMAIL PROTECTED]>:
>
>> Hi,
>>
>> nice patch! This will be very useful :)
>>
>> Do you know which version of sdl_mixer allows rwops for music
>> (Mix_LoadMUS_RW)? Does it require an SDL_mixer version check?
>>
>> Are you able to make make any unit tests for using file likes with the
>> music mixer? We're using unittests for all new code now, and it'd
>> make us feel more safe about adding it in for the 1.8.1 release.
>>
>> Not really sure how best to test it. I guess just loading the music
>> from different filename, and from a python file object would be ok for
>> now.
>>
>> here's a start on a test for it...
>>
>> data_fname = os.path.join('..', 'examples', 'data')
>> #note, I just added house_lo.ogg to svn.
>> oggfn = os.path.join(data_fname, 'house_lo.ogg')
>>
>> pygame.mixer.music.load(oggfn)
>> pygame.mixer.music.load(open(oggfn))
>> oggf = open(oggfn)
>> pygame.mixer.music.load(oggf)
>>
>>
>>
>> cheers,
>>
>>
>>
>> On Sat, Jun 14, 2008 at 9:53 AM, Forrest Voight <[EMAIL PROTECTED]> wrote:
>> > Thanks!
>> >
>> > On Fri, Jun 13, 2008 at 7:31 PM, Lenard Lindstrom <[EMAIL PROTECTED]>
>> > wrote:
>> >> This is interesting. I am having a look at it. No promise it can go into
>> >> 1.8.1 though as this is supposed to be a bug fix.
>> >>
>> >> Lenard
>> >>
>> >>
>> >> Forrest Voight wrote:
>> >>>
>> >>> This patch re-adds support for playing (and queueing) music from
>> >>> python file-like objects.
>> >>>
>> >>> While support for WAV music streams is still in SDL_mixer svn, there
>> >>> is support for mp3, mikmod and other formats already.
>> >>>
>> >>>
>> >>
>> >>
>> >
>>
>
>
> --
> Lenard Lindstrom
> <[EMAIL PROTECTED]>
>
>
[pygame] Re: Patch to add SDL_gfx support to pygame
Any interest in this? Shapes with alpha blending would be very nice for simple games. On Sat, Jun 14, 2008 at 10:22 PM, Forrest Voight <[EMAIL PROTECTED]> wrote: > This patch adds complete support for SDL_gfx primitive drawing to > pygame. It adds a new module named gfx which has many functions to > draw shapes to surfaces. > > The code is complete, but only has limited documentation with no > extended documentation on any of the functions. > > Attached is a patch without the generated reference material > (gfxnoref.diff) and one with reference material (glxref.diff). > > Thanks for any testing or comments! > > Forrest Voight >
Re: [pygame] Patch - Re-add music support for file-like objects
Thanks! On Fri, Jun 13, 2008 at 7:31 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote: > This is interesting. I am having a look at it. No promise it can go into > 1.8.1 though as this is supposed to be a bug fix. > > Lenard > > > Forrest Voight wrote: >> >> This patch re-adds support for playing (and queueing) music from >> python file-like objects. >> >> While support for WAV music streams is still in SDL_mixer svn, there >> is support for mp3, mikmod and other formats already. >> >> > >
[pygame] Patch - Re-add music support for file-like objects
This patch re-adds support for playing (and queueing) music from python file-like objects. While support for WAV music streams is still in SDL_mixer svn, there is support for mp3, mikmod and other formats already. Cheers, Forrest music.diff Description: Binary data
