[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] Extending OpenGL support in Pygame
On 12-04-05 12:00 PM, Santiago Romero wrote:
> YES! Very much! In my personal opinion, the lack of simple drop-in
> OpenGL support that works the same way as the existing Surface class is
> the biggest weakness of pygame.
I don't have knowledge about OpenGL but if I remember correctly,
textures (because with opengl your sprites need to be "faces" with
textures, simulating the sprite itself) must be power of 2 in size
(16x16, 32x32, 64x64, 128x128...).
This introduces a "handicap" in the sprite sizes that maybe can't
allow "simple drop-in" Surface-class replacement...
But, yes, I also agree that the advantages are very important,
specially that GPU rendering would allow really hi-res (hdready and
fullhd games, even with multiple scrolls!) even in limited hardware
(CPU power systems) such as tablets, and so on.
Modern OpenGL systems can often handle Non-Power of Two textures (there
are ARB extensions for this, and an ATI extension for rectangular
textures), but for something like Pygame sprites you'd likely do a POT
texture catalogue and pack your NPOT textures into that, using offsets
into the catalog texture to get the correct sprite rendered for a given
polygon (saves switching out the texture all the time as you render,
which is a non-trivial performance hit, and allows you to render all of
the geometry using the catalog (i.e. hundreds or thousands of sprites)
in a single GL call).
Movies need special handling.
To be particularly useful, such a port should likely target
approximately the GLES2.0 subset of OpenGL, btw.
HTH,
Mike
--
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com