Just a warning, glBegin(), glEnd() is deprecated, and so you know it's an old tutorial.
Have you tried SFML's python binding? It's a bit like Pygame, and abstracts the OpenGL functions for you. On Tue, Jul 29, 2014 at 7:38 AM, sylvain.boussekey < sylvain.bousse...@vertpingouin.fr> wrote: > I tried that with almost no perf gain. > I managed to do it in opengl but perfs are poor... The only advantage is > that there is almost no fps differences when increasing resolution. But > still framerate is poor. Here is roughly what I do (without knowing what I > do really)e : > > def openglblit(self, surf): > textureSurface = surf > > textureData = pygame.image.tostring(textureSurface, "RGBA", 1) > > width = textureSurface.get_width() > height = textureSurface.get_height() > > texture = glGenTextures(1) > glBindTexture(GL_TEXTURE_2D, texture) > glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST) > glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST) > glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, > GL_UNSIGNED_BYTE, textureData) > > glClear(GL_COLOR_BUFFER_BIT) > > glBindTexture(GL_TEXTURE_2D, texture) > glBegin(GL_QUADS) > glTexCoord2d(0,1) > glVertex2d(-1,1) > glTexCoord2d(0,0) > glVertex2d(-1,-1) > glTexCoord2d(1,0) > glVertex2d(1,-1) > glTexCoord2d(1,1) > glVertex2d(1,1) > > glEnd() > glFlush() > > glDeleteTextures(texture) > > But it seems that the conversion between pygame surface and opengl tex is > slow. > Argh !! I will really need to go full opengl if I want better perfs... > sad... > > > Le 2014-07-28 23:14, Noel Garwick a écrit : > >> vertpingouin, >> >> If you are doing that every frame as part of the sprites .draw or >> .update method , its still possible the transform is what is taking up >> >> CPU time. You may want to use something like this instead: >> >> class MySpriteThing( pygame.sprite.Sprite): >> image = None >> def __init___( self ): >> >> ..... >> if MySpriteThing.image is None: >> MySpriteThing.image = pygame.image.load( "foo.png" ) >> size = MySpriteThing.image.get_size() >> new_width = size[0] * X_SCALE # where X_SCALE is the >> ratio between RESOLUTION_X (the big resolution) and GRAPHICS_X (the >> resolution the images were made at) ; ( 1920 / 640 ) >> new_height = size[1] * Y_SCALE >> MySpriteThing..image = pygame.transform.scale( >> self.image, ( new_width, new_height ) ) >> >> self.image = MySpriteThing.image >> >> ........ >> >> # then, in your main loop, blit the sprites .image attribute to your >> >> display surface >> >> mySpriteGroup.draw( screen ) >> >> pygame.display.update() >> >> On Mon, Jul 28, 2014 at 4:41 PM, vertpingouin >> <sylvain.bousse...@vertpingouin.fr [3]> wrote: >> >> to Sam : >>> >>> Im using HWSURFACE flag but I got exatly the same framerate. The >>> ideal >>> would be to rewrite everything in openGL but I dont know it well... >>> yet. >>> >>> to Noel: >>> On the topic of performing transform one time only, Im not sure >>> >>> what >>> mean here. If I scale my surface one time, it gets, say, 1920x1080, >>> but >>> then blitting is done only of a 640x480 part of the surface... So >>> maybe >>> I misunderstood something here. >>> >>> Im using this to transform : >>> >>> pygame.transform.scale(self.native, (SCREENWIDTH, SCREENHEIGHT), >>> self.screen) >>> >>> where native is the little one and screen the big one. I assume >>> that >>> self.native is scaled then blit onto self.screen... >>> >>> I think this is the blitting that is slow because if I use a lesser >>> resolution for self.screen, I almost get back my precious frames >>> per >>> second. >>> >>> It will be really cool to send my little native surface to my >>> graphic >>> card, then let it scale by itself. Dont know if its even possible. >>> >>> >>> Le lundi 28 juillet 2014 à 11:50 -0400, Noel Garwick a écrit : >>> >>> Right now you are blitting tiles to a 640x480 surface, and then >>>> >>> > performing a transform on the whole surface and then blitting it >>> to >>> > the display? >>> > >>> > >>> > If this is the case, then try to only perform the scale operation >>> when >>> > the resolution is changed (instead of once each frame) and see >>> how >>> > that works. I know you mentioned that the full screen blit >>> operation >>> > seems to be the main bottleneck, but this should help too. >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > On Mon, Jul 28, 2014 at 7:32 AM, Sam Bull <sam.hack...@sent.com >>> [1]> >>> >>> > wrote: >>> > On lun, 2014-07-28 at 06:54 +0200, VertPingouin >>> wrote: >>> > > So I came up with the idea of an hardware opengl >>> texture >>> > stretching >>> > > instead of a dumb blit but I dont know how to >>> >>> achieve it. >>> > > >>> > > Anyone has already done this ? >>> > > >>> > >>> > >>> > You would just need to code the graphics in OpenGL >>> without >>> > using >>> > pygame.Surface and pygame.draw. First though, check >>> you are >>> > using the >>> > HWSURFACE flag, if you are running fullscreen, its >>> >>> possible >>> > this might >>> > provide the necessary speedup without going to >>> OpenGL. >>> > >>> > >>> http://www.pygame.org/docs/ref/display.html#pygame.display.set_mode >>> [2] >>> > >>> > >>> >> >> >> >> Links: >> ------ >> [1] mailto:sam.hack...@sent.com >> [2] http://www.pygame.org/docs/ref/display.html#pygame.display.set_mode >> [3] mailto:sylvain.bousse...@vertpingouin.fr >> > > -- Jake
