right. Before you blit. My bad.
On Mon, Aug 4, 2014 at 6:03 PM, Greg Ewing
wrote:
> Berlioz Silver wrote:
>
>> You want pixels2d, which gives you a variable which _references_ the data.
>>
>
> Yes, sorry, I got it the wrong way round. You need to start
> with a normal surface that you can blit
Berlioz Silver wrote:
You want pixels2d, which gives you a variable which _references_ the
data.
Yes, sorry, I got it the wrong way round. You need to start
with a normal surface that you can blit into, and then use
pixels2d to create a numpy view of it that you can pass
directly to OpenGL.
Wh
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 t
You want pixels2d, which gives you a variable which _references_ the data.
While the reference is still there, the surface is locked (otherwise you
could change the data mid-blit, which would be bad). Instead, you should
use:
del (variable with pixels2d in it)
right before you pass it off to GL o
Ok I now create my texture once.
I'm having some issues with this
> You're creating an extra copy of the texture data here.
> To avoid that, you could use surfarray to create a surface
> backed by a numpy array, do your drawing into that, and
> then pass the numpy array directly to glTexImage2D.
sylvain.boussekey wrote:
> I managed to do it in opengl but perfs are poor.
A few things to consider:
> textureData = pygame.image.tostring(textureSurface, "RGBA", 1)
* You're creating an extra copy of the texture data here.
To avoid that, you could use surfarray to create a surface
bac
Jeffrey Kleykamp wrote:
On my not so fast computer, I acheive 400FPS, which is useless but a
good indicator to know how many sprites I can draw simultaneously.
Are you clearing and redrawing the whole screen each frame,
or just drawing the areas where sprites have moved?
If the latter,
Well you might be able to scroll for some speedup. If everything is moving
in the same general direction then scroll the biggest thing (like the
background) and redraw everything else and the edges.
On Tue, Jul 29, 2014 at 11:02 AM, sylvain.boussekey <
sylvain.bousse...@vertpingouin.fr> wrote:
>
I have an asynchronous rendering function.
My game does logic updates at a fixed rate.
Rendering is done as fast as it can, possibly fps limited by a
pygame.time.Clock with interpolated position for sprites.
I'm actually drawing everything every frames because everthing is
moving constantly movi
I still don't understand what you are doing in the first place. Are you
taking a bunch of frames of art and running them as a movie? Do you really
have 60 frames of art per second? If not, then there's no reason to redraw
everything each frame. Only redraw when something changes. Or, redraw only
th
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(s
vertpingouin,
If you are doing that every frame as part of the sprite's .draw or .update
method , it's 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
to Sam :
I'm using HWSURFACE flag but I got exatly the same framerate. The ideal
would be to rewrite everything in openGL but I don't know it well...
yet.
to Noel:
On the topic of performing transform one time only, I'm not sure what
mean here. If I scale my surface one time, it gets, say, 1920x1
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
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 don't know how to achieve it.
>
> Anyone has already done this ?
>
You would just need to code the graphics in OpenGL without using
pygame.
Hi everyone,
I try to make a little 2d engines for my needs. I use the gameobject
library which bring me to a really really decent frame rate (between 400
and 2000 FPS depending on the computer). But I wanted to do some
beautiful pixel art so every frame, I pygame.transform.scale my 640 x
480
16 matches
Mail list logo
