Re: [pygame] Re: GSoC

[René Dudfield]

Hi,

sorry, pygame is not doing gsoc this year.


On Fri, Apr 8, 2011 at 6:52 AM, Nikhil Murthy  wrote:

> I am really sorry for the blank e-mail before, and I am also sorry that I
> am writing in so late, but as I would like to work on bringing it to
> Android, is Pygame taking GSoC applications this year?
>
> On Fri, Apr 8, 2011 at 11:19 AM, Nikhil Murthy wrote:
>
>>
>>
>> --
>> Nikhil Murthy
>>
>
>
>
> --
> Nikhil Murthy
>

Re: [pygame] Re: GSoC

[Adam Bark]

On 22/01/11 23:10, Ian Mallett wrote:
On Sat, Jan 22, 2011 at 3:48 PM, Sam Bull > wrote:


I only know a tiny bit of OpenGL, and I was wondering if anybody who
knows some OpenGL programming could answer a question, to help me
prepare.
   In order for me to produce these widgets in OpenGL, does
OpenGL provide
functions to draw 2D shapes onto the screen in front of the 3D view
(like a HUD), or do these have to be drawn in 3D and anchored to the
camera or something?.

Thanks,
Sam Bull

Graphics hardware works by transforming points (vertices) by three 
matrices (model, view, projection, although OpenGL combines the model 
and view matrices).  Then, the points are connected by pixels 
(rasterization).  So yes, change the matrices, and you change how what 
you see works.



To do a 3D view:

glMatrixMode(GL_PROJECTION)
glLoadIdentity()
gluPerspective(...)
glMatrixMode(GL_MODELVIEW)
glLoadIdentity()

gluLookAt(...)

#draw world


To do a 2D view:

glMatrixMode(GL_PROJECTION)
glLoadIdentity()
glOrtho(...) or gluOrtho2D(...)
glMatrixMode(GL_MODELVIEW)
glLoadIdentity()

#draw HUD


Ian
Although Ian's code is good you perhaps shouldn't be going down the old 
fixed function pipeline route. OpenGL 3 has already deprecated quite a 
bit of the fixed function and shaders have been available since, I 
believe, openGL 1.5. It's all on the pyopengl and opengl websites anyway.


Adam.

Re: [pygame] Re: GSoC

[Greg Ewing]

Ian Mallett wrote:


To do a 2D view:

glMatrixMode(GL_PROJECTION)
glLoadIdentity()
glOrtho(...) or gluOrtho2D(...)
glMatrixMode(GL_MODELVIEW)
glLoadIdentity()


You'll also probably want to turn off depth testing, lighting, etc.
if you previously had them enabled for the 3D view.

--
Greg

Re: [pygame] Re: GSoC

[Ian Mallett]

On Sat, Jan 22, 2011 at 3:48 PM, Sam Bull  wrote:

> I only know a tiny bit of OpenGL, and I was wondering if anybody who
> knows some OpenGL programming could answer a question, to help me
> prepare.
>In order for me to produce these widgets in OpenGL, does OpenGL
> provide
> functions to draw 2D shapes onto the screen in front of the 3D view
> (like a HUD), or do these have to be drawn in 3D and anchored to the
> camera or something?.
>
> Thanks,
> Sam Bull
>
Graphics hardware works by transforming points (vertices) by three matrices
(model, view, projection, although OpenGL combines the model and view
matrices).  Then, the points are connected by pixels (rasterization).  So
yes, change the matrices, and you change how what you see works.


To do a 3D view:

glMatrixMode(GL_PROJECTION)
glLoadIdentity()
gluPerspective(...)
glMatrixMode(GL_MODELVIEW)
glLoadIdentity()

gluLookAt(...)

#draw world


To do a 2D view:

glMatrixMode(GL_PROJECTION)
glLoadIdentity()
glOrtho(...) or gluOrtho2D(...)
glMatrixMode(GL_MODELVIEW)
glLoadIdentity()

#draw HUD


Ian

Re: [pygame] Re: GSoC project proposal: Pygame on rails

[Evan Kroske]

On Sat, Mar 20, 2010 at 5:37 PM, Marcus von Appen  wrote:
> On, Mon Mar 08, 2010, Evan Kroske wrote:
>
>> I wrote a blog entry about my idea that contains a more complete
>> explanation of why I want to create this framework and what I hope it
>> will accomplish. Check it out here:
>> http://welcome2obscurity.blogspot.com/2010/03/gsoc-project-idea-insta-pygame.html
>
> I do not think that a higher-level abstraction framework would make much
> sense as a GSoC task for Pygame itself, mainly because
>
> - different games have different needs
> - developers have different ideas about the *how*, you mention
> - keeping the framework generic enough to have a benefit for >=60-70% of
>  the developer base will be an impossible task and lower its usage
> - ...
>
> Another problem is the range of your approach. From your example, the
> system will include a scene manager, sprite engine, tile loader and
> management, UI, event and action system, object logic, and, and, and...
> Though it's possible to implement all those features, they would also be
> able to cover some rough basics, making them mostly unusable for
> advanced usage scenarios and less appealing for more complex
> applications and games.
>
> Personally, I'm not that happy with that idea for a GSoC :-).
>
> Regards
> Marcus
>

Thanks for the frank evaluation of my proposal. In retrospect, my
project obviously doesn't line up with PyGame's goals , but I was too
excited about the possibilities to think it through. Thanks for saving
me the effort!

-- 
Evan Kroske
http://welcome2obscurity.blogspot.com/
The personal blog of Evan Kroske,
novice software developer.

Re: [pygame] Re: GSoC project proposal: Pygame on rails

[Marcus von Appen]

On, Mon Mar 08, 2010, Evan Kroske wrote:

> I wrote a blog entry about my idea that contains a more complete
> explanation of why I want to create this framework and what I hope it
> will accomplish. Check it out here:
> http://welcome2obscurity.blogspot.com/2010/03/gsoc-project-idea-insta-pygame.html

I do not think that a higher-level abstraction framework would make much
sense as a GSoC task for Pygame itself, mainly because

- different games have different needs
- developers have different ideas about the *how*, you mention
- keeping the framework generic enough to have a benefit for >=60-70% of
  the developer base will be an impossible task and lower its usage
- ...

Another problem is the range of your approach. From your example, the
system will include a scene manager, sprite engine, tile loader and
management, UI, event and action system, object logic, and, and, and...
Though it's possible to implement all those features, they would also be
able to cover some rough basics, making them mostly unusable for
advanced usage scenarios and less appealing for more complex
applications and games.

Personally, I'm not that happy with that idea for a GSoC :-).

Regards
Marcus


pgp2JcqZdd4M9.pgp
Description: PGP signature

Re: [pygame] Re: GSOC project proposal: Finishing the movie module

[Patrick Mullen]

I would love to see this!

On Sun, Mar 7, 2010 at 8:00 AM, Tyler Laing  wrote:

> Oh another critical bug: a lack of subtitle support! (Well, critical to me)
>
> -Tyler
>
>
> On Sun, Mar 7, 2010 at 7:46 AM, Tyler Laing  wrote:
>
>> Hello all!
>>
>> So I am applying again this year, to properly finish my project last year.
>>
>>
>> The movie module was largely finished in last year's GSoC project,
>> however, it wasn't quite ready for release, with a few bugs and not
>> compiling on windows.
>>
>> My proposal is to fix up those bugs, get it compiled on windows and polish
>> it up for general release.
>>
>> The bugs were if I recall correctly:
>> -Sometimes desyncs
>> -memory leaks
>> -slow performance for SDL screens.
>> ...various other as-yet undiscovered bugs
>>
>> In addition, I'd be able to fix and complete the alternative video
>> players.
>>
>> Thank you in advance,
>>
>> --
>> Tyler Laing
>> Science and Tech Editor
>> The Phoenix Newspaper
>> (1) 250 863-4869
>>
>> University of British Columbia - Okanagan
>>  University Way
>> Kelowna, BC UNC 109
>> Student Services Building
>>
>
>
>
> --
> Tyler Laing
> Science and Tech Editor
> The Phoenix Newspaper
> (1) 250 863-4869
>
> University of British Columbia - Okanagan
>  University Way
> Kelowna, BC UNC 109
> Student Services Building
>

Re: [pygame] Re: GSoC A* for AI

[Marcus von Appen]

On, Thu Apr 02, 2009, Orcun Avsar wrote:

> yes, but these should be general methods. AI is a very large case but
> these must be AI modules like path finding that many users should
> need. otherwise it serves only for special purposes. what do you
> advice for general AI demands?

Evaluate, discuss and implement other AI parts, such as automated field
generations, agent-based systems and state machines, adaptive AI basics,
automated weight tables for AI algorithms and agent systems, simple
graphs (kd, rb, etc.) and and and...

As AI is such a broad field, it is constantly discussed controversely.
Take a quick look at the mailing list archive [0] for recent GSoC
related threads about it.

[0] http://www.mail-archive.com/pygame-users@seul.org/msg10914.html
http://www.mail-archive.com/pygame-users@seul.org/msg11061.html
http://www.mail-archive.com/pygame-users@seul.org/msg10949.html

Regards
Marcus


pgpeKPxeIvdZm.pgp
Description: PGP signature

Re: [pygame] Re: GSoC Proposal: Basic gui system

[RB[0]]

I don't think incorporating an existing gui into pygame would work.
Whatever it is you decide to do - it will need to be close enough to pygame
to be worth it (ie, integrated into event loop and such, to make it easy for
new users), abstract enough to allow extendability into a wide range of
needs, and powerful enough to look good and scale to full size applications.
>From my experience, none of the current pgame guis come close to having all
those attributes.
Either they are so abstract that the user has to do almost everything, they
are too powerful to easily extend, or they are just funky in their usage.

But that is yet another decision.
How will events be handled? WIll they be returned like pygame events, or
handled with callbacks? Or both and confuse people/be un-pythonic?
How will it be rendered? Will it simply be an object you send the screen to
at the end of each loop and render then update the screen?
Will it use dirty rects to make the gui fast, or not, so you can use flip?
How many/what widgets do you want to include?
You pointed out how you would take the best 2 or 3 - well that is it, there
is so much variance, and no gui I have seen that would be abstract enough to
be useable for this claims to be everything you might/will need.
I think most likely you would have a ton of different people chiming in, and
in the end you might get 2 or 3 highest rated, but none would get a majority
and it would probably fall apart before it even started...

I agree with Sky, it is simple to write basic widgets, but once you get into
more advanced stuff it takes time, and lots of it, there are just so many
things to do. It isn't particulartly hard, but time consuming, and difficult
to do "right". I think though updating the pygame wiki with some of the
newer gui's, with a good comparison would probably work better - but if you
do take one and make it work, more pwoer to you, and I am sure a lot of
people will be grateful...

Good luck :)

On Tue, Mar 24, 2009 at 3:11 PM, Jug  wrote:

> If you all think, a lot of people would use a built-in gui but it's
> not worth the work, is there a chance to put one of the existing guis
> into pygame? We could poll the users on the website and/or the mailing
> list about the best pygame gui. Then maybe have a look on the best 2
> or 3, discuss some pros and cons and include one into pygame? Because
> as I said before, one big problem of all of the existing guis is that
> they are at least one more dependency. In addition, new users don't
> have to test all guis and find the best but can have a look at
> pygame.gui and invest more time to understand it. I'm really tired
> from reading up on guis (used 2 and began to read about Albow). A
> pygame.gui module would get much more support (bug fixes, new ideas/
> widgets, etc.) than now, too.
>
> Regards,
> Jug
>

Re: [pygame] Re: GSoC Student

[Marcus von Appen]

On, Thu Mar 19, 2009, Tyler Laing wrote:

> Ah, apologies, I hadn't fully read the mailing list before I posted
> this.
> 
> Pygame for Python 3 is pgreloaded, which I presume has active
> developers.

Right. Me and my exceptional one-man-show :-).
 
> For the font and image support, there appears to already be a
> volunteer for that.

Note that those are two tasks as stated on the ideas page[0].  The one
covers improved font support, the other improved image and graphics
format support.

If you are unsure about whether others want to work on the same task,
but are really eager to do it, you can provide an application for it
anyways. Chances that one of you both is then accepted for that task
will be lower (not to say there will be none to have bot working on that
task :-), so it might be a good thing to contact us and the other
applicant in question to find some agreement or alternative task to work
on.
 
> But I would still like to work on the movie support. If there are any
> other ideas that could be done over the summer, I would like to hear
> them.

If you have own ones, feel free to submit them. You are not limited to
the ideas list.

[0] http://pygame.org/wiki/gsoc2009ideas

Regards
Marcus


pgpgtmDljF6u2.pgp
Description: PGP signature

Re: [pygame] Re: GSoC Student

[René Dudfield]

hi,

ffmpeg support would be great.  Perhaps using this library:
http://www.arjanhouben.nl/SDL_ffmpeg/

py3k is probably not too much work.  It took Marcus only a few days I think
to convert pgreloaded - probably less, so not a full 3 months work.

Feel free to email me your draft application, and I can help you with it.


cheers,


On Thu, Mar 19, 2009 at 10:05 AM, Tyler Laing  wrote:

> Ah, apologies, I hadn't fully read the mailing list before I posted
> this.
>
> Pygame for Python 3 is pgreloaded, which I presume has active
> developers.
>
> For the font and image support, there appears to already be a
> volunteer for that.
>
> But I would still like to work on the movie support. If there are any
> other ideas that could be done over the summer, I would like to hear
> them.
>
> -Tyler
>
> On Mar 18, 3:49 pm, Tyler Laing  wrote:
> > Hello everyone.
> >
> > My name is Tyler, a third year computer science student at UBC-Okanagan.
> I
> > started programming with python, even developing a simple game in Tkinter
> > before I found pygame. I've been programming in Python for almost 6 years
> > now, giving me a lot of experience and knowledge about the intricacies of
> > Python. In recent years, I've been learning C, and feel confident enough
> > about my skill with C to be able to contribute usefully. I have previous
> > experience working with python integrated into a C app(Nakedmud), as well
> as
> > some development experience(very minor) for rockbox.org. Most of what I
> > contributed to rockbox.org was access to a specific mp3 player, as well
> > decompilation information from the firmware.
> >
> > After looking at all the available choices, I would like to do one of the
> > three following projects:
> >
> > 1) Begin work on porting Pygame to Python 3, if it hasn't already been
> > started.
> > This would involved updating all the c modules to the new api changes and
> > updating all the internal python code to Python 3 format.
> > However, this could be a rather large project to undertake.
> >
> > 2) Add decent movie support using ffmpeg
> > While this is listed in the Hard tasks section, it sounded very
> interesting
> > to me. This would vastly improve my c skills, while contributing
> something
> > very useful to pygame.
> > This would require gaining a passing familiarity with ffmpeg's library,
> its
> > functions, and how they work in a multi-threaded environment. In
> addition, I
> > would also have to design an api for use in pygame for the movie support.
> >
> > 3) Improve font and image support in pygame.
> > This is likely the simplest task of the three. It would require studying
> the
> > documentation for the formats, learning the pygame internal structures
> for
> > these formats, and creating loaders and savers from those internal
> > structures.
> >
> > Thank you for your time, and please let me know if you would like to
> mentor
> > me, and which project would be best for me to undertake.
> >
> > -Tyler
> >
> > --
> > Visit my blog athttp://oddco.ca/zeroth/zblog
>