Re: [pygame] GSoC Proposal

[René Dudfield <renesd@xxxxxxxxx>]

hi,

that sounds pretty cool.

you are right in that It's kind of been done before a few times...

Lamina is usable... but not really all that fast.  It works at the
surface level.  Not all that fast, since almost everything is done
with software anyway, and is sent to a back buffer - which gets sent
to opengl.  This is especially nice if you want to use pygame inside
an opengl application -- especially useful to use pygame gui libs like
pgu etc.

There is an unfinished spritegl module floating around... which
doesn't really work all that well.  This works at the sprite level.
Which should theoretically allow a pretty fast implementation.


Then there's SDL 1.3 which includes opengl, and direct3d renderers.
However they use a separate Texture object, rather than using surfaces
-- so it's not really the ultimate solution.

I think something that works at the sprite level, and at the surface
level would be pretty good.  That is combining the Lamina, and
spritegl approaches.


Note, also Lennard has just added a scroll method to Surface(in pygame
1.9.0pre release) which allows you to do fairly fast scrolling with
pygame.  It makes it easy to use the already built in(but buggy with
some versions of SDL) ability to blit a surface onto itself.


cu,



On Sat, Mar 21, 2009 at 3:50 PM, Casey <spintriae@xxxxxxxxx> wrote:
> Hi team,
>
> I'm Casey, a student of computer science and computer game design at UC
> Santa Cruz beginning this fall. For game programming, I've been using
> Allegro for a few years now, I've gained some experience with SDL and XNA in
> the last year, and I've been using pygame for about 6 months. I greatly
> prefer Python to C/C++/C#, but pygame has some drawbacks that prevent me
> from making a total transition right away. To explain, first a few things
> about my approach to game design:
>
> * I tend to code retro-style 2D games in low resolutions: 320x240 or
> 640x480.
> * Fullscreen mode is excessive for these types of games, so I never use it.
> * Low resolution games can be unplayable in windowed mode, so I stretch the
> buffer, and apply scale2x if it suits the graphics.
>
> Because pygame doesn't support hardware acceleration in windowed mode, I'm
> stuck with software rendering, which is super slow for side-scrollers where
> dirty rectangles are not an option. The console style platformer and RPG
> engines I'm working on get an average of 30-45 FPS on most hardware, and I
> have yet to see them run at the full refresh rate on any of the hardware
> I've tested them on.
>
> To address these issues, I would like to code a library that overloads
> pygame's graphics modules with OpenGL enhanced ones. I know that some 2D
> OpenGL libraries exists, but none of them do what I would like them to, and
> what I think would be most beneficial to the community, which is to play
> nice with existing code.
>
> What I'm proposing is essentially a wrapper, with which one could
> theoretically take any existing game, add the line "from [proposed
> library].locals import *", set the mode to OPENGL, and it would run exactly
> as expected with improved OpenGL powered rendering. Of course, that might
> not be possible for all code (it depends on how it's written), but the
> fundamental idea is to make learning and implementing the proposed library
> as painless as possible.
>
> Before I elaborate any further, I'll leave this open to questions and
> comments. If anything is not clear, let me know.
>
> To conclude, I've been thinking about this for a while now and I'm confident
> I could implement it within the GSoC timeframe. Also, I would be pleased to
> continue to maintain it when the summer is over, since I would undoubtedly
> be applying it to my personal and academic projects.
>
> Looking forward to comments and suggestions...
>
> Casey
>