Re: [pygame] GSoC

[Zack Baker]

GSOC=Google summer of code

-Zack

On Feb 21, 2012, at 4:36 PM, Sam Bull  wrote:

> GSoC 2012 was recently announced. I was just wondering if anybody knows
> if Pygame will make it into this year's GSoC? I'd quite like to do a
> project for GSoC, but am only likely to do so if Pygame is accepted.
> 
> Thanks,
> Sam Bull

Re: [pygame] GSoC

[Sam Bull]

Thanks to everyone who joined in this discussion, it was very helpful.

I think I will go with Casey's idea, and support both methods, leaving
it to the user to decide which method to use.

Thanks,
Sam Bull

On Mon, 2011-02-07 at 12:34 -0700, Casey Duncan wrote:
> On Feb 6, 2011, at 9:37 PM, David Burton wrote:
> 
> > On Sun, Feb 6, 2011 at 4:42 PM, Greg Ewing  
> > wrote:
> > David Burton wrote:
> > 
> >  (That's because, if you are an experienced programmer, you have learned 
> > [probably the hard way] that you really don't want to start anything 
> > complicated in response to a click if you're deep in the bowels of the GUI 
> > code [which has called your callback function], since the complicated thing 
> > you start might want to /use/ that same GUI code, and get button clicks and 
> > menu choices of its own, leading to ever deeper recursion in the [hopefully 
> > reentrant!] GUI code, and mind-bending complexity and bugs.)
> > 
> > I can't really see how using events helps with that, because if
> > there's a complicated thing to be done, it needs to be done somehow
> > or other, and either way it's being done by a piece of code being
> > called from the event loop, which will hold up the GUI until it's
> > finished.
> > 
> > The difference is that with callbacks your application code is not called 
> > from the event loop, it is called from somewhere deep inside the GUI code.
> > 
> > With pygame events, your application code doesn't even see the button-click 
> > or whatever until the GUI coded has finished and exited, so the application 
> > author doesn't have to worry about what can go wrong if he tries to do more 
> > user interactions at that point.
> > 
> > With callbacks, if, when your application gets a button clock or whatever, 
> > it then tries to do more user interactions, it will be reentering the GUI 
> > code for a new user interaction from deep within the GUI code itself, 
> > because the GUI code hasn't yet returned from processing the previous user 
> > interaction, because the callback from the application code hasn't 
> > returned.  When the second user interaction gets its result, and makes its 
> > callback to the application, both the application and the GUI are now 
> > reentrant!  Two different callbacks are now simultaneously active, and 
> > there's no guarantee that the application code won't want to ask the user 
> > another question, causing a third level of reentrancy...  and so forth and 
> > upward and onward, gee whiz!
> 
> IMHO callbacks vs. events are an architecture opinion that a library should 
> not force upon an application. It seems to me like little extra work to 
> support both. Actually it is pretty easy to imagine building event support 
> simply on top of callbacks. All the callbacks would do is post events.
> 
> Forcing simple apps to always use events though sounds like a loss. There are 
> plenty of games where the added complexity of events buys you nothing, and 
> just makes the code more complex and harder to follow. In more complex GUI 
> apps, events can be a win, or folks might just prefer that approach over 
> callbacks. So making the library non-religious on this issue would be a good 
> thing.
> 
> -Casey
> 



signature.asc
Description: This is a digitally signed message part

Re: [pygame] GSoC

[Lenard Lindstrom]

Entered as Issue 62 at Pygame issue tracker.

Lenard Lindstrom

On 06/02/11 03:35 PM, David Burton wrote:

Aha!  Thanks for this info, Greg and Lenard!!

Also, thanks, Lendard, I do think this is worth opening an issue about.

It seems that it is not a .dict() method, but a .dict attribute.  It 
appears to be almost the equivalent of dir(), lacking the .type entry, 
but including the other attributes that matter:


Python 3.1.3 (r313:86834, Nov 27 2010, 18:30:53) [MSC v.1500 32 bit 
(Intel)] on win32

Type "copyright", "credits" or "license()" for more information.
>>> import pygame
>>> ev = pygame.event.Event( pygame.USEREVENT, {'id':'test', 
'internal':False} )

>>> dict(ev)
Traceback (most recent call last):
  File "", line 1, in 
dict(ev)
TypeError: 'Event' object is not iterable
>>> ev.dict()
Traceback (most recent call last):
  File "", line 1, in 
ev.dict()
TypeError: 'dict' object is not callable
>>> ev.__dict__
Traceback (most recent call last):
  File "", line 1, in 
ev.__dict__
AttributeError: event member not defined
>>> ev.dict
{'internal': False, 'id': 'test'}
>>>

Re: [pygame] GSoC

[Greg Ewing]

Casey Duncan wrote:


IMHO callbacks vs. events are an architecture opinion that a library should
not force upon an application. It seems to me like little extra work to support
both.


For what it's worth, the event style can easily be used in Albow
if you want, by installing a callback that schedules a function
to be called after a delay of 0. This will ensure that it happens
after all processing of the current event is finished, but before
processing any other events.

--
Greg

Re: [SPAM: 3.100] Re: [pygame] GSoC

[Greg Ewing]

David Burton wrote:

Some dialogs have a "backing out" operation (the "close" button, or the 
"ok" button, or whatever).  But many don't.


If it's a *modal* dialog, it *has* to have some way of backing
out. Conversely, if it doesn't, it has to be non-modal.

But if the GUI is structured to use callbacks, then the button click 
code /*is still running*/, seconds or minutes later, when the user is 
adjusting the slider.


No, it's not, because in the non-modal case, the only thing the
button callback does is make the window with the sliders in it
appear, then it *returns*. By the time the user clicks on the
slider, the button callback is ancient history just the same.

To implement the interaction non-modally using events, the
handler for the button-click event has to obey the same
restriction -- i.e. it must simply make the window appear, and
do nothing further. If it tries to wait for any more input
itself, then you still have a nested event loop, and nothing
has really changed.

Non-modal using callbacks:

  Main event loop receives mouse down in button
Button callback makes option adjustment window visible
  Main event loop receives mouse down in slider
Slider callback changes game state

Non-modal using events:

  Main event loop receives mouse down in button
Button callback posts button-click event
  Main event loop receives button-click event
Button-click handler makes option adjustment window visible
  Main event loop receives mouse down in slider
Slider callback posts slider-click event
  Main event loop receives slider-click event
Slider-click handler changes game state

There's no more nesting one way than the other, and the event
version is more complicated.

Modal using callbacks:

  Main event loop receives mouse down in button
Button callback makes option adjustment window visible
  Nested event loop receives mouse-down in slider
Slider callback changes game state

Non-modal using events:

  Main event loop receives mouse down in button
Button callback posts button-click event
  Main event loop receives button-click event
Button-click handler makes option adjustment window visible
  Nested event loop receives mouse-down in slider
Slider callback posts slider-click event
  Nested event loop receives slider-click event
Slider-click handler changes game state

Again, they're both equally nested, and the event
version is more complicated.

So I maintain that the key difference is not callbacks vs.
events, but modal vs. non-modal. If you have a nested event
handling structure, switching from callbacks to events *on
its own* doesn't change the fact that it's nested.

To get rid of the nesting, you have to restructure things
so that the interaction is non-modal -- and you can do that
just as effectively and more simply using direct callbacks,
without any need to involve events.


That represents a mismatch between how the user uses the UI and how the code
implements it, which is a dead giveaway of a structural problem.


The structures I've described do match the way the user thinks.
If the interaction is modal, the user thinks of it as a nested
activity, and this is reflected in the nested structure of the
code. If it's non-modal, the user doesn't think of it as nested,
and the code structure is flat.

--
Greg

Re: [SPAM: 3.100] Re: [pygame] GSoC

[Casey Duncan]

On Feb 7, 2011, at 2:15 PM, David Burton wrote:

> On Mon, Feb 7, 2011 at 3:52 PM, Greg Ewing  
> wrote:
> David Burton wrote:
> 
> So if the GUI toolkit  uses callbacks to communicate its results to the 
> application code, then when one of those callbacks into the application gets 
> called, it's nested something like this:
> 
> main / event-loop sees mouse click, calls
> -> GUI toolkit event notification code, calls
> -> button widget event notification method, calls
>  -> application callback for the button click
>  
> Now we're back in application code.  It gets the (for example) button click 
> callback, which tells it that the user wants to (for example) adjust his game 
> settings.  So the application code calls
> 
>-> an application function to adjust game settings, which calls
> -> GUI toolkit to put up a form with check-boxes and 
> sliders,
> 
> ...which which had better be modal, running its own event loop,
> 
> Yes, this is exactly how modal dialogs are implemented in Albow,
> by recursively calling the main event loop.
> 
> 
>   -> which sees a slider adjustment, and calls
>-> application callback for the slider 
> adjustment
> 
> ...and now we're back in the application, and we know what the user wants of 
> us, but we're a looong way from being able to resume the game!
> 
> If the intent is to pause the game while the user is adjusting the
> options, then this isn't a problem, because you don't want to resume
> the game until the user backs out of the whole dialog.
> 
> Some dialogs have a "backing out" operation (the "close" button, or the "ok" 
> button, or whatever).  But many don't.  There's no backing out of a singleton 
> button.  It just clicks.
> 
> In the above scenario, as far as the user is concerned, the button click has 
> already happened, and it's ancient history by the time the slider adjustment 
> happens.
> 
> If the GUI is structured to use events to report its results, the button 
> click is ancient history to the GUI, too.
> 
> But if the GUI is structured to use callbacks, then the button click code is 
> still running, seconds or minutes later, when the user is adjusting the 
> slider.  It's still down in the bowels of the button's event notification 
> method, calling a callback which hasn't yet returned.
> 
> That represents a mismatch between how the user uses the UI and how the code 
> implements it, which is a dead giveaway of a structural problem.

I'm not sure that I understand this argument. If a button click is going to 
last a very long time, then the application needs to inform the user of this 
(spinner, wait indicator, etc). This probably would only happen if the 
application was making some blocking i/o call, or it's doing some long running 
cpu-intensive operation.

Let's assume for a second that events solve this problem. In a typical 
game-type application how many potentially long-running operations would there 
be relative to all GUI invoked operations in the app? I would argue that the 
common case would be very few, if any. So, if that's true, how hard would it be 
to have the callback for a few operations fire an event? My point being that 
callbacks and events are not mutually exclusive.

It doesn't make sense in general to complicate the common case to accommodate 
the special case. Let the special case be a little harder, and the common case 
be easier. Don't make me decouple everything when I don't want to, but make it 
possible if I do.

The other problem with this argument is the assumption that events solve 
problems like blocking i/o and long running cpu-intensive things on their own. 
They don't. You'll need to call in other tools like: async i/o, 
multiprocessing, etc. (I'm going to steer clear of threads ) And once you 
do that, you can just use a callback again because it can return immediately 
once it kicks off the parallel process, which fires another callback when it's 
done. You can also use events to signal these things, of course, but both are 
viable.

Another thing I hate about event handlers is that they encourage coding 
insanely long if/elif structures that seem just fine in the beginning, but grow 
into monstrosities over time. They too easily become "god functions". There are 
ways around that, but they require more forethought. Callbacks, on the other 
hand tend to encourage nice, short, single purpose functions, which I find 
scale much better.

-Casey

Re: [pygame] GSoC

[Casey Duncan]

That sounds even more complicated than either events or callbacks alone. 

And yes you can pass references to functions (or other python callables) 
around, which is one of the reasons that callbacks are so simple to code in 
Python.

Bear in mind that one person's nice abstraction is another's hair-pulling 
complexity. I can think of instances where having abstract events for various 
GUI interactions would be nice, but if I just want to have a button that 
confirm's an action, or dismisses a very simple "dialog", or even just launches 
the game from the title screen, I'm not sure I want to deal with the added 
complexity and decoupling of events.

There are so many GUI libraries out there for pygame in various states of 
completion, that I think it would be a great benefit if a "built-in" one didn't 
take too many sides. Otherwise you risk a lot of folks just going "meh" and 
rolling their own yet again.

-Casey

On Feb 7, 2011, at 1:11 PM, David Burton wrote:

> Or you could do it the other way around.  Instead of building event support 
> on top of callbacks, by having callback functions which (optionally) post 
> pygame events, you could build callback support on top of events, by posting 
> pygame events which (optionally) contain callback functions.
> 
> In Python, functions are objects, so you can (presumably -- I haven't tried 
> it) put a callback function reference into a GUI-generated pygame event.  
> When the event loop sees a GUI-generated event, it checks for the presence of 
> a 'callback' attribute, and if one exists it would be called.
> 
> That would be an improvement over a regular callback, because the call to the 
> callback function would be deferred until the call-stack into the GUI library 
> had been unwound.
> 
> Dave
> 
> 
> On Mon, Feb 7, 2011 at 2:34 PM, Casey Duncan  wrote:
> 
> IMHO callbacks vs. events are an architecture opinion that a library should 
> not force upon an application. It seems to me like little extra work to 
> support both. Actually it is pretty easy to imagine building event support 
> simply on top of callbacks. All the callbacks would do is post events.
> 
> Forcing simple apps to always use events though sounds like a loss. There are 
> plenty of games where the added complexity of events buys you nothing, and 
> just makes the code more complex and harder to follow. In more complex GUI 
> apps, events can be a win, or folks might just prefer that approach over 
> callbacks. So making the library non-religious on this issue would be a good 
> thing.
> 
> -Casey
> 
> 

Re: [SPAM: 3.100] Re: [pygame] GSoC

[David Burton]

On Mon, Feb 7, 2011 at 3:52 PM, Greg Ewing wrote:

> David Burton wrote:
>
> So if the GUI toolkit  uses callbacks to communicate its results to the
>> application code, then when one of those callbacks into the application gets
>> called, it's nested something like this:
>
>
>> main / event-loop sees mouse click, calls
>
> -> GUI toolkit event notification code, calls
>
> -> button widget event notification method, calls
>
>  -> application callback for the button click
>
>
>
Now we're back in application code.  It gets the (for example) button click
>> callback, which tells it that the user wants to (for example) adjust his
>> game settings.  So the application code calls
>>
>>-> an application function to adjust game settings, which
>> calls
>> -> GUI toolkit to put up a form with check-boxes and
>> sliders,
>>
>> ...which which had better be modal, running its own event loop,
>>
>
> Yes, this is exactly how modal dialogs are implemented in Albow,
> by recursively calling the main event loop.
>
>
>-> which sees a slider adjustment, and calls
>>-> application callback for the slider
>> adjustment
>>
>> ...and now we're back in the application, and we know what the user wants
>> of us, but we're a looong way from being able to resume the game!
>>
>
> If the intent is to pause the game while the user is adjusting the
> options, then this isn't a problem, because you don't want to resume
> the game until the user backs out of the whole dialog.
>

Some dialogs have a "backing out" operation (the "close" button, or the "ok"
button, or whatever).  But many don't.  There's no backing out of a
singleton button.  It just clicks.

In the above scenario, as far as the user is concerned, the button click has
already happened, and it's ancient history by the time the slider adjustment
happens.

If the GUI is structured to use events to report its results, the button
click is ancient history to the GUI, too.

But if the GUI is structured to use callbacks, then the button click code *is
still running*, seconds or minutes later, when the user is adjusting the
slider.  It's still down in the bowels of the button's event notification
method, calling a callback which hasn't yet returned.

That represents a mismatch between how the user uses the UI and how the code
implements it, which is a dead giveaway of a structural problem.

Dave

Re: [SPAM: 3.100] Re: [pygame] GSoC

[Greg Ewing]

David Burton wrote:

Now we're back in application code.  It gets the (for example) button 
click callback, which tells it that the user wants to (for example) 
adjust his game settings.  So the application code calls


-> an application function to adjust game settings, 
which calls
 -> GUI toolkit to put up a form with check-boxes 
and sliders,


...which which had better be modal, running its own event loop,


Yes, this is exactly how modal dialogs are implemented in Albow,
by recursively calling the main event loop.


   -> which sees a slider adjustment, and calls
-> application callback for the slider 
adjustment


...and now we're back in the application, and we know what the user 
wants of us, but we're a looog way from being able to resume the game!


If the intent is to pause the game while the user is adjusting the
options, then this isn't a problem, because you don't want to resume
the game until the user backs out of the whole dialog.

If you want the game to be running while the options are adjusted
"live", so to speak, then I would say you don't want a modal dialog
at all. You want to put up the options window as a non-modal
widget and then return to the main event loop. The game will then
keep running as usual, and callbacks from the sliders, etc. will be
no further down from the main loop than the button callback that
started it all off.

The important thing is to break down a non-modal interaction into
a series of steps, each of which is triggered by one user action
and doesn't need to wait for any further user actions. Once you've
done that, there's no reason not to carry out each step directly
in the callback for the triggering action.

--
Greg

Re: [pygame] GSoC

[Greg Ewing]

DR0ID wrote:

and pushing the events on the pygame event loop could be dangerous 
because it is possible that there are already other events on the queue 
that will change the state of the application (or gui elements) so that 
at the time when your event gets processed it brakes (because the 
application isn't in the state anymore it was when the event was 
posted). This is a very subtle bug and difficult to catch. Not sure how 
to avoid that behavior


You could keep a list of functions waiting to be called, and process
it in the event loop before reading the next event.

I have something like this in Albow. It's more complicated because it
allows you to schedule things to happen at a later time, but if you
use a delay of 0 it has the effect we're talking about.

--
Greg

Re: [pygame] GSoC

[Greg Ewing]

David Burton wrote:

With callbacks, if, when your application gets a button clock or 
whatever, it then tries to do more user interactions, it will be 
reentering the GUI code for a new user interaction from deep within the 
GUI code itself,


Yes, this is the way modal dialogs are implemented in many
GUI frameworks, using a nested event loop, and I've never found
it to be a problem, as long as you really do intend the interaction
to be modal.

If it needs to be non-modal, then you're going to have to break
it up into stages that are called one at a time from the top
level. Then it doesn't make much difference if the first stage
is triggered directly from a button callback or from a handler
for a custom event.

--
Greg

Re: [pygame] GSoC

[David Burton]

Or you could do it the other way around.  Instead of building event support
on top of callbacks, by having callback functions which (optionally) post
pygame events, you could build callback support on top of events, by posting
pygame events which (optionally) contain callback functions.

In Python, functions are objects, so you can (presumably -- I haven't tried
it) put a callback function reference into a GUI-generated pygame event.
 When the event loop sees a GUI-generated event, it checks for the presence
of a 'callback' attribute, and if one exists it would be called.

That would be an improvement over a regular callback, because the call to
the callback function would be deferred until the call-stack into the GUI
library had been unwound.

Dave


On Mon, Feb 7, 2011 at 2:34 PM, Casey Duncan  wrote:

>
> IMHO callbacks vs. events are an architecture opinion that a library should
> not force upon an application. It seems to me like little extra work to
> support both. Actually it is pretty easy to imagine building event support
> simply on top of callbacks. All the callbacks would do is post events.
>
> Forcing simple apps to always use events though sounds like a loss. There
> are plenty of games where the added complexity of events buys you nothing,
> and just makes the code more complex and harder to follow. In more complex
> GUI apps, events can be a win, or folks might just prefer that approach over
> callbacks. So making the library non-religious on this issue would be a good
> thing.
>
> -Casey
>
>

Re: [pygame] GSoC

[Casey Duncan]

On Feb 6, 2011, at 9:37 PM, David Burton wrote:

> On Sun, Feb 6, 2011 at 4:42 PM, Greg Ewing  
> wrote:
> David Burton wrote:
> 
>  (That's because, if you are an experienced programmer, you have learned 
> [probably the hard way] that you really don't want to start anything 
> complicated in response to a click if you're deep in the bowels of the GUI 
> code [which has called your callback function], since the complicated thing 
> you start might want to /use/ that same GUI code, and get button clicks and 
> menu choices of its own, leading to ever deeper recursion in the [hopefully 
> reentrant!] GUI code, and mind-bending complexity and bugs.)
> 
> I can't really see how using events helps with that, because if
> there's a complicated thing to be done, it needs to be done somehow
> or other, and either way it's being done by a piece of code being
> called from the event loop, which will hold up the GUI until it's
> finished.
> 
> The difference is that with callbacks your application code is not called 
> from the event loop, it is called from somewhere deep inside the GUI code.
> 
> With pygame events, your application code doesn't even see the button-click 
> or whatever until the GUI coded has finished and exited, so the application 
> author doesn't have to worry about what can go wrong if he tries to do more 
> user interactions at that point.
> 
> With callbacks, if, when your application gets a button clock or whatever, it 
> then tries to do more user interactions, it will be reentering the GUI code 
> for a new user interaction from deep within the GUI code itself, because the 
> GUI code hasn't yet returned from processing the previous user interaction, 
> because the callback from the application code hasn't returned.  When the 
> second user interaction gets its result, and makes its callback to the 
> application, both the application and the GUI are now reentrant!  Two 
> different callbacks are now simultaneously active, and there's no guarantee 
> that the application code won't want to ask the user another question, 
> causing a third level of reentrancy...  and so forth and upward and onward, 
> gee whiz!

IMHO callbacks vs. events are an architecture opinion that a library should not 
force upon an application. It seems to me like little extra work to support 
both. Actually it is pretty easy to imagine building event support simply on 
top of callbacks. All the callbacks would do is post events.

Forcing simple apps to always use events though sounds like a loss. There are 
plenty of games where the added complexity of events buys you nothing, and just 
makes the code more complex and harder to follow. In more complex GUI apps, 
events can be a win, or folks might just prefer that approach over callbacks. 
So making the library non-religious on this issue would be a good thing.

-Casey

Re: [pygame] GSoC

[David Burton]

On Mon, Feb 7, 2011 at 1:28 PM, DR0ID  wrote:

>
> Hi
>
> " from deep within the GUI code itself"  <-- how does that get called? from
> the event loop?
>

In a typical pygame app, the event loop is simply the outermost level of the
application.  So if the GUI toolkit  uses callbacks to communicate its
results to the application code, then when one of those callbacks into the
application gets called, it's nested something like this:

main / event-loop sees mouse click, calls
-> GUI toolkit event notification code, calls
-> button widget event notification method, calls
 -> application callback for the button click

Now we're back in application code.  It gets the (for example) button click
callback, which tells it that the user wants to (for example) adjust his
game settings.  So the application code calls

-> an application function to adjust game settings, which
calls
 -> GUI toolkit to put up a form with check-boxes and
sliders,

...which which had better be modal, running its own event loop, because
you're now a lg way from the application's main event loop!...

   -> which sees a slider adjustment, and calls
-> application callback for the slider
adjustment

...and now we're back in the application, and we know what the user wants of
us, but we're a looog way from being able to resume the game!  We're
simultaneously inside two callback functions, one for a button and one for a
slider, as well as an unknown number of functions and methods inside the GUI
toolkit, and two different event loops!  The application can't just make the
requested setting change and resume running the game.  It has to return from
the slider's callback, get control back from the GUI toolkit in the button
callback, return from that, and finally get control back in the main event
loop, all before the game can resume.


and pushing the events on the pygame event loop could be dangerous because
> it is possible that there are already other events on the queue that will
> change the state of the application (or gui elements) so that at the time
> when your event gets processed it brakes (because the application isn't in
> the state anymore it was when the event was posted).
>

It's not a problem.  Remember what these events represent: they are
notifications of things that the user did, like "user clicked a button," or
"user entered text," etc..  They are very infrequent compared to things like
mousemotion events.

What's more, like all events, they don't stay in the event queue for long at
all.  If the user clicked a button while moving his mouse across it, a few
mousemotion events might be in the queue, either before or after the
button-click event, but it really doesn't matter. The response to the
button-click is going to look instantaneous to the user, anyhow.  There's no
reason that the application should brake or exhibit some strange bug just
because it processed a few mouse movements before it noticed that a button
had been clicked.

If the application exhibits strange bugs due to other events being processed
before the GUI-generated events, that means it is so delicate &
timing-dependent that it matters if the user clicks a couple of milliseconds
too early or late.

This is a very subtle bug and difficult to catch. Not sure how to avoid that
> behavior (maybe posting the gui internal events at the front of the event
> queue?).
>

It wouldn't matter.  Posting at the front might make the application notice
the button click (or menu choice, or check-box change, or whatever) a couple
of milliseconds earlier.  It matters no more or less than whether the user
clicks a couple of milliseconds earlier or later.


> Therefore I think callbacks are easier to work with. But I'm not entirely
> sure how to handle reentrant calls, if there are any (is the recursion a
> problem at all?). Normally only one user interaction (event) is processed at
> the time. So i wonder:
>
> "When the second user interaction gets its result, and makes *its* callback
> to the application"
>
> How?
>
> Just my opinion.
>
> ~DR0ID
>
>

Re: [pygame] GSoC

[DR0ID]

On 07.02.2011 05:37, David Burton wrote:
On Sun, Feb 6, 2011 at 4:42 PM, Greg Ewing 
mailto:greg.ew...@canterbury.ac.nz>> wrote:


David Burton wrote:

 (That's because, if you are an experienced programmer, you
have learned [probably the hard way] that you really don't
want to start anything complicated in response to a click if
you're deep in the bowels of the GUI code [which has called
your callback function], since the complicated thing you start
might want to /use/ that same GUI code, and get button clicks
and menu choices of its own, leading to ever deeper recursion
in the [hopefully reentrant!] GUI code, and mind-bending
complexity and bugs.)


I can't really see how using events helps with that, because if
there's a complicated thing to be done, it needs to be done somehow
or other, and either way it's being done by a piece of code being
called from the event loop, which will hold up the GUI until it's
finished.


The difference is that with callbacks your application code is 
/not/ called from the event loop, it is called from somewhere deep 
inside the GUI code.


With pygame events, your application code doesn't even see the 
button-click or whatever until the GUI coded has finished and exited, 
so the application author doesn't have to worry about what can go 
wrong if he tries to do more user interactions at that point.


With callbacks, if, when your application gets a button clock or 
whatever, it then tries to do more user interactions, it will be 
reentering the GUI code for a new user interaction from deep within 
the GUI code itself, because the GUI code hasn't yet returned from 
processing the previous user interaction, because the callback from 
the application code hasn't returned.  When the second user 
interaction gets its result, and makes /its/ callback to the 
application, both the application and the GUI are now reentrant!  Two 
different callbacks are now simultaneously active, and there's no 
guarantee that the application code won't want to ask the user another 
question, causing a /third/ level of reentrancy... /and so forth and 
upward and onward, gee whiz !/


Dave



Hi

" from deep within the GUI code itself" <-- how does that get called? 
from the event loop?


and pushing the events on the pygame event loop could be dangerous 
because it is possible that there are already other events on the queue 
that will change the state of the application (or gui elements) so that 
at the time when your event gets processed it brakes (because the 
application isn't in the state anymore it was when the event was 
posted). This is a very subtle bug and difficult to catch. Not sure how 
to avoid that behavior (maybe posting the gui internal events at the 
front of the event queue?). Therefore I think callbacks are easier to 
work with. But I'm not entirely sure how to handle reentrant calls, if 
there are any (is the recursion a problem at all?). Normally only one 
user interaction (event) is processed at the time. So i wonder:


"When the second user interaction gets its result, and makes 
/its/ callback to the application"


How?

Just my opinion.

~DR0ID

Re: [pygame] GSoC

[David Burton]

On Sun, Feb 6, 2011 at 4:42 PM, Greg Ewing wrote:

> David Burton wrote:
>
>   (That's because, if you are an experienced programmer, you have learned
>> [probably the hard way] that you really don't want to start anything
>> complicated in response to a click if you're deep in the bowels of the GUI
>> code [which has called your callback function], since the complicated thing
>> you start might want to /use/ that same GUI code, and get button clicks and
>> menu choices of its own, leading to ever deeper recursion in the [hopefully
>> reentrant!] GUI code, and mind-bending complexity and bugs.)
>>
>
> I can't really see how using events helps with that, because if
> there's a complicated thing to be done, it needs to be done somehow
> or other, and either way it's being done by a piece of code being
> called from the event loop, which will hold up the GUI until it's
> finished.
>

The difference is that with callbacks your application code is *not* called
from the event loop, it is called from somewhere deep inside the GUI code.

With pygame events, your application code doesn't even see the button-click
or whatever until the GUI coded has finished and exited, so the application
author doesn't have to worry about what can go wrong if he tries to do more
user interactions at that point.

With callbacks, if, when your application gets a button clock or whatever,
it then tries to do more user interactions, it will be reentering the GUI
code for a new user interaction from deep within the GUI code itself,
because the GUI code hasn't yet returned from processing the previous user
interaction, because the callback from the application code hasn't returned.
 When the second user interaction gets its result, and makes *its* callback
to the application, both the application and the GUI are now reentrant!  Two
different callbacks are now simultaneously active, and there's no guarantee
that the application code won't want to ask the user another question,
causing a *third* level of reentrancy...  *and so forth and upward and
onward, gee whiz !*

Dave

Re: [pygame] GSoC

[David Burton]

Aha!  Thanks for this info, Greg and Lenard!!

Also, thanks, Lendard, I do think this is worth opening an issue about.

It seems that it is not a .dict() method, but a .dict attribute.  It appears
to be almost the equivalent of dir(), lacking the .type entry, but including
the other attributes that matter:

Python 3.1.3 (r313:86834, Nov 27 2010, 18:30:53) [MSC v.1500 32 bit (Intel)]
on win32
Type "copyright", "credits" or "license()" for more information.
>>> import pygame
>>> ev = pygame.event.Event( pygame.USEREVENT, {'id':'test',
'internal':False} )
>>> dict(ev)
Traceback (most recent call last):
  File "", line 1, in 
dict(ev)
TypeError: 'Event' object is not iterable
>>> ev.dict()
Traceback (most recent call last):
  File "", line 1, in 
ev.dict()
TypeError: 'dict' object is not callable
>>> ev.__dict__
Traceback (most recent call last):
  File "", line 1, in 
ev.__dict__
AttributeError: event member not defined
>>> ev.dict
{'internal': False, 'id': 'test'}
>>>


On Sun, Feb 6, 2011 at 2:19 PM, Lenard Lindstrom  wrote:

> Hi David,
>
> On 05/02/11 08:01 PM, David Burton wrote:
>
>> **
>> *
>> *
>> *..., I have noticed that pygame events are somewhat weird.  They are
>> objects, but they don't always behave like proper Python objects.  There's
>> no __dict__ attribute, and dir() doesn't work, which I find annoying:*
>>
>>
>> Python 3.1.3 (r313:86834, Nov 27 2010, 18:30:53) [MSC v.1500 32 bit
>> (Intel)] on win32
>> Type "copyright", "credits" or "license()" for more information.
>> >>> import pygame
>> >>> ev = pygame.event.Event( pygame.USEREVENT, {'id':'test',
>> 'internal':False} )
>> >>> dir(ev)
>> []
>> >>> ev.__dict__
>> Traceback (most recent call last):
>>  File "", line 1, in 
>>ev.__dict__
>> AttributeError: event member not defined
>> >>> ev.type
>> 24
>> >>> ev.id 
>>
>> 'test'
>> >>> ev.internal
>> False
>> >>> repr(ev)
>> ""
>> >>>
>>
>> *Contrast that with how other Python objects behave:*
>>
>> >>> class junk:
>> fee = 1
>> fie = True
>> foe = 'giant'
>> fum = (1,2,3)
>>
>> >>> j1 = junk()
>> >>> repr(j1)
>> '<__main__.junk object at 0x034FA870>'
>> >>> dir(j1)
>> ['__class__', '__delattr__', '__dict__', '__doc__', '__eq__',
>> '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__',
>> '__init__', '__le__', '__lt__', '__module__', '__ne__', '__new__',
>> '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__',
>> '__str__', '__subclasshook__', '__weakref__', 'fee', 'fie', 'foe', 'fum']
>>
>>
>> *See what I mean?  With other Python objects, it is easy to enumerate the
>> attributes of an object.  But it is not obvious how to do that for pygame
>> event objects (though repr() somehow manages it).*
>> *
>> *
>> *Does anyone know how repr() manages to find the attributes for the pygame
>> event, since dir() doesn't work?*
>> *
>> *
>>
>>  Pygame predates Python 2.2, when types became classes. I suppose the
> Event type was never updated. Also, the Event attributes may be read-only
> intentionally. I don't know for sure. If  you are requesting a __dict__ for
> Event types I will add an issue to the Pygame tracker at Motherhamster and
> have a look. Even if system generated events need to keep their attributes
> immutable, I see no problem with mutable attibutes on user generated events.
>
> repr() uses a different mechanism from Python attribute access, a separate
> tp slot function. This function directly accesses the event's dictionary at
> C level, even when it is hidden from dir() at the Python level.
>
> Lenard Lindstrom
>
>


On Sun, Feb 6, 2011 at 4:42 PM, Greg Ewing 
 wrote:

> David Burton wrote:
> ...
>
>> *However, I have noticed that pygame events are somewhat weird.  They are
>> objects, but they don't always behave like proper Python objects.  There's
>> no __dict__ attribute, and dir() doesn't work,
>>
>
> According to the docs, they have a dict() method instead.
>
> --
> Greg
>

Re: [pygame] GSoC

[Greg Ewing]

David Burton wrote:

 (That's because, if you are an experienced programmer, you have learned 
[probably the hard way] that you really don't want to start anything 
complicated in response to a click if you're deep in the bowels of the 
GUI code [which has called your callback function], since the 
complicated thing you start might want to /use/ that same GUI code, and 
get button clicks and menu choices of its own, leading to ever deeper 
recursion in the [hopefully reentrant!] GUI code, and mind-bending 
complexity and bugs.)


I can't really see how using events helps with that, because if
there's a complicated thing to be done, it needs to be done somehow
or other, and either way it's being done by a piece of code being
called from the event loop, which will hold up the GUI until it's
finished.

I don't mean to say that it's *wrong* to use events this way -- if
you find the technique helpful, then that's fine. It's just that the
problem you're describing doesn't seem to arise for me, and I don't
think it would simplify anything in the way I write my game code.

*However, I have noticed that pygame events are somewhat weird.  They 
are objects, but they don't always behave like proper Python objects. 
 There's no __dict__ attribute, and dir() doesn't work,


According to the docs, they have a dict() method instead.

--
Greg

Re: [pygame] GSoC

[Lenard Lindstrom]

Hi David,

On 05/02/11 08:01 PM, David Burton wrote:

**
*
*
*..., I have noticed that pygame events are somewhat weird.  They are 
objects, but they don't always behave like proper Python objects. 
 There's no __dict__ attribute, and dir() doesn't work, which I find 
annoying:*


Python 3.1.3 (r313:86834, Nov 27 2010, 18:30:53) [MSC v.1500 32 bit 
(Intel)] on win32

Type "copyright", "credits" or "license()" for more information.
>>> import pygame
>>> ev = pygame.event.Event( pygame.USEREVENT, {'id':'test', 
'internal':False} )

>>> dir(ev)
[]
>>> ev.__dict__
Traceback (most recent call last):
  File "", line 1, in 
ev.__dict__
AttributeError: event member not defined
>>> ev.type
24
>>> ev.id 
'test'
>>> ev.internal
False
>>> repr(ev)
""
>>>

*Contrast that with how other Python objects behave:*

>>> class junk:
fee = 1
fie = True
foe = 'giant'
fum = (1,2,3)

>>> j1 = junk()
>>> repr(j1)
'<__main__.junk object at 0x034FA870>'
>>> dir(j1)
['__class__', '__delattr__', '__dict__', '__doc__', '__eq__', 
'__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', 
'__init__', '__le__', '__lt__', '__module__', '__ne__', '__new__', 
'__reduce__', '__reduce_ex__', '__repr__', '__setattr__', 
'__sizeof__', '__str__', '__subclasshook__', '__weakref__', 'fee', 
'fie', 'foe', 'fum']



*See what I mean?  With other Python objects, it is easy to enumerate 
the attributes of an object.  But it is not obvious how to do that for 
pygame event objects (though repr() somehow manages it).*

*
*
*Does anyone know how repr() manages to find the attributes for the 
pygame event, since dir() doesn't work?*

*
*

Pygame predates Python 2.2, when types became classes. I suppose the 
Event type was never updated. Also, the Event attributes may be 
read-only intentionally. I don't know for sure. If  you are requesting a 
__dict__ for Event types I will add an issue to the Pygame tracker at 
Motherhamster and have a look. Even if system generated events need to 
keep their attributes immutable, I see no problem with mutable attibutes 
on user generated events.


repr() uses a different mechanism from Python attribute access, a 
separate tp slot function. This function directly accesses the event's 
dictionary at C level, even when it is hidden from dir() at the Python 
level.


Lenard Lindstrom

Re: [pygame] GSoC

[David Burton]

*Any GUI-widget toolkit needs to send information back to the application
about the events that happen: button clicks, menu items picked, text
entered, etc..  There are two obvious ways to do that in pygame: callbacks
and pygame events.*
*
*
*Pygame events are by far the better approach.
*
*
*
Here's how I do it in my code.  When initializing a GUI-widget, it is passed
an identifying data value (an ID), to distinguish it from other GUI-widgets.
 The ID value is stored in the GUI-widget's instance data.  Then, when the
widget needs to send information back to the program, it simply posts a
pygame event with the ID value stored in the pygame event instance.  (I
currently use a single event type number, default USEREVENT, for all
GUI-widget-generated events.)

This is super-simple for the application to handle, much easier than
callbacks.  In the main program, you just have another elif clause in the
event loop, to receive GUI-widget events: button clicks, menu clicks,
user-entered-text-and-pressed [Enter], etc.

Using the event queue like that is just plain *Bette*r for the structure of
the program than using callbacks.

If you use callbacks to call user functions whenever a button or menu click
happens, then much of the time all the callbacks do is set some global
flags, store some data, and then return, so that you can unwrap the call
stack and wind your way back out of the innards of the GUI code, before
actually doing whatever the button or menu click requires.  (That's because,
if you are an experienced programmer, you have learned [probably the hard
way] that you really don't want to start anything complicated in response to
a click if you're deep in the bowels of the GUI code [which has called your
callback function], since the complicated thing you start might want to *use
* that same GUI code, and get button clicks and menu choices of its own,
leading to ever deeper recursion in the [hopefully reentrant!] GUI code, and
mind-bending complexity and bugs.)

If you use the event queue, instead of callbacks, to pass back information
from the GUI, all that complexity goes away.  A button click, a menu
selection, etc. is just another event to be handled in the main event loop.

Python/pygame makes that easy, since you can attach as much additional info
as you want to the event object.  I think the reason so many other GUI
frameworks use callbacks is that their event queues are so limited.  All
they contain is integer event numbers, so it isn't feasible to pass back
(for example) the string of text from a text entry field.  So they work
around this limitation with callbacks to pass back the additional
information.  Programmers get used to this cumbersome approach, and do it
that way even when they don't have to, because of the Toolbox Principle: *"if
all you have is a hammer, then everything looks like a nail."*
*
*
Additionally, you can make any GUI-widget modal, by wrapping it in a simple
function that contains a temporary event loop.  Here's mine:

def modal_popup(widget):
'''Usually, widget sprites are displayed and active along with
everything
else in the application, but it is also possible to display a widget
sprite
"modally," that is, with everything else suspended.  To do so, just pass
the widget to this function.  It won't return until the widget generates
a result event.

A result event is any event of type WIDGETEVENT which has an attribute
.internal=False.

Note: don't use this with widget sprites which can't generate events
(like
LabelSprites), lest it never return!  (Humming Kingston Trio tune...)
'''
group = WidgetGroup(widget)  # a temporary group, for duration of this
popup
keep_running = True
while keep_running:
# Update and Draw the widget
group.update()
group.draw(screen)
pygame.display.update()
# get next event:
event = pygame.event.wait()
# If event is QUIT then they closed the applicaiton, so quit
if event.type == QUIT:
keep_running = False
pygame.quit()
sys.exit(0)
# Give widget sprite a look at the event
group.notify(event)
# We loop until we get a result event from the widget!
if event.type == WIDGETEVENT:
if hasattr(event,'internal') and not event.internal:
group.remove(widget)
keep_running = False
return event
*
*
*However, I have noticed that pygame events are somewhat weird.  They are
objects, but they don't always behave like proper Python objects.  There's
no __dict__ attribute, and dir() doesn't work, which I find annoying:*

Python 3.1.3 (r313:86834, Nov 27 2010, 18:30:53) [MSC v.1500 32 bit (Intel)]
on win32
Type "copyright", "credits" or "license()" for more information.
>>> import pygame
>>> ev = pygame.event.Event( pygame.USEREVENT, {'id':'test',
'internal':False} )
>>> dir(ev)
[]
>>> ev.__dict__
Traceback (most recent call last):
  File "",

Re: [pygame] GSoC

[Greg Ewing]

Sam Bull wrote:


But, from a conversation with someone else about this, it was suggested
that this could complicate the game code, and it would be better to use
events in order to keep the game code and GUI code separated.


It's not necessary to use pygame events to achieve that. Techniques
for keeping GUI and application code decoupled are well known. Google
"MVC" for more information.

The only good reason I can think of for using events this way is if
for some reason you need to handle the event asynchronously, i.e. you
need to ensure that all processing for the current event is completed
before carrying out the action. Otherwise, using an event is probably
just needless complication.

--
Greg

Re: [pygame] GSoC

[Sam Bull]

Hi guys,

I'm looking for some input into widget events, and what people think is
the best way to implement this.

There seems to be two main methods, either a widget can have functions
that are called on these events, or the widget can emit a Pygame event
that will then be handled in the main game loop.
The advantage of the first method is that it is perhaps a little more
OO, in that the functions are encapsulated within the widget's class.
But, from a conversation with someone else about this, it was suggested
that this could complicate the game code, and it would be better to use
events in order to keep the game code and GUI code separated.
After this conversation, I have come up with a potential solution:
On a widget event, such as clicking on a button or hitting the enter key
in an input box, the widget will check for an appropriate function (e.g.
self.on_click()), and run it. This will be useful for printlining or
running some quick GUI code, e.g. clicking a button that should
add/remove a menu can be easily done this way.
If the function is not present, then the widget will emit a Pygame
event, that the developers game code can then handle.

What do you think about the best way to do this?

Also, if you like the proposed idea, would it be better to check if the
function exists, or perhaps check if the function returns None.
The latter may be advantageous, as I can have empty functions in the
base class to simplify documentation. It would also allow a developer to
use the function and return None, so that an event is still emitted and
both methods could be used simultaneously.

Thanks,
Sam Bull

> On Sat, Jan 15, 2011 at 7:46 AM, Sam Bull 
> wrote:
> Hi,
> 
> I was wondering if there was any chance of creating a new GUI
> toolkit in
> Pygame, for Google Summer of Code. I know this isn't working
> directly on
> Pygame, but I think an easier to use, more detailed toolkit
> may lower
> the entry barrier for new developers, and provide a smoother
> experience
> to the players that choose to play these games, thus improving
> the
> overall quality of the Pygame project.
> 
> This toolkit will focus more on the widgets than packing
> features,
> giving full control to the developer as to where the widgets
> should be
> positioned. Each widget should act as a user would expect,
> with similar
> behaviour to GTK+ widgets, a lot of attention has gone into
> the small
> details.
> 
> With it's current design, to start using the toolkit it is as
> simple as:
> from sgc import *
> from sgc.locals import * #Import the modules
> # Create a widget
> example_widget = widgets.Input_Box(args...) #Create an input
> box widget
> example_widget.pos = (x,y) #Set the widget's position
> example_widget.add() #Add widget to the active widgets
> Then just add into your event handling:
> widgets.event(event)
> And somewhere else in your game loop:
> widgets.update(time)
> 
> It should be complete without graphics to keep the total size
> low and
> unbloated, all graphics should thus be produced through code
> only.
> Although, it will be themeable so that developers can use
> custom images
> to change the appearance of the widgets.
> 
> During this GSoC project I would also like to make this
> toolkit work in
> OpenGL under Pygame, with identical behaviour, so developers
> can have a
> more seamless transition between 2D and 3D game development.
> 
> I have started creating a spec for this project as part of my
> college
> coursework. Most of the stuff in the spec has already been
> completed, so
> if there is a chance I can do this for GSoC then I will expand
> this spec
> to show what will be completed during this timeframe. You can
> download
> the spec from:
> http://sambull.org/spec.pdf
> 
> If you also want to see the current progress of the project,
> you can
> download the source from:
> https://launchpad.net/simplegc
> Just download the code from the link, then run the run.py file
> in Python
> to launch the example program. The widgets should behave as
> you would
> expect them to on your desktop, use the "f" key to toggle the
> FPS
> counter.
> The dialog windows and menu are not complete, but the few
> other widgets
> are reasonably feature complete.
> 
> Thank you for your time,
> Sam Bull



signature.asc
Description: This is a digitally signed message p

Re: [pygame] GSOC 2011 ideas for pygame

[Keith Nemitz]

I have a working setup.py script for Mac OSX. It's for a large game using 
PyOpenGL, so it should be useful. I'll contribute that. But Windows and Linux 
have stymied me. py2exe is very finicky with PyOpenGL.

I recommend trying to make an innosetup build that can turn a pygame game into 
an app installer, for Windows. I don't have a Linux machine to work with.


good luck!


--- On Wed, 1/26/11, kunal  wrote:

> From: kunal 
> Subject: Re: [pygame] GSOC 2011 ideas for pygame
> To: pygame-users@seul.org
> Date: Wednesday, January 26, 2011, 7:47 PM
> On 01/26/2011 11:43 PM, Lenard
> Lindstrom wrote:
> > Hi,
> > 
> > py2exe and py2app create standalone Python executables
> for Windows and OS X respectively. They package Python and a
> program together so the program can be run without
> installing Python first. Getting py2exe and py2app include
> all the required Pygame extension modules and their
> dependencies is tricky. Having a profiler or something that
> can analyze a game and then write a setup.py for py2exe or
> py2app may be useful. It would be an exercise in
> meta-programming I suppose.
> > 
> > http://www.py2exe.org/
> > http://svn.pythonmac.org/py2app/py2app/trunk/doc/index.html
> > 
> > I have just started an new GSoC 2011 page at the
> Pygame wiki: http://www.pygame.org/wiki/gsoc2011ideas
> > 
> > This will keep track of the proposals. Everyone,
> please add to as needed.
> > 
> > Lenard Lindstrom
> 
> Hi Lenard,
> 
> This sounds interesting.
> When generating setup.py files for py2app i suppose there
> would be a
> need for an OS X machine at one's disposal, i don't have
> one.
> 
> But py2exe could be worked upon. Also , is there a need
> for
> a single installer wizard for pygame for the various linux
> distros ?
> If so, that interests me a lot , and would be great if i
> could work on the same.
> 
> I am also looking at the pygame bugtracker 
> http://pygame.motherhamster.org/bugzilla/query.cgi
> to see, if there are any issues, that i can patch, as a
> preliminary.
> 
> regards,
> Kunal
> > 
> > 
> > On 26/01/11 08:39 AM, kunal wrote:
> >> On 01/26/2011 04:20 PM, Keith Nemitz wrote:
> >>> A critical piece of the pygame making pie is
> creating applications for various platforms. In particular,
> integrating PyOpenGl into py2exe and py2app is very
> difficult, especially using innoSetup or other installer
> packages. I've actually got py2app working pretty well with
> it, but there are also many flavors of Linux that could
> benefit from a simple install wrapper for those who don't
> live on the command line.
> >> 
> >> Hi Keith,
> >> So, the idea is of an installer to install games
> based on pygame.
> >> The installer bundles all the packages necessary
> for the game to run on the client machine.
> >> When double clicked it should pop up an Installer
> , asking the client basic bootstrap
> >> questions. Then just install the game to the
> system, for the varied linux distros.
> >> 
> >> Did i understand you correctly ?
> >> 
> >>> 
> >>> 
> >>> --- On Tue, 1/25/11, kunal 
> wrote:
> >>> 
> >>>> From: kunal
> >>>> Subject: [pygame] GSOC 2011 ideas for
> pygame
> >>>> To: pygame-users@seul.org
> >>>> Date: Tuesday, January 25, 2011, 10:58 PM
> >>>> Hi all,
> >>>> I am planning to work on pygame for this
> GSOC 2011.
> >>>> Can someone point me to some prospective
> ideas, or
> >>>> junior jobs that i can undertake.
> >>>> I am comfortable with python.
> >>>> 
> >>>> regards,
> >>>> Kunal
> >>>> 
> >> 
> >> 
> > 
> 
> 
> -- regards
> ---
> Kunal Ghosh
> Dept of Computer Sc.&  Engineering.
> Sir MVIT
> Bangalore,India
> 
> permalink: member.acm.org/~kunal.t2
> Blog:kunalghosh.wordpress.com
> Website:www.kunalghosh.net46.net
> 
>

Re: [pygame] GSOC 2011 ideas for pygame

[kunal]

On 01/26/2011 11:43 PM, Lenard Lindstrom wrote:

Hi,

py2exe and py2app create standalone Python executables for Windows and 
OS X respectively. They package Python and a program together so the 
program can be run without installing Python first. Getting py2exe and 
py2app include all the required Pygame extension modules and their 
dependencies is tricky. Having a profiler or something that can 
analyze a game and then write a setup.py for py2exe or py2app may be 
useful. It would be an exercise in meta-programming I suppose.


http://www.py2exe.org/
http://svn.pythonmac.org/py2app/py2app/trunk/doc/index.html

I have just started an new GSoC 2011 page at the Pygame wiki: 
http://www.pygame.org/wiki/gsoc2011ideas


This will keep track of the proposals. Everyone, please add to as needed.

Lenard Lindstrom


Hi Lenard,

This sounds interesting.
When generating setup.py files for py2app i suppose there would be a
need for an OS X machine at one's disposal, i don't have one.

But py2exe could be worked upon. Also , is there a need for
a single installer wizard for pygame for the various linux distros ?
If so, that interests me a lot , and would be great if i could work on 
the same.


I am also looking at the pygame bugtracker 
http://pygame.motherhamster.org/bugzilla/query.cgi

to see, if there are any issues, that i can patch, as a preliminary.

regards,
Kunal



On 26/01/11 08:39 AM, kunal wrote:

On 01/26/2011 04:20 PM, Keith Nemitz wrote:
A critical piece of the pygame making pie is creating applications 
for various platforms. In particular, integrating PyOpenGl into 
py2exe and py2app is very difficult, especially using innoSetup or 
other installer packages. I've actually got py2app working pretty 
well with it, but there are also many flavors of Linux that could 
benefit from a simple install wrapper for those who don't live on 
the command line.


Hi Keith,
So, the idea is of an installer to install games based on pygame.
The installer bundles all the packages necessary for the game to run 
on the client machine.
When double clicked it should pop up an Installer , asking the client 
basic bootstrap
questions. Then just install the game to the system, for the varied 
linux distros.


Did i understand you correctly ?




--- On Tue, 1/25/11, kunal  wrote:


From: kunal
Subject: [pygame] GSOC 2011 ideas for pygame
To: pygame-users@seul.org
Date: Tuesday, January 25, 2011, 10:58 PM
Hi all,
I am planning to work on pygame for this GSOC 2011.
Can someone point me to some prospective ideas, or
junior jobs that i can undertake.
I am comfortable with python.

regards,
Kunal









--
regards
---
Kunal Ghosh
Dept of Computer Sc.&  Engineering.
Sir MVIT
Bangalore,India

permalink: member.acm.org/~kunal.t2
Blog:kunalghosh.wordpress.com
Website:www.kunalghosh.net46.net

Re: [pygame] GSOC 2011 ideas for pygame

[Lenard Lindstrom]

Hi,

py2exe and py2app create standalone Python executables for Windows and 
OS X respectively. They package Python and a program together so the 
program can be run without installing Python first. Getting py2exe and 
py2app include all the required Pygame extension modules and their 
dependencies is tricky. Having a profiler or something that can analyze 
a game and then write a setup.py for py2exe or py2app may be useful. It 
would be an exercise in meta-programming I suppose.


http://www.py2exe.org/
http://svn.pythonmac.org/py2app/py2app/trunk/doc/index.html

I have just started an new GSoC 2011 page at the Pygame wiki: 
http://www.pygame.org/wiki/gsoc2011ideas


This will keep track of the proposals. Everyone, please add to as needed.

Lenard Lindstrom


On 26/01/11 08:39 AM, kunal wrote:

On 01/26/2011 04:20 PM, Keith Nemitz wrote:
A critical piece of the pygame making pie is creating applications 
for various platforms. In particular, integrating PyOpenGl into 
py2exe and py2app is very difficult, especially using innoSetup or 
other installer packages. I've actually got py2app working pretty 
well with it, but there are also many flavors of Linux that could 
benefit from a simple install wrapper for those who don't live on the 
command line.


Hi Keith,
So, the idea is of an installer to install games based on pygame.
The installer bundles all the packages necessary for the game to run 
on the client machine.
When double clicked it should pop up an Installer , asking the client 
basic bootstrap
questions. Then just install the game to the system, for the varied 
linux distros.


Did i understand you correctly ?




--- On Tue, 1/25/11, kunal  wrote:


From: kunal
Subject: [pygame] GSOC 2011 ideas for pygame
To: pygame-users@seul.org
Date: Tuesday, January 25, 2011, 10:58 PM
Hi all,
I am planning to work on pygame for this GSOC 2011.
Can someone point me to some prospective ideas, or
junior jobs that i can undertake.
I am comfortable with python.

regards,
Kunal

Re: [pygame] GSOC 2011 ideas for pygame

[kunal]

On 01/26/2011 04:20 PM, Keith Nemitz wrote:

A critical piece of the pygame making pie is creating applications for various 
platforms. In particular, integrating PyOpenGl into py2exe and py2app is very 
difficult, especially using innoSetup or other installer packages. I've 
actually got py2app working pretty well with it, but there are also many 
flavors of Linux that could benefit from a simple install wrapper for those who 
don't live on the command line.


Hi Keith,
So, the idea is of an installer to install games based on pygame.
The installer bundles all the packages necessary for the game to run on 
the client machine.
When double clicked it should pop up an Installer , asking the client 
basic bootstrap
questions. Then just install the game to the system, for the varied 
linux distros.


Did i understand you correctly ?




--- On Tue, 1/25/11, kunal  wrote:


From: kunal
Subject: [pygame] GSOC 2011 ideas for pygame
To: pygame-users@seul.org
Date: Tuesday, January 25, 2011, 10:58 PM
Hi all,
I am planning to work on pygame for this GSOC 2011.
Can someone point me to some prospective ideas, or
junior jobs that i can undertake.
I am comfortable with python.

regards,
Kunal




--
regards
---
Kunal Ghosh
Dept of Computer Sc.&  Engineering.
Sir MVIT
Bangalore,India

permalink: member.acm.org/~kunal.t2
Blog:kunalghosh.wordpress.com
Website:www.kunalghosh.net46.net

Re: [pygame] GSOC 2011 ideas for pygame

[Keith Nemitz]

A critical piece of the pygame making pie is creating applications for various 
platforms. In particular, integrating PyOpenGl into py2exe and py2app is very 
difficult, especially using innoSetup or other installer packages. I've 
actually got py2app working pretty well with it, but there are also many 
flavors of Linux that could benefit from a simple install wrapper for those who 
don't live on the command line.



--- On Tue, 1/25/11, kunal  wrote:

> From: kunal 
> Subject: [pygame] GSOC 2011 ideas for pygame
> To: pygame-users@seul.org
> Date: Tuesday, January 25, 2011, 10:58 PM
> Hi all,
> I am planning to work on pygame for this GSOC 2011.
> Can someone point me to some prospective ideas, or
> junior jobs that i can undertake.
> I am comfortable with python.
> 
> regards,
> Kunal
> 

Re: [pygame] GSoC

[René Dudfield]

hi,

you'll need to compile pygame from source for python 3 on ubuntu.
Since it is not packaged by ubuntu for python 3 yet (like a lot of
missing python 3 modules on ubuntu).


sudo apt-get install python-dev libsdl-image1.2-dev
libsdl-mixer1.2-dev libsdl-ttf2.0-dev libsdl1.2-dev libsmpeg-dev
python-numpy subversion libportmidi-dev

svn co svn://seul.org/svn/pygame/trunk pygame

cd pygame
python3.1 setup.py build
sudo python3.1 setup.py install




On Sun, Jan 16, 2011 at 9:39 AM, Sam Bull  wrote:
>
> Hi David,
>
> I had not realised that Pygame was working on Python 3. Oddly, it still
> does not seem to be working on my computer:
>  File "/home/s/Games/Python/Tools/sgc/sgc/example/test.py", line 12, in
> 
>    import pygame
> ImportError: No module named pygame
> I'm running Ubuntu, and have installed python-pygame from the
> repositories, it says Pygame is 1.9.1, but does not seem to run with
> python3.
> It works without a problem on Python 2 though...
>
> On Sat, 2011-01-15 at 08:52 -0500, David Burton wrote:
> > [private / off-list to Sam Bull]
> >
> > I agree, Sam!
> >
> > There are several options out there.  I have three of them running on
> > Python 3, but I'm not too happy with any of them:
> > ...

Re: [pygame] GSoC

[Sam Bull]

Hi David,

I had not realised that Pygame was working on Python 3. Oddly, it still
does not seem to be working on my computer:
  File "/home/s/Games/Python/Tools/sgc/sgc/example/test.py", line 12, in

import pygame
ImportError: No module named pygame
I'm running Ubuntu, and have installed python-pygame from the
repositories, it says Pygame is 1.9.1, but does not seem to run with
python3.
It works without a problem on Python 2 though...

On Sat, 2011-01-15 at 08:52 -0500, David Burton wrote:
> [private / off-list to Sam Bull]
> 
> I agree, Sam!
> 
> There are several options out there.  I have three of them running on
> Python 3, but I'm not too happy with any of them:
> ...


signature.asc
Description: This is a digitally signed message part

Re: [pygame] GSoC

[Luke Paireepinart]

I don't make such decisions, but I think this is a fabulous idea. We've been 
sorely lacking something like this.

-
Sent from a mobile device. Apologies for brevity and top-posting.
-

On Jan 15, 2011, at 6:46 AM, Sam Bull  wrote:

> Hi,
> 
> I was wondering if there was any chance of creating a new GUI toolkit in
> Pygame, for Google Summer of Code. I know this isn't working directly on
> Pygame, but I think an easier to use, more detailed toolkit may lower
> the entry barrier for new developers, and provide a smoother experience
> to the players that choose to play these games, thus improving the
> overall quality of the Pygame project.
> 
> This toolkit will focus more on the widgets than packing features,
> giving full control to the developer as to where the widgets should be
> positioned. Each widget should act as a user would expect, with similar
> behaviour to GTK+ widgets, a lot of attention has gone into the small
> details.
> 
> With it's current design, to start using the toolkit it is as simple as:
> from sgc import *
> from sgc.locals import * #Import the modules
> # Create a widget
> example_widget = widgets.Input_Box(args...) #Create an input box widget
> example_widget.pos = (x,y) #Set the widget's position
> example_widget.add() #Add widget to the active widgets
> Then just add into your event handling:
> widgets.event(event)
> And somewhere else in your game loop:
> widgets.update(time)
> 
> It should be complete without graphics to keep the total size low and
> unbloated, all graphics should thus be produced through code only.
> Although, it will be themeable so that developers can use custom images
> to change the appearance of the widgets.
> 
> During this GSoC project I would also like to make this toolkit work in
> OpenGL under Pygame, with identical behaviour, so developers can have a
> more seamless transition between 2D and 3D game development.
> 
> I have started creating a spec for this project as part of my college
> coursework. Most of the stuff in the spec has already been completed, so
> if there is a chance I can do this for GSoC then I will expand this spec
> to show what will be completed during this timeframe. You can download
> the spec from:
> http://sambull.org/spec.pdf
> 
> If you also want to see the current progress of the project, you can
> download the source from:
> https://launchpad.net/simplegc
> Just download the code from the link, then run the run.py file in Python
> to launch the example program. The widgets should behave as you would
> expect them to on your desktop, use the "f" key to toggle the FPS
> counter.
> The dialog windows and menu are not complete, but the few other widgets
> are reasonably feature complete.
> 
> Thank you for your time,
> Sam Bull

Re: [pygame] GSoC Article for PSF and my blog

[Neilen Marais]

Hi,

On Thu, Sep 16, 2010 at 7:20 PM, RB[0]  wrote:
> There is a 2010 page as well, the link appears to have been fixed...
> I haven't been involved in GSOC before either, but this is the pygame
> mailing list so I don't think he is actually asking you personally Neilen,
> but the Pygame community.

Uhm, yeah, not sure why I thought it was addressed to me personally...
Sorry for the on-list brain-malfunction :)

Best Regards
Neilen

Re: [pygame] GSoC Article for PSF and my blog

[Mike Driscoll]

Hi Lenard,

Thanks for the heads-up!

- Mike


On Thu, Sep 16, 2010 at 2:26 PM, Lenard Lindstrom  wrote:

> Hi,
>
> There was only one Pygame specific project this year. It is mentioned on
> the Pygame page http://www.pygame.org/news.html under the July 6 entry.
>
> Lenard Lindstrom
>
>
> On 16/09/10 11:00 AM, Mike Driscoll wrote:
>
>> Hi,
>>
>> Yeah, I was asking the community in general since there is no specific
>> go-to person mentioned on that website. Sorry I wasn't clearer. I was hoping
>> that whoever was involved this year would contact me.
>>
>> - Mike
>>
>>
>> On Thu, Sep 16, 2010 at 12:20 PM, RB[0] > roeb...@gmail.com>> wrote:
>>
>>There is a 2010 page as well, the link appears to have been fixed...
>>I haven't been involved in GSOC before either, but this is the
>>pygame mailing list so I don't think he is actually asking you
>>personally Neilen, but the Pygame community.
>>I believe you should speak with Marcus, he seems the most active
>>in GSOC, but I dunno...
>>
>>
>>On Thu, Sep 16, 2010 at 11:10 AM, Mike Driscoll
>>mailto:m...@pythonlibrary.org>> wrote:
>>
>>Hi Neilen,
>>
>>In the Development section on that link, it lists the
>>following: "PyGame has their own ideas page" (5th down). Of
>>course, it links to the 2009 page on PyGame's site:
>>http://pygame.org/wiki/gsoc2009ideas
>>
>>Not sure how it got included on the 2010 wiki page though.
>>Sorry to bother you guys.
>>
>>- Mike
>>
>>
>>On Thu, Sep 16, 2010 at 9:17 AM, Neilen Marais
>>mailto:nmar...@gmail.com>> wrote:
>>
>>Hi Mike,
>>
>>On Thu, Sep 16, 2010 at 4:08 PM, Mike Driscoll
>>mailto:m...@pythonlibrary.org>>
>>
>>wrote:
>>> Hi,
>>>
>>> I am working on an article for the Python Software
>>Foundation's blog,
>>> http://pyfound.blogspot.com/, about the various Python
>>projects that were
>>> worked on during this year's Google Summer of Code
>>program. They want me to
>>> write up something about what projects were worked on
>>and what the results
>>> were. I found your project information here:
>>> http://wiki.python.org/moin/SummerOfCode/2010
>>
>>I'm not sure how you manage to find my project there,
>>since I have no
>>such project. I have never been involved with GSOC in any
>>way, nor am
>>I really qualified to be a mentor :) I have posted in/on
>>various
>>python formums/mailing lists though, so presumably it's a
>>case of
>>mistaken identity!
>>
>>Best regards
>>Neilen
>>
>>
>>
>>
>>-- -
>>Mike Driscoll
>>
>>Blog: http://blog.pythonlibrary.org
>>
>>
>>
>>
>>
>> --
>> -
>> Mike Driscoll
>>
>> Blog: http://blog.pythonlibrary.org
>>
>
>


-- 
-
Mike Driscoll

Blog:   http://blog.pythonlibrary.org

Re: [pygame] GSoC Article for PSF and my blog

[Lenard Lindstrom]

Hi,

There was only one Pygame specific project this year. It is mentioned on 
the Pygame page http://www.pygame.org/news.html under the July 6 entry.


Lenard Lindstrom

On 16/09/10 11:00 AM, Mike Driscoll wrote:

Hi,

Yeah, I was asking the community in general since there is no specific 
go-to person mentioned on that website. Sorry I wasn't clearer. I was 
hoping that whoever was involved this year would contact me.


- Mike


On Thu, Sep 16, 2010 at 12:20 PM, RB[0] > wrote:


There is a 2010 page as well, the link appears to have been fixed...
I haven't been involved in GSOC before either, but this is the
pygame mailing list so I don't think he is actually asking you
personally Neilen, but the Pygame community.
I believe you should speak with Marcus, he seems the most active
in GSOC, but I dunno...


On Thu, Sep 16, 2010 at 11:10 AM, Mike Driscoll
mailto:m...@pythonlibrary.org>> wrote:

Hi Neilen,

In the Development section on that link, it lists the
following: "PyGame has their own ideas page" (5th down). Of
course, it links to the 2009 page on PyGame's site:
http://pygame.org/wiki/gsoc2009ideas

Not sure how it got included on the 2010 wiki page though.
Sorry to bother you guys.

- Mike


On Thu, Sep 16, 2010 at 9:17 AM, Neilen Marais
mailto:nmar...@gmail.com>> wrote:

Hi Mike,

On Thu, Sep 16, 2010 at 4:08 PM, Mike Driscoll
mailto:m...@pythonlibrary.org>>
wrote:
> Hi,
>
> I am working on an article for the Python Software
Foundation's blog,
> http://pyfound.blogspot.com/, about the various Python
projects that were
> worked on during this year's Google Summer of Code
program. They want me to
> write up something about what projects were worked on
and what the results
> were. I found your project information here:
> http://wiki.python.org/moin/SummerOfCode/2010

I'm not sure how you manage to find my project there,
since I have no
such project. I have never been involved with GSOC in any
way, nor am
I really qualified to be a mentor :) I have posted in/on
various
python formums/mailing lists though, so presumably it's a
case of
mistaken identity!

Best regards
Neilen




-- 
-

Mike Driscoll

Blog: http://blog.pythonlibrary.org





--
-
Mike Driscoll

Blog: http://blog.pythonlibrary.org

Re: [pygame] GSoC Article for PSF and my blog

[Mike Driscoll]

Hi,

Yeah, I was asking the community in general since there is no specific go-to
person mentioned on that website. Sorry I wasn't clearer. I was hoping that
whoever was involved this year would contact me.

- Mike


On Thu, Sep 16, 2010 at 12:20 PM, RB[0]  wrote:

> There is a 2010 page as well, the link appears to have been fixed...
> I haven't been involved in GSOC before either, but this is the pygame
> mailing list so I don't think he is actually asking you personally Neilen,
> but the Pygame community.
> I believe you should speak with Marcus, he seems the most active in GSOC,
> but I dunno...
>
>
> On Thu, Sep 16, 2010 at 11:10 AM, Mike Driscoll wrote:
>
>> Hi Neilen,
>>
>> In the Development section on that link, it lists the following: "PyGame
>> has their own ideas page" (5th down). Of course, it links to the 2009 page
>> on PyGame's site: http://pygame.org/wiki/gsoc2009ideas
>>
>> Not sure how it got included on the 2010 wiki page though. Sorry to bother
>> you guys.
>>
>> - Mike
>>
>>
>> On Thu, Sep 16, 2010 at 9:17 AM, Neilen Marais  wrote:
>>
>>> Hi Mike,
>>>
>>> On Thu, Sep 16, 2010 at 4:08 PM, Mike Driscoll 
>>> wrote:
>>> > Hi,
>>> >
>>> > I am working on an article for the Python Software Foundation's blog,
>>> > http://pyfound.blogspot.com/, about the various Python projects that
>>> were
>>> > worked on during this year's Google Summer of Code program. They want
>>> me to
>>> > write up something about what projects were worked on and what the
>>> results
>>> > were. I found your project information here:
>>> > http://wiki.python.org/moin/SummerOfCode/2010
>>>
>>> I'm not sure how you manage to find my project there, since I have no
>>> such project. I have never been involved with GSOC in any way, nor am
>>> I really qualified to be a mentor :) I have posted in/on various
>>> python formums/mailing lists though, so presumably it's a case of
>>> mistaken identity!
>>>
>>> Best regards
>>> Neilen
>>>
>>
>>
>>
>> --
>> -
>> Mike Driscoll
>>
>> Blog:   http://blog.pythonlibrary.org
>>
>
>


-- 
-
Mike Driscoll

Blog:   http://blog.pythonlibrary.org

Re: [pygame] GSoC Article for PSF and my blog

[RB[0]]

There is a 2010 page as well, the link appears to have been fixed...
I haven't been involved in GSOC before either, but this is the pygame
mailing list so I don't think he is actually asking you personally Neilen,
but the Pygame community.
I believe you should speak with Marcus, he seems the most active in GSOC,
but I dunno...

On Thu, Sep 16, 2010 at 11:10 AM, Mike Driscoll wrote:

> Hi Neilen,
>
> In the Development section on that link, it lists the following: "PyGame
> has their own ideas page" (5th down). Of course, it links to the 2009 page
> on PyGame's site: http://pygame.org/wiki/gsoc2009ideas
>
> Not sure how it got included on the 2010 wiki page though. Sorry to bother
> you guys.
>
> - Mike
>
>
> On Thu, Sep 16, 2010 at 9:17 AM, Neilen Marais  wrote:
>
>> Hi Mike,
>>
>> On Thu, Sep 16, 2010 at 4:08 PM, Mike Driscoll 
>> wrote:
>> > Hi,
>> >
>> > I am working on an article for the Python Software Foundation's blog,
>> > http://pyfound.blogspot.com/, about the various Python projects that
>> were
>> > worked on during this year's Google Summer of Code program. They want me
>> to
>> > write up something about what projects were worked on and what the
>> results
>> > were. I found your project information here:
>> > http://wiki.python.org/moin/SummerOfCode/2010
>>
>> I'm not sure how you manage to find my project there, since I have no
>> such project. I have never been involved with GSOC in any way, nor am
>> I really qualified to be a mentor :) I have posted in/on various
>> python formums/mailing lists though, so presumably it's a case of
>> mistaken identity!
>>
>> Best regards
>> Neilen
>>
>
>
>
> --
> -
> Mike Driscoll
>
> Blog:   http://blog.pythonlibrary.org
>

Re: [pygame] GSoC Article for PSF and my blog

[Mike Driscoll]

Hi Neilen,

In the Development section on that link, it lists the following: "PyGame has
their own ideas page" (5th down). Of course, it links to the 2009 page on
PyGame's site: http://pygame.org/wiki/gsoc2009ideas

Not sure how it got included on the 2010 wiki page though. Sorry to bother
you guys.

- Mike

On Thu, Sep 16, 2010 at 9:17 AM, Neilen Marais  wrote:

> Hi Mike,
>
> On Thu, Sep 16, 2010 at 4:08 PM, Mike Driscoll 
> wrote:
> > Hi,
> >
> > I am working on an article for the Python Software Foundation's blog,
> > http://pyfound.blogspot.com/, about the various Python projects that
> were
> > worked on during this year's Google Summer of Code program. They want me
> to
> > write up something about what projects were worked on and what the
> results
> > were. I found your project information here:
> > http://wiki.python.org/moin/SummerOfCode/2010
>
> I'm not sure how you manage to find my project there, since I have no
> such project. I have never been involved with GSOC in any way, nor am
> I really qualified to be a mentor :) I have posted in/on various
> python formums/mailing lists though, so presumably it's a case of
> mistaken identity!
>
> Best regards
> Neilen
>



-- 
-
Mike Driscoll

Blog:   http://blog.pythonlibrary.org

Re: [pygame] GSoC Article for PSF and my blog

[Neilen Marais]

Hi Mike,

On Thu, Sep 16, 2010 at 4:08 PM, Mike Driscoll  wrote:
> Hi,
>
> I am working on an article for the Python Software Foundation's blog,
> http://pyfound.blogspot.com/, about the various Python projects that were
> worked on during this year's Google Summer of Code program. They want me to
> write up something about what projects were worked on and what the results
> were. I found your project information here:
> http://wiki.python.org/moin/SummerOfCode/2010

I'm not sure how you manage to find my project there, since I have no
such project. I have never been involved with GSOC in any way, nor am
I really qualified to be a mentor :) I have posted in/on various
python formums/mailing lists though, so presumably it's a case of
mistaken identity!

Best regards
Neilen

Re: [pygame] gsoc: pygamedraw - status update

[jug]

Lorenz Quack wrote:

Hey,

I have to agree with the other comments. it's really looking good so far!


Thanks.



On 06/17/2010 06:05 PM, jug wrote:

Hello,

I'd like to give you a short status report of the pygamedraw gsoc 
project.

I've implemented the main class structure and basic drawing methods, so
its already usable:


[...]

If you have any ideas for further Pen classes please tell me.

[...]
> Regards,
> Julian
>

I just thought that it *might* be useful to have an attribute "style" 
or something like that
which can be set to "SOLID", "DOTTED" or "DASHED" in analogy to the 
css attribute border-style [1].

I don't think this is a top priority item but might be nice to have.

keep up the good work

//Lorenz

[1] http://www.tizag.com/cssT/border.php



Yes, I also had this idea of line styles or some kind of orientation 
that could be passed to
the drawing algorithm but this is not that easy due to the generic 
implementation via
masks. However its on my "ideas that would be cool to have and may be 
implemented later

if I have some time left"-list :)

Luke Paireepinart wrote:

Hey, I'm in need of some fast drawing functions that can correctly
paint brush strokes... eg. if I draw a series of points 1px apart,with
alpha, is it going to look like a bunch of overlapping circles, or is
it going to look like a thick line of the correct alpha value?
   


By default it will look like a bunch of overlapping circles as this is the
normally expected behavior. However you could prevent this by activating
multi-part drawing. This means, that the (mask of the) last drawn shape is
removed from the (mask of the) next shape.
(note that this is not completely implemented yet.)


Also, these are implemented in pure Python?  How fast are they?  do
they do a lot of work in Python or is most of it done in existing SDL
code or something?
   


Currently its all done in pure Python. Since this is a rewrite of the
current modules that are only wrappers around the SDL functions
I do not use any SDL drawing routines.  This is why it is not fast
at all now, but its just a prototyping and we plan to port the critical
parts to C at the end.


And how can I test this out?  Do I just install Pygame Reloaded and
then add this to my project folder and import it?
   


Yes. You need pygame2 installed and the "lib" folder in the pygamedraw
project dir on your python part. Then you can do
"from lib.solidpen import SolidPen" and so on. Have a look at the example
at ./examples/allinone.py.

Regards,
Julian

Re: [pygame] gsoc: pygamedraw - status update

[Luke Paireepinart]

Hey, I'm in need of some fast drawing functions that can correctly
paint brush strokes... eg. if I draw a series of points 1px apart,with
alpha, is it going to look like a bunch of overlapping circles, or is
it going to look like a thick line of the correct alpha value?

Also, these are implemented in pure Python?  How fast are they?  do
they do a lot of work in Python or is most of it done in existing SDL
code or something?

And how can I test this out?  Do I just install Pygame Reloaded and
then add this to my project folder and import it?

Thanks,
-Luke

On Thu, Jun 17, 2010 at 3:54 PM, Lorenz Quack  wrote:
> Hey,
>
> I have to agree with the other comments. it's really looking good so far!
>
> On 06/17/2010 06:05 PM, jug wrote:
>>
>> Hello,
>>
>> I'd like to give you a short status report of the pygamedraw gsoc project.
>> I've implemented the main class structure and basic drawing methods, so
>> its already usable:
>>
> [...]
>>
>> If you have any ideas for further Pen classes please tell me.
>
> [...]
>> Regards,
>> Julian
>>
>
> I just thought that it *might* be useful to have an attribute "style" or
> something like that
> which can be set to "SOLID", "DOTTED" or "DASHED" in analogy to the css
> attribute border-style [1].
> I don't think this is a top priority item but might be nice to have.
>
> keep up the good work
>
> //Lorenz
>
> [1] http://www.tizag.com/cssT/border.php
>
>

Re: [pygame] gsoc: pygamedraw - status update

[Lorenz Quack]

Hey,

I have to agree with the other comments. it's really looking good so far!

On 06/17/2010 06:05 PM, jug wrote:

Hello,

I'd like to give you a short status report of the pygamedraw gsoc project.
I've implemented the main class structure and basic drawing methods, so
its already usable:


[...]

If you have any ideas for further Pen classes please tell me.

[...]
> Regards,
> Julian
>

I just thought that it *might* be useful to have an attribute "style" or 
something like that
which can be set to "SOLID", "DOTTED" or "DASHED" in analogy to the css 
attribute border-style [1].
I don't think this is a top priority item but might be nice to have.

keep up the good work

//Lorenz

[1] http://www.tizag.com/cssT/border.php

Re: [pygame] gsoc: pygamedraw - status update

[Lenard Lindstrom]

Looking good.

Lenard

Re: [pygame] gsoc: pygamedraw - status update

[Marcus von Appen]

On, Thu Jun 17, 2010, Henrique Nakashima wrote:

> The module is looking very nice so far, I'm looking forward to using it =)
> 
> Have you though about implementing the Pen class as an abstract class with
> the abc module? That would prevent Pen from being directly instantiated.
> 

The abc module is not available (by default) for Python 2.4 and 2.5, so
it was not taken into consideration for now. Hence the (older) approach
of using NotImplementedError instad.

Regards
Marcus


pgpwU8gSvPV5E.pgp
Description: PGP signature

Re: [pygame] gsoc: pygamedraw - status update

[Henrique Nakashima]

The module is looking very nice so far, I'm looking forward to using it =)

Have you though about implementing the Pen class as an abstract class with
the abc module? That would prevent Pen from being directly instantiated.

On Thu, Jun 17, 2010 at 13:29, René Dudfield  wrote:

> sweet as :)
>

Re: [pygame] gsoc: pygamedraw - status update

[René Dudfield]

sweet as :)

Re: [pygame] GSoC 2010: A New Draw Module

[Lenard Lindstrom]

Hi Julian,

A great idea. If the new module implements all the functionality of the 
current modules, then for backwards compatibility the draw module, or 
something like it, can be implemented in Python on top the new module. 
So the new module should have a different name. Though I ported the 
gfxdraw module from pygame2 into pygame, I have shied away from doing 
any enhancements since my only graphics course was taught by an 
electrical engineer, with an emphasis on hardware and an embedded 
graphics language for Fortran the engineer had written (this was some 
time ago). So I'm glad to see someone else take on the job. Be aware 
though, someone will request anti-aliased circles with line thickness 
greater than one. Oh, and Cairo is considered too slow, so wrapping it 
won't do.


Lenard

jug wrote:

Hello!

I'm going to write a new draw module for pygame and pygame2 as part of
GSoC this year. The aim is to have one draw module for pygame that
implements not only the very basic drawing of a few plain color shapes 
but

also drawing of more advanced shapes and whith more advanced attributes
(ie. curves, rounded corners, aa, etc.) as well as alternative filling 
methods
(ie. procedural or image based textures, filling from another 
surface/image

(cloning), etc.). Unlike now the code will be object oriented thus you'll
need to create a (pen) object before using it to draw stuff. That is 
to to keep
code clean and structured and avoid functions with (terribly) long 
parameter
lists. However, I plan to add some shortcuts for basic functionality 
(and maybe

compatibility).

I'm still thinking about concepts and have some more vague ideas in 
mind so

if you have any ideas or suggestions please tell me :)


While development I'll blog about any progress at


Even though I've got svn access to the pygame repo (thank you, rene) I 
also

have a (currently still empty) hg repo with wiki and issue tracker at
http://bitbucket.org/schlangen/pygamedraw


Regards,
Julian

Re: [pygame] GSoC 2010: A New Draw Module

[Devon Scott-Tunkin]

Congratulations Julian, looking forward to it.

Devon

On Sun, May 2, 2010 at 6:00 PM, Luke Paireepinart wrote:

> Yay.
> Pygame has needed this for a LONG time.
> Good luck!  Keep us updated.
>
> On Sun, May 2, 2010 at 5:55 PM, jug  wrote:
> > Hello!
> >
> > I'm going to write a new draw module for pygame and pygame2 as part of
> > GSoC this year. The aim is to have one draw module for pygame that
> > implements not only the very basic drawing of a few plain color shapes
> but
> > also drawing of more advanced shapes and whith more advanced attributes
> > (ie. curves, rounded corners, aa, etc.) as well as alternative filling
> > methods
> > (ie. procedural or image based textures, filling from another
> surface/image
> > (cloning), etc.). Unlike now the code will be object oriented thus you'll
> > need to create a (pen) object before using it to draw stuff. That is to
> to
> > keep
> > code clean and structured and avoid functions with (terribly) long
> parameter
> > lists. However, I plan to add some shortcuts for basic functionality (and
> > maybe
> > compatibility).
> >
> > I'm still thinking about concepts and have some more vague ideas in mind
> so
> > if you have any ideas or suggestions please tell me :)
> >
> >
> > While development I'll blog about any progress at
> > http://pygamedraw.wordpress.com/
> >
> > Even though I've got svn access to the pygame repo (thank you, rene) I
> also
> > have a (currently still empty) hg repo with wiki and issue tracker at
> > http://bitbucket.org/schlangen/pygamedraw
> >
> >
> > Regards,
> > Julian
> >
>

Re: [pygame] GSoC 2010: A New Draw Module

[Luke Paireepinart]

Yay.
Pygame has needed this for a LONG time.
Good luck!  Keep us updated.

On Sun, May 2, 2010 at 5:55 PM, jug  wrote:
> Hello!
>
> I'm going to write a new draw module for pygame and pygame2 as part of
> GSoC this year. The aim is to have one draw module for pygame that
> implements not only the very basic drawing of a few plain color shapes but
> also drawing of more advanced shapes and whith more advanced attributes
> (ie. curves, rounded corners, aa, etc.) as well as alternative filling
> methods
> (ie. procedural or image based textures, filling from another surface/image
> (cloning), etc.). Unlike now the code will be object oriented thus you'll
> need to create a (pen) object before using it to draw stuff. That is to to
> keep
> code clean and structured and avoid functions with (terribly) long parameter
> lists. However, I plan to add some shortcuts for basic functionality (and
> maybe
> compatibility).
>
> I'm still thinking about concepts and have some more vague ideas in mind so
> if you have any ideas or suggestions please tell me :)
>
>
> While development I'll blog about any progress at
> http://pygamedraw.wordpress.com/
>
> Even though I've got svn access to the pygame repo (thank you, rene) I also
> have a (currently still empty) hg repo with wiki and issue tracker at
> http://bitbucket.org/schlangen/pygamedraw
>
>
> Regards,
> Julian
>

Re: [pygame] GSoC project proposal: A new draw module

[Kris Schnee]

I tried to use OpenGL and found that drawing anything in 2D was very hard.
For instance, I couldn't simply build a 3D set of shapes and then draw onto
the screen in 2D, using existing Pygame functions; I had to muck around with
textures instead. And drawing text in OpenGL -- just 2D text on a 2D surface
-- is a nightmare. If people are looking for projects, how about an easy way
to switch to a "Pygame mode" of drawing while using OpenGL, so that we can
use existing UI and drawing libraries?


There is the Lamina module, that provides you a pygame surface within
an OpenGL display, that you can draw on using Pygame drawing libraries
and GUIs.

I have not used it for a year or so, but if you are using
PyOpenGL/OpenGL 2, it should work fine.

http://pitchersduel.wordpress.com/2007/07/13/lamina-v-02/

David Keeney

I am the author, so feel free to email me for assistance, if you
decide to use it.


Neat! Thank you.

Re: [pygame] GSoC project proposal: A new draw module

[David]

On Sat, Apr 3, 2010 at 4:25 PM, Kris Schnee  wrote:
> On 4/3/2010 12:58 PM, jug wrote:
>>
>> Marcus von Appen wrote:
>>>
>>> What would be interesting here is, what the Pen class would offer except
>>> from the drawing functions wrapped up in a class and som additional
>>> shapes.
>>>
>>> What about e.g. an aa-property to keep the argument amount low,
>>> transformation and rotation angles for the x- and y-axis (implicit
>>> transformation done upon drawing) or even vector support (e.g. for
>>> faster 2d, 2.5d, 3d operations on the shapes) using the math module?
>>>
>>> What do you think about working out some basic Pen (and utility)
>>> class(es) as an example (no need to implement any function or property,
>>> just a stub of the class, we can examine and design)?
>
> I tried to use OpenGL and found that drawing anything in 2D was very hard.
> For instance, I couldn't simply build a 3D set of shapes and then draw onto
> the screen in 2D, using existing Pygame functions; I had to muck around with
> textures instead. And drawing text in OpenGL -- just 2D text on a 2D surface
> -- is a nightmare. If people are looking for projects, how about an easy way
> to switch to a "Pygame mode" of drawing while using OpenGL, so that we can
> use existing UI and drawing libraries?
>


There is the Lamina module, that provides you a pygame surface within
an OpenGL display, that you can draw on using Pygame drawing libraries
and GUIs.

I have not used it for a year or so, but if you are using
PyOpenGL/OpenGL 2, it should work fine.

http://pitchersduel.wordpress.com/2007/07/13/lamina-v-02/

David Keeney

I am the author, so feel free to email me for assistance, if you
decide to use it.



-- 
dkee...@travelbyroad.net
Rdbhost -> SQL databases as a webservice [www.rdbhost.com]

Re: [pygame] GSoC: Sprite and scene system

[Nikhil Murthy]

Hello,

I had put forward a proposal for this a while ago, but due to a very
crippling college workload, I have not been able to do too much towards
following it up, and likely will not be able to do much towards it until my
summer break. You should have a look through the old threads. To summarize
them:

- Take a look at pyBTS at hg.thadeusb.com . This was Thadeus Burgess's first
attempt at a pygame engine.
- Jason M. Marshall has recently been working on the sprite code, but that
doesn't stop you from working.

Good luck,
Nikhil Murthy

On Mon, Apr 5, 2010 at 8:38 AM, Ark  wrote:

> Hi Everyone.
> I'm very interested on applying to GSoC in Pygame. The idea I like
> from the ideas page is "Improved Sprite and scene system". For this
> idea, is very important to hear comments from people that use pygame.
> The idea is in http://www.pygame.org/wiki/gsoc2010ideas.
>
> I'm trying to be as detailed as possible in my applications, and any
> comment about the idea es very important, not only for me, but for
> everyone with the wish to apply to this idea.
>
> Thanks.
> Jonathan
>

Re: [pygame] GSoC project proposal: A new draw module

[Kris Schnee]

On 4/3/2010 12:58 PM, jug wrote:

Marcus von Appen wrote:


What would be interesting here is, what the Pen class would offer except
from the drawing functions wrapped up in a class and som additional
shapes.

What about e.g. an aa-property to keep the argument amount low,
transformation and rotation angles for the x- and y-axis (implicit
transformation done upon drawing) or even vector support (e.g. for
faster 2d, 2.5d, 3d operations on the shapes) using the math module?

What do you think about working out some basic Pen (and utility)
class(es) as an example (no need to implement any function or property,
just a stub of the class, we can examine and design)?


I tried to use OpenGL and found that drawing anything in 2D was very 
hard. For instance, I couldn't simply build a 3D set of shapes and then 
draw onto the screen in 2D, using existing Pygame functions; I had to 
muck around with textures instead. And drawing text in OpenGL -- just 2D 
text on a 2D surface -- is a nightmare. If people are looking for 
projects, how about an easy way to switch to a "Pygame mode" of drawing 
while using OpenGL, so that we can use existing UI and drawing libraries?

Re: [pygame] GSoC project proposal: A new draw module

[jug]

Marcus von Appen wrote:


What would be interesting here is, what the Pen class would offer except
from the drawing functions wrapped up in a class and som additional
shapes.

What about e.g. an aa-property to keep the argument amount low,
transformation and rotation angles for the x- and y-axis (implicit
transformation done upon drawing) or even vector support (e.g. for
faster 2d, 2.5d, 3d operations on the shapes) using the math module?

What do you think about working out some basic Pen (and utility)
class(es) as an example (no need to implement any function or property,
just a stub of the class, we can examine and design)?

Regards
Marcus

I've created a page with all ideas and concepts that everyone can
(and should) edit or comment on:

http://pexdra.wikidot.com/

Regards
Julian

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

[Evan Kroske]

On Sat, Mar 20, 2010 at 6:16 PM, Luke Paireepinart
 wrote:
>
>
> On Sun, Mar 7, 2010 at 2:30 PM, Evan Kroske  wrote:
>>
>> I plan to make my framework much simpler by restricting the game
>> developer's options
>>
>> I plan to make my framework much simpler by restricting the game
>> developer's options to hide complexity. Here's an idea of the type of code a
>> developer using my framework would write to create a simple platformer with
>> a single level:
>>
>> from insta.menu import *
>> from insta.platformer import *
>>
>> def startMenu():
>>
>>   titleScreen = Screen(600, 400)
>>   titleScreen.setTheme(themes.MEDIEVAL)
>>   titleScreen.setTitle("Porcupine's Tiny Adventure")
>>   titleScreen.setOptions(["Play", "Controls", "Credits"])
>>   titleScreen.getOption("Play").setAction(startGame)
>>   # More code for other menu options
>>
>> def startGame():
>>
>>   game = Game()
>>     hero = Player()
>>   hero.setSprite("standing.gif")
>>   hero.setRunningSprites(["running1.gif", "running2.gif", "running3.gif"])
>>   hero.setJumpSprite("jumping.gif")
>>   hero.setDeathSprite("gravestone.gif")
>>     hero.setMovementTriggers(constants.ARROW_KEYS)
>>   hero.setJumpTrigger(constants.SPACE_BAR)
>>     goal = Item()
>>   goal.setSprite("bigring.gif")
>>   goal.setBehavior(constants.FLOATING)
>>   goal.setAction(game.nextLevel)
>>     itemGenerator = ItemGenerator([None, goal, hero])
>>   [snip...]
>
> Personally I _HATE_ the setSomething notation you're using.  one of the
> reasons I don't use Java is so I don't have to deal with setters and
> getters.  It's an extra 4 keystrokes per function call! (if you include the
> "shift" to make the 4th letter uppercase).
> also, most of your setters/getters are just gonna be setting variables
> behind the scenes so it makes more sense to use properties and to use
> variable syntax.  Eg.
> hero.running_sprites = ["running1.gif", "running2.gif", "running3.gif"]
>
> doesn't that make a lot more sense?
>
> Also I agree that this doesn't have that much relevance to GSoC as far as
> I'm concerned, but you should still pursue the project if it is something
> you want to do!
>
> -Luke
> -Luke
>

Yeah, you're right. When I started thinking about it, I quickly
realized that the setSomething API was ridiculous. I decided to use a
event system for switching sprites; here's an example:

hero.when(hero.running).setSprites('running1.gif', 'running2.gif')

or

hero.when(hero.moving, "left").setSprite('bankingleft.gif')

I think it would be a highly intuitive method for triggering actions.

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

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

[Luke Paireepinart]

On Sun, Mar 7, 2010 at 2:30 PM, Evan Kroske  wrote:

> I plan to make my framework much simpler by restricting the game
> developer's options
>
>
> I plan to make my framework much simpler by restricting the game
> developer's options to hide complexity. Here's an idea of the type of code a
> developer using my framework would write to create a simple platformer with
> a single level:
>
> from insta.menu import *
> from insta.platformer import *
>
> def startMenu():
>
>   titleScreen = Screen(600, 400)
>   titleScreen.setTheme(themes.MEDIEVAL)
>   titleScreen.setTitle("Porcupine's Tiny Adventure")
>   titleScreen.setOptions(["Play", "Controls", "Credits"])
>   titleScreen.getOption("Play").setAction(startGame)
>   # More code for other menu options
>
> def startGame():
>
>   game = Game()
> hero = Player()
>   hero.setSprite("standing.gif")
>   hero.setRunningSprites(["running1.gif", "running2.gif", "running3.gif"])
>   hero.setJumpSprite("jumping.gif")
>   hero.setDeathSprite("gravestone.gif")
> hero.setMovementTriggers(constants.ARROW_KEYS)
>   hero.setJumpTrigger(constants.SPACE_BAR)
> goal = Item()
>   goal.setSprite("bigring.gif")
>   goal.setBehavior(constants.FLOATING)
>   goal.setAction(game.nextLevel)
> itemGenerator = ItemGenerator([None, goal, hero])
>   [snip...]
>

Personally I _HATE_ the setSomething notation you're using.  one of the
reasons I don't use Java is so I don't have to deal with setters and
getters.  It's an extra 4 keystrokes per function call! (if you include the
"shift" to make the 4th letter uppercase).
also, most of your setters/getters are just gonna be setting variables
behind the scenes so it makes more sense to use properties and to use
variable syntax.  Eg.
hero.running_sprites = ["running1.gif", "running2.gif", "running3.gif"]

doesn't that make a lot more sense?

Also I agree that this doesn't have that much relevance to GSoC as far as
I'm concerned, but you should still pursue the project if it is something
you want to do!

-Luke
-Luke

Re: [pygame] GSoC project proposal: A new draw module

[Marcus von Appen]

On, Sun Mar 07, 2010, Julian Habrock wrote:

> Hello,
> 
> I'd like to rewrite/improve the pygame draw module(s) as a GSoC project.
> Currently, there are pygame.draw and pygame.gfxdraw, but both are not
> very usable. There is just a small set of basic shapes to draw. Another 
> important
> point is the missing anti-aliasing. Well, the new gfxdraw has some 
> aa-functions,
> but they are too inflexible.  Lets say you need to draw a filled, 
> anti-aliased circle.
> There is no function to do that, even though there are four (!) 
> functions to draw
> some kind of circle. These functions can draw a circle either filled or 
> anti-aliased
> (or not anti-aliased and not filled) but not both. The same applies to 
> the other
> shapes.
> 
> I made some small tests[1] and it was really easy to get some nice 
> shapes[2]. Of course,
> the code is dirty and slow, but its just a test to get an idea of an 
> usable draw module.
> 
> To handle all these options and parameters, the code could be organized 
> more object
> oriented. One idea was to handle it like PIL:
> 
> mypen = pygame.draw.Pen(surface, ...)
> mypen.circle(pos, rad, ...)
> 
> Then, shapes could not only be filled with plain color, but also pixel 
> data from another
> surface or maybe some kind of texture or so.
> 
> Just some first thoughts and rough ideas.

What would be interesting here is, what the Pen class would offer except
from the drawing functions wrapped up in a class and som additional
shapes.

What about e.g. an aa-property to keep the argument amount low,
transformation and rotation angles for the x- and y-axis (implicit
transformation done upon drawing) or even vector support (e.g. for
faster 2d, 2.5d, 3d operations on the shapes) using the math module?

What do you think about working out some basic Pen (and utility)
class(es) as an example (no need to implement any function or property,
just a stub of the class, we can examine and design)?

Regards
Marcus


pgpTGp7ZttWOR.pgp
Description: PGP signature

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

[Evan Kroske]

I plan to make my framework much simpler by restricting the game 
developer's options


Thadeus Burgess wrote:

I have actually attempted to perform this same thing. My project went
on a standstill as other things were pressing, however I am interested
in reopening my project back up.

I am calling it PyBTS (pygame behind the scenes). It includes a world
manager, terrain, physics based on the "genre". You can take the same
codebase, and change the type of Terrain class, and you get a tilemap
or sidescroller respectively.

I would definitely love to revive the project, my goals for it are
fairly similar, to provide all of the game engine boiler plate code
that goes into making a game.

http://hg.thadeusb.com/Games/PyBTS/
http://hg.thadeusb.com/Games/MyRTS/ # Uses pybts

-Thadeus
I plan to make my framework much simpler by restricting the game 
developer's options to hide complexity. Here's an idea of the type of 
code a developer using my framework would write to create a simple 
platformer with a single level:


from insta.menu import *
from insta.platformer import *

def startMenu():

   titleScreen = Screen(600, 400)
   titleScreen.setTheme(themes.MEDIEVAL)
   titleScreen.setTitle("Porcupine's Tiny Adventure")
   titleScreen.setOptions(["Play", "Controls", "Credits"])
   titleScreen.getOption("Play").setAction(startGame)
   # More code for other menu options

def startGame():

   game = Game()
  
   hero = Player()

   hero.setSprite("standing.gif")
   hero.setRunningSprites(["running1.gif", "running2.gif", "running3.gif"])
   hero.setJumpSprite("jumping.gif")
   hero.setDeathSprite("gravestone.gif")
  
   hero.setMovementTriggers(constants.ARROW_KEYS)

   hero.setJumpTrigger(constants.SPACE_BAR)
  
   goal = Item()

   goal.setSprite("bigring.gif")
   goal.setBehavior(constants.FLOATING)
   goal.setAction(game.nextLevel)
  
   itemGenerator = ItemGenerator([None, goal, hero])
  
   '''
   Tile generator translates level maps (text files full of numbers) 
into tile

   maps in a context-sensitive manner
   '''
   tileGenerator = TileGenerator()
   tileGenerator.setFloorSprite("levelground.gif")
   tileGenerator.setUndergroundSprite("underground.gif")
   tileGenerator.setPlatformSprite("platform.gif")
   # Edge and corner sprites could also be set
  
   mushroom = Enemy()

   mushroom.setRunningSprites(["step1.gif", "step2.gif"])
   mushroom.setDeathSprite("explosion.gif")
   # Some simple behaviors would be pre-defined
   mushroom.setBehavior(constants.WALKING)
  
   bird = Enemy()

   bird.setFlightSprites(["flap1.gif", "flap2.gif"])
   bird.setDeathSprite("feathers.gif")
   bird.setBehavior(constants.FLYING)
  
   # List associates enemy types with numbers in the text file

   enemyGenerator = EnemyGenerator([None, mushroom, bird])
  
   level = Level()

   level.setTileMap(tileGenerator.generateTileMap("levelmap1.txt"))
   level.setEnemyMap(enemyGenerator.generateEnemyMap("enemymap1.txt"))
   level.setItemMap(itemGenerator.generateItemMap("itemmap1.txt"))
   level.setBackground("background.gif")
   level.setBackgroundOptions([constants.TILED, constants.PARALLAX])
  
   game.setLevels([level])

   game.start()

if (__name__ == "__main__"):

   startMenu()

I don't want to make developers worry about individual frames, bounding 
boxes, or damage calculations. They should only think about what's on 
screen and how it moves and interacts. I want to create a framework that 
lets developers think about their games on the same level as the 
LittleBigPlanet level creator at the expense of total freedom and 
granularity.


--
|Evan Kroske
Welcome2Obscurity.Blogspot.com 
The personal blog of a
novice software developer. |

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

[Alex Nordlund]

On Sun, Mar 7, 2010 at 8:03 AM, Nikhil Murthy  wrote:
> You should really take a look at Thadues Burgess's pyBTS, where a lot of the
> things you have mentioned have been done, at least partly.

and DR0ID has written an awesome tile loader.

---
//Alex

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

[Nikhil Murthy]

You should really take a look at Thadues Burgess's pyBTS, where a lot of the
things you have mentioned have been done, at least partly. For instance,
look at his entity module and the weapon classes in there to get ideas for
the weapons you used as your first example.

On Sun, Mar 7, 2010 at 11:42 AM, Thadeus Burgess wrote:

> I have actually attempted to perform this same thing. My project went
> on a standstill as other things were pressing, however I am interested
> in reopening my project back up.
>
> I am calling it PyBTS (pygame behind the scenes). It includes a world
> manager, terrain, physics based on the "genre". You can take the same
> codebase, and change the type of Terrain class, and you get a tilemap
> or sidescroller respectively.
>
> I would definitely love to revive the project, my goals for it are
> fairly similar, to provide all of the game engine boiler plate code
> that goes into making a game.
>
> http://hg.thadeusb.com/Games/PyBTS/
> http://hg.thadeusb.com/Games/MyRTS/ # Uses pybts
>
> -Thadeus
>
>
>
>
>
> On Sat, Mar 6, 2010 at 4:54 PM, Evan Kroske  wrote:
> > I'd like to work on a Pygame-related project for GSoC, so I've been
> > thinking about possible projects I'd like to do. My favorite idea is
> > developing a micro-framework on top of Pygame to cut the volume of
> > code required to create a game within a well-defined genre. It would
> > revolve around assigning actions to high-level events. For example,
> > instead of creating a block like this within the main game loop:
> >
> > if not player.reloading and sdlconst.K_SPACE in keystate and
> > len(shots) < constants.MAX_SHOTS:
> >shots.append(factory.createProjectile(player))
> >
> > the game developer would write something like this:
> >
> > player.setProjectile(Bullet())
> > player.setFireTrigger(sdlconst.K_SPACE)
> >
> > Here are a few more possible examples:
> >
> > # Set tile map for stage
> > level.setTileMap(tileMap)
> >
> > # Set BG music for stage
> > level.setBGMusic("battletheme.ogg")
> >
> > # Assign goal for stage
> > level.setGoal(flagpole)
> >
> > The framework would have specialized modules for each genre; the
> > platformer module would have a simple physics engine and a tiled
> > background engine, but the space shooter module would have a way to
> > easily control the behavior of shots and enemy ships.The framework
> > would dramatically simplify the process of putting graphics on screen
> > and playing sounds, allowing developers to focus on other aspects of
> > game design, such as automated level generation, AI, and media-based
> > mashup games.
> >
> > I'm really excited about the possibility, but I want to know what you
> > think about it. Do game developers need an easier way to create games?
> > Has another project already done this?
> >
> > --
> > Evan Kroske
> > http://welcome2obscurity.blogspot.com/
> > The personal blog of Evan Kroske,
> > novice software developer.
> >
>

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

[Thadeus Burgess]

I have actually attempted to perform this same thing. My project went
on a standstill as other things were pressing, however I am interested
in reopening my project back up.

I am calling it PyBTS (pygame behind the scenes). It includes a world
manager, terrain, physics based on the "genre". You can take the same
codebase, and change the type of Terrain class, and you get a tilemap
or sidescroller respectively.

I would definitely love to revive the project, my goals for it are
fairly similar, to provide all of the game engine boiler plate code
that goes into making a game.

http://hg.thadeusb.com/Games/PyBTS/
http://hg.thadeusb.com/Games/MyRTS/ # Uses pybts

-Thadeus





On Sat, Mar 6, 2010 at 4:54 PM, Evan Kroske  wrote:
> I'd like to work on a Pygame-related project for GSoC, so I've been
> thinking about possible projects I'd like to do. My favorite idea is
> developing a micro-framework on top of Pygame to cut the volume of
> code required to create a game within a well-defined genre. It would
> revolve around assigning actions to high-level events. For example,
> instead of creating a block like this within the main game loop:
>
> if not player.reloading and sdlconst.K_SPACE in keystate and
> len(shots) < constants.MAX_SHOTS:
>    shots.append(factory.createProjectile(player))
>
> the game developer would write something like this:
>
> player.setProjectile(Bullet())
> player.setFireTrigger(sdlconst.K_SPACE)
>
> Here are a few more possible examples:
>
> # Set tile map for stage
> level.setTileMap(tileMap)
>
> # Set BG music for stage
> level.setBGMusic("battletheme.ogg")
>
> # Assign goal for stage
> level.setGoal(flagpole)
>
> The framework would have specialized modules for each genre; the
> platformer module would have a simple physics engine and a tiled
> background engine, but the space shooter module would have a way to
> easily control the behavior of shots and enemy ships.The framework
> would dramatically simplify the process of putting graphics on screen
> and playing sounds, allowing developers to focus on other aspects of
> game design, such as automated level generation, AI, and media-based
> mashup games.
>
> I'm really excited about the possibility, but I want to know what you
> think about it. Do game developers need an easier way to create games?
> Has another project already done this?
>
> --
> Evan Kroske
> http://welcome2obscurity.blogspot.com/
> The personal blog of Evan Kroske,
> novice software developer.
>

Re: [pygame] GSOC commited camera module to svn

[René Dudfield]

Hey,

if you can't figure out the git->svn thing, best to just add the files
with svn to trunk.

cheers,


On Tue, Aug 18, 2009 at 1:08 AM, el lauwer wrote:
> I have temporarily upload the latest version to
> http://www.2shared.com/file/7239598/40fd6468/pygame.html
> So that the latest version is available for gsoc. you can always use the one
> at github, since
> it isn't mutch diferent from the one at 2shared.com.
>
> I will look into the svn and git problem tomorrow.
>
> Grtz
>

Re: [pygame] GSOC commited camera module to svn

[el lauwer]

I have temporarily upload the latest version to 
http://www.2shared.com/file/7239598/40fd6468/pygame.html
So that the latest version is available for gsoc. you can always use  
the one at github, since

it isn't mutch diferent from the one at 2shared.com.

I will look into the svn and git problem tomorrow.

Grtz

Re: [pygame] GSOC commited camera module to svn

[el lauwer]

On 16-aug-09, at 18:58, Nirav Patel wrote:


I don't see the new files in the repository, just the updated ones.
Did you do an "svn add"?



I have a problem with my github and svn, ever since I fetched from svn  
en and dcommited to svn.


Ok, here is a little context about my problem...

I change some lines in src/camera_mac.m
now I do the flowing:

(pygame-dev)a...@higg:pygame$ git add src/camera_mac.m
(pygame-dev)a...@higg:pygame$ git commit -a -m "fuck svn & git"
[detached HEAD 4f227ab] fuck svn & git
 1 files changed, 3 insertions(+), 0 deletions(-)
(pygame-dev)a...@higg:pygame$ git push origin master
Everything up-to-date
(pygame-dev)a...@higg:pygame$ git svn fetch
(pygame-dev)a...@higg:pygame$ git svn dcommit
Committing to svn://seul.org/svn/pygame/trunk ...
A   test_git
Item already exists in filesystem: File already exists: filesystem '/ 
home/svn/repos/svn/pygame/db', transaction '2617-1', path '/trunk/ 
test_git' at /sw/lib/git/git-svn line 492


but when I go and take a look at github or the svn the chances are not  
committed...

any ideas on what could be wrong...
> I haven't looked at your code but have you thought about using the  
transform.flip() function

> rather than writing your own code?
I have looked at that, but I think my one function is faster since it  
cam be more specific about the rotating...

Re: [pygame] GSOC commited camera module to svn

[Nirav Patel]

I don't see the new files in the repository, just the updated ones.
Did you do an "svn add"?

Nirav

On Sun, Aug 16, 2009 at 2:54 AM, el lauwer wrote:
> Hello,
>
> I committed the camera module to the official svn trunk.
>
> Please post any remarks about the module here.
>
> Because I couldn't get the camera to grab a flipped frame, I wrote a
> function that does this manually. It could be improved a bit but I will wait
> with that untill you peaple have tested it more.
>
> Grtz
>
>
>

Re: [pygame] GSOC commited camera module to svn

[don]

> Hello,
> 
> I committed the camera module to the official svn trunk.
> 
> Please post any remarks about the module here.
> 
> Because I couldn't get the camera to grab a flipped frame, I wrote a
> function that does this manually. It could be improved a bit but I
> will wait with that untill you peaple have tested it more.

I haven't looked at your code but have you thought about using the 
transform.flip() function 
rather than writing your own code?

greetings
//Lorenz

Re: [pygame] gsoc midterm report for the camera module

[Nirav Patel]

I don't have anything running OS X to test it on, but it is possible
the colors are in a different order.  (BGR vs RGB).  Try pointing the
camera at a test pattern and seeing if any colors are switched.
http://en.wikipedia.org/wiki/File:SMPTE_Color_Bars_16x9.svg

Nirav

On Fri, Jul 17, 2009 at 10:09 AM, el lauwer wrote:

> * mac_copy_gworld_to_surface()
>        note: There is something wrong with the colors.
>

Re: [pygame] gsoc project blogs, coding has started, and week 1 has past!

[el lauwer]

Hoi,

I will be using github: http://github.com/ab3/pygame-mirror/tree/master

If you like I can make a weekly commit to svn...

Slu


hello,

just in case anyone missed it, each of the GSOC participants have a  
blog up now:
Tyler Laing will improve the movie support in pygame, by adding an  
ffmpeg-based module (blog).  http://www.oddco.ca/zeroth/zblog/
Vicent Marti will improve font handling using the freetype library  
(blog).  http://www.bellverde.org/gsoc
Werner Laurensse will improve the new camera module and add MacOS X  
support for it (blog).  http://abeocracy.tumblr.com/


So if you'd like to follow along with their developments, drop by to  
their blogs!



Or you can follow their progress in svn:

Tyler Laing:
http://www.seul.org/viewcvs/viewcvs.cgi/branches/tylerthemovie/?root=PyGame&sortby=date

Vicent Marti:
http://www.seul.org/viewcvs/viewcvs.cgi/branches/pgreloaded/?root=PyGame&sortby=date

Werner Laurensse:
not sure where Werners repository is?  Using git?  Perhaps a branch  
can be set up in svn where you could publish to once a week or so?   
Werner/Nirav, do you have a link?





cheers,

Re: [pygame] [GSOC] svn and compile problem with pygame-svn

[Lenard Lindstrom]

René Dudfield wrote:
On Mon, May 4, 2009 at 4:44 PM, Lenard Lindstrom > wrote:


Ok, the transform problems were caused by the Mac not having MMX,
so some untested code was conditionally compiled. As for the unit
test errors I don't know what is happening there. Some newly added
unit tests to base_test.py were ported back from the python3
trunk. That is where the Python 2.5 and 2.6 builds fail. What is
happening to Python 2.4 is a mystery.

Lenard



hi,


it looks like that test is failing because of the missing scrap module. 

I guess that test was disabled before.  So if we put in a new scrap 
for osx then that test should pass.



The tests were newly added to base_test.py in the python3 branch. They 
found their way into the trunk with the merge. I will add a check for 
the scrap module.


Lenard

Re: [pygame] [GSOC] svn and compile problem with pygame-svn

[René Dudfield]

On Mon, May 4, 2009 at 4:44 PM, Lenard Lindstrom  wrote:

> Ok, the transform problems were caused by the Mac not having MMX, so some
> untested code was conditionally compiled. As for the unit test errors I
> don't know what is happening there. Some newly added unit tests to
> base_test.py were ported back from the python3 trunk. That is where the
> Python 2.5 and 2.6 builds fail. What is happening to Python 2.4 is a
> mystery.
>
> Lenard
>


hi,


it looks like that test is failing because of the missing scrap module.

I guess that test was disabled before.  So if we put in a new scrap for osx
then that test should pass.


cheers,

Re: [pygame] [GSOC] svn and compile problem with pygame-svn

[Lenard Lindstrom]

Ok, the transform problems were caused by the Mac not having MMX, so 
some untested code was conditionally compiled. As for the unit test 
errors I don't know what is happening there. Some newly added unit tests 
to base_test.py were ported back from the python3 trunk. That is where 
the Python 2.5 and 2.6 builds fail. What is happening to Python 2.4 is a 
mystery.


Lenard

René Dudfield wrote:
... and it looks like Lenard has fixed it already too.  Latest svn 
trunk compiles on osx again.


cu,

On Mon, May 4, 2009 at 8:03 AM, René Dudfield > wrote:


hi,

looks like some changes from the py3k merge that Lenard just did.

Note, that the build bot last built successfully: revision 2047

So you can always check out that revision, that built successfully
on osx, until trunk is fixed.



This is also points out how changes on one platform can easily
break other platforms, and why the buildbot is so awesome.


cu,




On Mon, May 4, 2009 at 1:33 AM, Brian Fisher
mailto:br...@hamsterrepublic.com>> wrote:

My automated build machine is having the same problem on OS X,
so I'd say it's nothing wrong with your setup:
http://thorbrian.com/pygame/builds.php


On Sun, May 3, 2009 at 12:14 AM, el lauwer
mailto:el.lau...@gmail.com>> wrote:

Oi,

Ok, I will use git as for my daily work, and submit my
code to svn if
I need a global feedback.

I have solved the problem with architecture, but now I get
the following
syntax error in the pygame code:

rc/transform.c:57: error: syntax error before ‘_state’
src/transform.c:58: warning: initialization makes integer
from pointer without a cast
src/transform.c:59: error: ‘filter_shrink_X_ONLYC’
undeclared here (not in a function)
src/transform.c:59: warning: excess elements in scalar
initializer
src/transform.c:59: warning: (near initialization for
‘_state’)
src/transform.c:60: error: ‘filter_shrink_Y_ONLYC’
undeclared here (not in a function)
src/transform.c:60: warning: excess elements in scalar
initializer
src/transform.c:60: warning: (near initialization for
‘_state’)
src/transform.c:61: error: ‘filter_expand_X_ONLYC’
undeclared here (not in a function)
src/transform.c:61: warning: excess elements in scalar
initializer
src/transform.c:61: warning: (near initialization for
‘_state’)
src/transform.c:62: error: ‘filter_expand_Y_ONLYC’
undeclared here (not in a function)
src/transform.c:62: warning: excess elements in scalar
initializer
src/transform.c:62: warning: (near initialization for
‘_state’)
src/transform.c:62: warning: data definition has no type
or storage class
src/transform.c: In function ‘surf_scalesmooth’:
src/transform.c:1416: warning: passing argument 3 of
‘scalesmooth’ from incompatible pointer type
src/transform.c: In function ‘surf_get_smoothscale_backend’:
src/transform.c:1437: error: request for member
‘filter_type’ in something not a structure or union
src/transform.c: In function ‘surf_set_smoothscale_backend’:
src/transform.c:1443: warning: initialization from
incompatible pointer type
src/transform.c:1497: error: ‘filter_type’ undeclared
(first use in this function)
src/transform.c:1497: error: (Each undeclared identifier
is reported only once
src/transform.c:1497: error: for each function it appears in.)
src/transform.c: In function ‘inittransform’:
src/transform.c:2739: warning: assignment from
incompatible pointer type
lipo: can't figure out the architecture type of:
/var/tmp//cc47AiT3.out

error: command 'gcc' failed with exit status 1

Re: [pygame] [GSOC] svn and compile problem with pygame-svn

[René Dudfield]

... and it looks like Lenard has fixed it already too.  Latest svn trunk
compiles on osx again.

cu,

On Mon, May 4, 2009 at 8:03 AM, René Dudfield  wrote:

> hi,
>
> looks like some changes from the py3k merge that Lenard just did.
>
> Note, that the build bot last built successfully: revision 2047
>
> So you can always check out that revision, that built successfully on osx,
> until trunk is fixed.
>
>
>
> This is also points out how changes on one platform can easily break other
> platforms, and why the buildbot is so awesome.
>
>
> cu,
>
>
>
>
> On Mon, May 4, 2009 at 1:33 AM, Brian Fisher wrote:
>
>> My automated build machine is having the same problem on OS X, so I'd say
>> it's nothing wrong with your setup:
>> http://thorbrian.com/pygame/builds.php
>>
>>
>> On Sun, May 3, 2009 at 12:14 AM, el lauwer  wrote:
>>
>>> Oi,
>>>
>>> Ok, I will use git as for my daily work, and submit my code to svn if
>>> I need a global feedback.
>>>
>>> I have solved the problem with architecture, but now I get the following
>>> syntax error in the pygame code:
>>>
>>> rc/transform.c:57: error: syntax error before ‘_state’
>>> src/transform.c:58: warning: initialization makes integer from pointer
>>> without a cast
>>> src/transform.c:59: error: ‘filter_shrink_X_ONLYC’ undeclared here (not
>>> in a function)
>>> src/transform.c:59: warning: excess elements in scalar initializer
>>> src/transform.c:59: warning: (near initialization for ‘_state’)
>>> src/transform.c:60: error: ‘filter_shrink_Y_ONLYC’ undeclared here (not
>>> in a function)
>>> src/transform.c:60: warning: excess elements in scalar initializer
>>> src/transform.c:60: warning: (near initialization for ‘_state’)
>>> src/transform.c:61: error: ‘filter_expand_X_ONLYC’ undeclared here (not
>>> in a function)
>>> src/transform.c:61: warning: excess elements in scalar initializer
>>> src/transform.c:61: warning: (near initialization for ‘_state’)
>>> src/transform.c:62: error: ‘filter_expand_Y_ONLYC’ undeclared here (not
>>> in a function)
>>> src/transform.c:62: warning: excess elements in scalar initializer
>>> src/transform.c:62: warning: (near initialization for ‘_state’)
>>> src/transform.c:62: warning: data definition has no type or storage class
>>> src/transform.c: In function ‘surf_scalesmooth’:
>>> src/transform.c:1416: warning: passing argument 3 of ‘scalesmooth’ from
>>> incompatible pointer type
>>> src/transform.c: In function ‘surf_get_smoothscale_backend’:
>>> src/transform.c:1437: error: request for member ‘filter_type’ in
>>> something not a structure or union
>>> src/transform.c: In function ‘surf_set_smoothscale_backend’:
>>> src/transform.c:1443: warning: initialization from incompatible pointer
>>> type
>>> src/transform.c:1497: error: ‘filter_type’ undeclared (first use in this
>>> function)
>>> src/transform.c:1497: error: (Each undeclared identifier is reported only
>>> once
>>> src/transform.c:1497: error: for each function it appears in.)
>>> src/transform.c: In function ‘inittransform’:
>>> src/transform.c:2739: warning: assignment from incompatible pointer type
>>> lipo: can't figure out the architecture type of: /var/tmp//cc47AiT3.out
>>> error: command 'gcc' failed with exit status 1
>>>
>>> Slu
>>>
>>>
>>>
>>>
>>> On 3-mei-09, at 07:48, Nirav Patel wrote:
>>>
>>>  I personally found/find it useful to use a personal git repo, and use
 git-svn to stay up to date with the Pygame SVN.  You can use "git svn
 rebase" to keep your repo up to date with upstream and then commit
 with "git svn dcommit" when you have code that others can
 use/test/hack.

 There is a decent guide for using git-svn with github here:
 http://www.fnokd.com/2008/08/20/mirroring-svn-repository-to-github/

 That is also useful so you have a repo to work in until 1.9 is
 released and you can start committing to Pygame SVN.

 Nirav

 On Sun, May 3, 2009 at 1:10 AM, René Dudfield  wrote:

> Hi,
>
> more below...
>
> On Sun, May 3, 2009 at 2:50 PM, el lauwer  wrote:
>
>>
>> Oi,
>>
>> I am installing the latest version of pygame on svn,
>> so I can start coding on my camera module. I am
>> installing it under virtualenv so I can keep using
>> the stable pygame release for my current games.
>>
>> 1)
>> I recently reseaved a svn account for the pygame
>> svn repository. How do you sugest I use this account
>> during the development prossess, should I use it to
>> commit all my changes to the main brange, or should
>> I make a personal brange just for my work on the
>> camera module. Can I use my github account instead,
>> if so, what must I do with the changes and bug
>> fixel to the main pygame development brange.
>>
>
>
> You might want to work on the main trunk, or not... depending on a
> number of
> things.
>
> Either a separate branch or in your git hub is probably a good way to
> g

Re: [pygame] [GSOC] svn and compile problem with pygame-svn

[René Dudfield]

hi,

looks like some changes from the py3k merge that Lenard just did.

Note, that the build bot last built successfully: revision 2047

So you can always check out that revision, that built successfully on osx,
until trunk is fixed.



This is also points out how changes on one platform can easily break other
platforms, and why the buildbot is so awesome.


cu,



On Mon, May 4, 2009 at 1:33 AM, Brian Fisher wrote:

> My automated build machine is having the same problem on OS X, so I'd say
> it's nothing wrong with your setup:
> http://thorbrian.com/pygame/builds.php
>
>
> On Sun, May 3, 2009 at 12:14 AM, el lauwer  wrote:
>
>> Oi,
>>
>> Ok, I will use git as for my daily work, and submit my code to svn if
>> I need a global feedback.
>>
>> I have solved the problem with architecture, but now I get the following
>> syntax error in the pygame code:
>>
>> rc/transform.c:57: error: syntax error before ‘_state’
>> src/transform.c:58: warning: initialization makes integer from pointer
>> without a cast
>> src/transform.c:59: error: ‘filter_shrink_X_ONLYC’ undeclared here (not in
>> a function)
>> src/transform.c:59: warning: excess elements in scalar initializer
>> src/transform.c:59: warning: (near initialization for ‘_state’)
>> src/transform.c:60: error: ‘filter_shrink_Y_ONLYC’ undeclared here (not in
>> a function)
>> src/transform.c:60: warning: excess elements in scalar initializer
>> src/transform.c:60: warning: (near initialization for ‘_state’)
>> src/transform.c:61: error: ‘filter_expand_X_ONLYC’ undeclared here (not in
>> a function)
>> src/transform.c:61: warning: excess elements in scalar initializer
>> src/transform.c:61: warning: (near initialization for ‘_state’)
>> src/transform.c:62: error: ‘filter_expand_Y_ONLYC’ undeclared here (not in
>> a function)
>> src/transform.c:62: warning: excess elements in scalar initializer
>> src/transform.c:62: warning: (near initialization for ‘_state’)
>> src/transform.c:62: warning: data definition has no type or storage class
>> src/transform.c: In function ‘surf_scalesmooth’:
>> src/transform.c:1416: warning: passing argument 3 of ‘scalesmooth’ from
>> incompatible pointer type
>> src/transform.c: In function ‘surf_get_smoothscale_backend’:
>> src/transform.c:1437: error: request for member ‘filter_type’ in something
>> not a structure or union
>> src/transform.c: In function ‘surf_set_smoothscale_backend’:
>> src/transform.c:1443: warning: initialization from incompatible pointer
>> type
>> src/transform.c:1497: error: ‘filter_type’ undeclared (first use in this
>> function)
>> src/transform.c:1497: error: (Each undeclared identifier is reported only
>> once
>> src/transform.c:1497: error: for each function it appears in.)
>> src/transform.c: In function ‘inittransform’:
>> src/transform.c:2739: warning: assignment from incompatible pointer type
>> lipo: can't figure out the architecture type of: /var/tmp//cc47AiT3.out
>> error: command 'gcc' failed with exit status 1
>>
>> Slu
>>
>>
>>
>>
>> On 3-mei-09, at 07:48, Nirav Patel wrote:
>>
>>  I personally found/find it useful to use a personal git repo, and use
>>> git-svn to stay up to date with the Pygame SVN.  You can use "git svn
>>> rebase" to keep your repo up to date with upstream and then commit
>>> with "git svn dcommit" when you have code that others can
>>> use/test/hack.
>>>
>>> There is a decent guide for using git-svn with github here:
>>> http://www.fnokd.com/2008/08/20/mirroring-svn-repository-to-github/
>>>
>>> That is also useful so you have a repo to work in until 1.9 is
>>> released and you can start committing to Pygame SVN.
>>>
>>> Nirav
>>>
>>> On Sun, May 3, 2009 at 1:10 AM, René Dudfield  wrote:
>>>
 Hi,

 more below...

 On Sun, May 3, 2009 at 2:50 PM, el lauwer  wrote:

>
> Oi,
>
> I am installing the latest version of pygame on svn,
> so I can start coding on my camera module. I am
> installing it under virtualenv so I can keep using
> the stable pygame release for my current games.
>
> 1)
> I recently reseaved a svn account for the pygame
> svn repository. How do you sugest I use this account
> during the development prossess, should I use it to
> commit all my changes to the main brange, or should
> I make a personal brange just for my work on the
> camera module. Can I use my github account instead,
> if so, what must I do with the changes and bug
> fixel to the main pygame development brange.
>


 You might want to work on the main trunk, or not... depending on a
 number of
 things.

 Either a separate branch or in your git hub is probably a good way to
 go.
 If you put things in svn, then it's easier for some of the pygame
 developers
 to watch your work, and maybe even make changes.  However it's up to
 you.

 Best to merge your work in occasionally into a svn branch at least.   Or
 send the mailing list a link to your

Re: [pygame] [GSOC] svn and compile problem with pygame-svn

[Brian Fisher]

My automated build machine is having the same problem on OS X, so I'd say
it's nothing wrong with your setup:
http://thorbrian.com/pygame/builds.php

On Sun, May 3, 2009 at 12:14 AM, el lauwer  wrote:

> Oi,
>
> Ok, I will use git as for my daily work, and submit my code to svn if
> I need a global feedback.
>
> I have solved the problem with architecture, but now I get the following
> syntax error in the pygame code:
>
> rc/transform.c:57: error: syntax error before ‘_state’
> src/transform.c:58: warning: initialization makes integer from pointer
> without a cast
> src/transform.c:59: error: ‘filter_shrink_X_ONLYC’ undeclared here (not in
> a function)
> src/transform.c:59: warning: excess elements in scalar initializer
> src/transform.c:59: warning: (near initialization for ‘_state’)
> src/transform.c:60: error: ‘filter_shrink_Y_ONLYC’ undeclared here (not in
> a function)
> src/transform.c:60: warning: excess elements in scalar initializer
> src/transform.c:60: warning: (near initialization for ‘_state’)
> src/transform.c:61: error: ‘filter_expand_X_ONLYC’ undeclared here (not in
> a function)
> src/transform.c:61: warning: excess elements in scalar initializer
> src/transform.c:61: warning: (near initialization for ‘_state’)
> src/transform.c:62: error: ‘filter_expand_Y_ONLYC’ undeclared here (not in
> a function)
> src/transform.c:62: warning: excess elements in scalar initializer
> src/transform.c:62: warning: (near initialization for ‘_state’)
> src/transform.c:62: warning: data definition has no type or storage class
> src/transform.c: In function ‘surf_scalesmooth’:
> src/transform.c:1416: warning: passing argument 3 of ‘scalesmooth’ from
> incompatible pointer type
> src/transform.c: In function ‘surf_get_smoothscale_backend’:
> src/transform.c:1437: error: request for member ‘filter_type’ in something
> not a structure or union
> src/transform.c: In function ‘surf_set_smoothscale_backend’:
> src/transform.c:1443: warning: initialization from incompatible pointer
> type
> src/transform.c:1497: error: ‘filter_type’ undeclared (first use in this
> function)
> src/transform.c:1497: error: (Each undeclared identifier is reported only
> once
> src/transform.c:1497: error: for each function it appears in.)
> src/transform.c: In function ‘inittransform’:
> src/transform.c:2739: warning: assignment from incompatible pointer type
> lipo: can't figure out the architecture type of: /var/tmp//cc47AiT3.out
> error: command 'gcc' failed with exit status 1
>
> Slu
>
>
>
>
> On 3-mei-09, at 07:48, Nirav Patel wrote:
>
>  I personally found/find it useful to use a personal git repo, and use
>> git-svn to stay up to date with the Pygame SVN.  You can use "git svn
>> rebase" to keep your repo up to date with upstream and then commit
>> with "git svn dcommit" when you have code that others can
>> use/test/hack.
>>
>> There is a decent guide for using git-svn with github here:
>> http://www.fnokd.com/2008/08/20/mirroring-svn-repository-to-github/
>>
>> That is also useful so you have a repo to work in until 1.9 is
>> released and you can start committing to Pygame SVN.
>>
>> Nirav
>>
>> On Sun, May 3, 2009 at 1:10 AM, René Dudfield  wrote:
>>
>>> Hi,
>>>
>>> more below...
>>>
>>> On Sun, May 3, 2009 at 2:50 PM, el lauwer  wrote:
>>>

 Oi,

 I am installing the latest version of pygame on svn,
 so I can start coding on my camera module. I am
 installing it under virtualenv so I can keep using
 the stable pygame release for my current games.

 1)
 I recently reseaved a svn account for the pygame
 svn repository. How do you sugest I use this account
 during the development prossess, should I use it to
 commit all my changes to the main brange, or should
 I make a personal brange just for my work on the
 camera module. Can I use my github account instead,
 if so, what must I do with the changes and bug
 fixel to the main pygame development brange.

>>>
>>>
>>> You might want to work on the main trunk, or not... depending on a number
>>> of
>>> things.
>>>
>>> Either a separate branch or in your git hub is probably a good way to go.
>>> If you put things in svn, then it's easier for some of the pygame
>>> developers
>>> to watch your work, and maybe even make changes.  However it's up to you.
>>>
>>> Best to merge your work in occasionally into a svn branch at least.   Or
>>> send the mailing list a link to your work when you've committed something
>>> you'd like people to look at or merge in.
>>>
>>> Then when your work is getting along, talk about merging it into the
>>> trunk
>>> with the mailing list and other developers.  If no one has changed any of
>>> the files you have changed, then it's probably ok.
>>>
>>> Working in the trunk lets you take advantage of some other things... like
>>> the build bots which build on mac/win python2.4 python2.5 python2.6 and
>>> run
>>> the tests for you.  So it can save you a lot of testing work.
>>>
>>> Say yo

Re: [pygame] [GSOC] svn and compile problem with pygame-svn

[el lauwer]

Oi,

Ok, I will use git as for my daily work, and submit my code to svn if
I need a global feedback.

I have solved the problem with architecture, but now I get the following
syntax error in the pygame code:

rc/transform.c:57: error: syntax error before ‘_state’
src/transform.c:58: warning: initialization makes integer from pointer  
without a cast
src/transform.c:59: error: ‘filter_shrink_X_ONLYC’ undeclared here  
(not in a function)

src/transform.c:59: warning: excess elements in scalar initializer
src/transform.c:59: warning: (near initialization for ‘_state’)
src/transform.c:60: error: ‘filter_shrink_Y_ONLYC’ undeclared here  
(not in a function)

src/transform.c:60: warning: excess elements in scalar initializer
src/transform.c:60: warning: (near initialization for ‘_state’)
src/transform.c:61: error: ‘filter_expand_X_ONLYC’ undeclared here  
(not in a function)

src/transform.c:61: warning: excess elements in scalar initializer
src/transform.c:61: warning: (near initialization for ‘_state’)
src/transform.c:62: error: ‘filter_expand_Y_ONLYC’ undeclared here  
(not in a function)

src/transform.c:62: warning: excess elements in scalar initializer
src/transform.c:62: warning: (near initialization for ‘_state’)
src/transform.c:62: warning: data definition has no type or storage  
class

src/transform.c: In function ‘surf_scalesmooth’:
src/transform.c:1416: warning: passing argument 3 of ‘scalesmooth’  
from incompatible pointer type

src/transform.c: In function ‘surf_get_smoothscale_backend’:
src/transform.c:1437: error: request for member ‘filter_type’ in  
something not a structure or union

src/transform.c: In function ‘surf_set_smoothscale_backend’:
src/transform.c:1443: warning: initialization from incompatible  
pointer type
src/transform.c:1497: error: ‘filter_type’ undeclared (first use in  
this function)
src/transform.c:1497: error: (Each undeclared identifier is reported  
only once

src/transform.c:1497: error: for each function it appears in.)
src/transform.c: In function ‘inittransform’:
src/transform.c:2739: warning: assignment from incompatible pointer type
lipo: can't figure out the architecture type of: /var/tmp//cc47AiT3.out
error: command 'gcc' failed with exit status 1

Slu



On 3-mei-09, at 07:48, Nirav Patel wrote:


I personally found/find it useful to use a personal git repo, and use
git-svn to stay up to date with the Pygame SVN.  You can use "git svn
rebase" to keep your repo up to date with upstream and then commit
with "git svn dcommit" when you have code that others can
use/test/hack.

There is a decent guide for using git-svn with github here:
http://www.fnokd.com/2008/08/20/mirroring-svn-repository-to-github/

That is also useful so you have a repo to work in until 1.9 is
released and you can start committing to Pygame SVN.

Nirav

On Sun, May 3, 2009 at 1:10 AM, René Dudfield   
wrote:

Hi,

more below...

On Sun, May 3, 2009 at 2:50 PM, el lauwer   
wrote:


Oi,

I am installing the latest version of pygame on svn,
so I can start coding on my camera module. I am
installing it under virtualenv so I can keep using
the stable pygame release for my current games.

1)
I recently reseaved a svn account for the pygame
svn repository. How do you sugest I use this account
during the development prossess, should I use it to
commit all my changes to the main brange, or should
I make a personal brange just for my work on the
camera module. Can I use my github account instead,
if so, what must I do with the changes and bug
fixel to the main pygame development brange.



You might want to work on the main trunk, or not... depending on a  
number of

things.

Either a separate branch or in your git hub is probably a good way  
to go.
If you put things in svn, then it's easier for some of the pygame  
developers
to watch your work, and maybe even make changes.  However it's up  
to you.


Best to merge your work in occasionally into a svn branch at  
least.   Or
send the mailing list a link to your work when you've committed  
something

you'd like people to look at or merge in.

Then when your work is getting along, talk about merging it into  
the trunk
with the mailing list and other developers.  If no one has changed  
any of

the files you have changed, then it's probably ok.

Working in the trunk lets you take advantage of some other  
things... like
the build bots which build on mac/win python2.4 python2.5 python2.6  
and run

the tests for you.  So it can save you a lot of testing work.

Say you wanted to make some changes to surface.c and a bunch of  
others that
aren't part of the camera module directly, and didn't commit to  
trunk for a
few weeks... there's a good chance someone else might make changes  
to those

files.

As long as you communicate with other devs what your working on it  
should be

fine.

Re: [pygame] [GSOC] svn and compile problem with pygame-svn

[Nirav Patel]

I personally found/find it useful to use a personal git repo, and use
git-svn to stay up to date with the Pygame SVN.  You can use "git svn
rebase" to keep your repo up to date with upstream and then commit
with "git svn dcommit" when you have code that others can
use/test/hack.

There is a decent guide for using git-svn with github here:
http://www.fnokd.com/2008/08/20/mirroring-svn-repository-to-github/

That is also useful so you have a repo to work in until 1.9 is
released and you can start committing to Pygame SVN.

Nirav

On Sun, May 3, 2009 at 1:10 AM, René Dudfield  wrote:
> Hi,
>
> more below...
>
> On Sun, May 3, 2009 at 2:50 PM, el lauwer  wrote:
>>
>> Oi,
>>
>> I am installing the latest version of pygame on svn,
>> so I can start coding on my camera module. I am
>> installing it under virtualenv so I can keep using
>> the stable pygame release for my current games.
>>
>> 1)
>> I recently reseaved a svn account for the pygame
>> svn repository. How do you sugest I use this account
>> during the development prossess, should I use it to
>> commit all my changes to the main brange, or should
>> I make a personal brange just for my work on the
>> camera module. Can I use my github account instead,
>> if so, what must I do with the changes and bug
>> fixel to the main pygame development brange.
>
>
> You might want to work on the main trunk, or not... depending on a number of
> things.
>
> Either a separate branch or in your git hub is probably a good way to go.
> If you put things in svn, then it's easier for some of the pygame developers
> to watch your work, and maybe even make changes.  However it's up to you.
>
> Best to merge your work in occasionally into a svn branch at least.   Or
> send the mailing list a link to your work when you've committed something
> you'd like people to look at or merge in.
>
> Then when your work is getting along, talk about merging it into the trunk
> with the mailing list and other developers.  If no one has changed any of
> the files you have changed, then it's probably ok.
>
> Working in the trunk lets you take advantage of some other things... like
> the build bots which build on mac/win python2.4 python2.5 python2.6 and run
> the tests for you.  So it can save you a lot of testing work.
>
> Say you wanted to make some changes to surface.c and a bunch of others that
> aren't part of the camera module directly, and didn't commit to trunk for a
> few weeks... there's a good chance someone else might make changes to those
> files.
>
> As long as you communicate with other devs what your working on it should be
> fine.
>

Re: [pygame] [GSOC] svn and compile problem with pygame-svn

[René Dudfield]

Hi,

more below...

On Sun, May 3, 2009 at 2:50 PM, el lauwer  wrote:

> Oi,
>
> I am installing the latest version of pygame on svn,
> so I can start coding on my camera module. I am
> installing it under virtualenv so I can keep using
> the stable pygame release for my current games.
>
> 1)
> I recently reseaved a svn account for the pygame
> svn repository. How do you sugest I use this account
> during the development prossess, should I use it to
> commit all my changes to the main brange, or should
> I make a personal brange just for my work on the
> camera module. Can I use my github account instead,
> if so, what must I do with the changes and bug
> fixel to the main pygame development brange.
>


You might want to work on the main trunk, or not... depending on a number of
things.

Either a separate branch or in your git hub is probably a good way to go.
If you put things in svn, then it's easier for some of the pygame developers
to watch your work, and maybe even make changes.  However it's up to you.

Best to merge your work in occasionally into a svn branch at least.   Or
send the mailing list a link to your work when you've committed something
you'd like people to look at or merge in.

Then when your work is getting along, talk about merging it into the trunk
with the mailing list and other developers.  If no one has changed any of
the files you have changed, then it's probably ok.

Working in the trunk lets you take advantage of some other things... like
the build bots which build on mac/win python2.4 python2.5 python2.6 and run
the tests for you.  So it can save you a lot of testing work.

Say you wanted to make some changes to surface.c and a bunch of others that
aren't part of the camera module directly, and didn't commit to trunk for a
few weeks... there's a good chance someone else might make changes to those
files.

As long as you communicate with other devs what your working on it should be
fine.





>
> 2)
> When I try to compile the pygame version with help
> of the MacSVNCompile doc I get the following error:
>
> $ python config.py
>
> Hunting dependencies...
> Framework SDL found
> Framework SDL_ttf found
> Framework SDL_image found
> Framework SDL_mixer found
> Framework smpeg found
> PNG : found
> JPEG: found
> SCRAP   : not found
> PORTMIDI: not found
> Framework CoreMidi found
>
> $ python setup.py build
>
> ...
>
> ld warning: in /opt/local/lib/libpng.a, file is not of required
> architecture
> ld warning: in /opt/local/lib/libjpeg.a, file is not of required
> architecture
> ld: in /opt/local/lib/libz.1.dylib, file is not of required architecture
> for architecture ppc
> collect2: ld returned 1 exit status
> lipo: can't open input file:
> /var/folders/sd/sdb8APIWH4qmd53S-O6k8k+++TI/-Tmp-//cct7zCL5.out (No such
> file or directory)
> error: command 'gcc' failed with exit status 1
>
>
> In case i should matter, I use fink instead of macports.
> Any idea on how to solve this.
>
>

it looks like the files you're linking against do not have a ppc version in
them.

There's a note in the compile doc about how to get a universal binary, if
you can't compile one yourself.
http://pygame.org/wiki/MacCompile?parent=index#%20Install%20Universal%20build%20libjpeg%20&%20libpng




cheers,

Re: [pygame] GSOC: Extending Camera support for PyGame to Mac OSX Updates!

[Nirav Patel]

A kalman filter is I think implementable in numpy without much
difficulty, and numpy is already a dependency.

It depends on what you are looking for, but searching Google Scholar
on a specific topic is a great way to learn about various algorithms.

Nirav

On Fri, Apr 10, 2009 at 5:07 AM, el lauwer  wrote:
> Hoi,
>
> Those mask functions sound useful. Do you think it would be a good idea to
> implement a kalman filter in pygame that can be used for color based object
> tracking.
>
> Is there a good place I can find computer vision related information.
>
> Grtz
>
>
> On 9-apr-09, at 18:08, Nirav Patel wrote:
>
>> Excellent.  Making your code available as you work on it is a great
>> idea, especially for something like this that needs to be tested on a
>> wide range of hardware.
>>
>> About pattern recognition, something like face recognition is probably
>> too heavy for pygame purposes and would be better suited for pyehci or
>> opencv-python.  However, extending some of the basic computer vision
>> stuff would certainly be useful, like higher or even arbitrary moments
>> [0] in masks, thresholding with hysteresis, hole detection in masks, a
>> mask to surface function, etc.
>>
>> Nirav
>>
>> [0] http://en.wikipedia.org/wiki/Moment_(mathematics)
>>
>> On Thu, Apr 9, 2009 at 11:44 AM, el lauwer  wrote:
>>>
>>> Hoi,
>>>
>>> I recently posted my proposal for GSOC to socghop. There where some
>>> comments
>>> about the content, so I have updated my proposal, and hereby posted it to
>>> this mailing list so guys can comment further on my proposal...
>>>
>>>
>>> Rene Dudfield maid the following remark about my original proposal:
>>>
>>> "
>>> Also a section on user testing would be good.  Where you ask others to
>>> download pygame to run your tests - to make sure it works ok with their
>>> computer/camera.
>>>
>>> Finally a change in your proposal to seek feedback from the community on
>>> what changes you will do after the osx stuff is finished would be good.
>>>  Since I have a feeling that you should have some time left over at the
>>> end.
>>> "
>>> I am planning to make a branch of my code available on github.com so
>>> everybody who like can follow my daily work on the project.
>>> Later on in the project I intend to make some blog post about my work and
>>> post them on reddit.com/r/python, reddit.com/r/mac,
>>> pygame ML and other communities so people can test my code. I have 2 mac
>>> at
>>> home and know some other people with macs who
>>> would be willing to test out my work.
>>>
>>> Pattern recognition is a complicated subject, But I think that it would
>>> be a
>>> good thing if there where some basic pattern recognition
>>> included like a steering wheel or a face. This would allow any gygame
>>> programmer to use this feartues in there game without any
>>> additional work. A possible interesting project to experiment with could
>>> be http://code.google.com/p/ehci/wiki/pyehci
>>>
>>> If you have any suggestions, remarks or questions please comment.
>>>
>>> original
>>> proposal:
>>> http://socghop.appspot.com/student_proposal/show/google/gsoc2009/abe/t123872941171
>>> updated
>>> proposal: http://socghop.appspot.com/document/show/user/abe/gsoc_updates
>>>
>>>
>>> =
>>>
>>> Updated proposal:
>>>
>>> Instructions
>>>
>>> Start by getting in contact with the mentor(s) familiar with your
>>> proposed
>>> project.  They will help you polish your proposal and introduce you to
>>> the
>>> developer team you'd be working with over the Summer.
>>>
>>>
>>>
>>> Summary:
>>>
>>> Nirav Patel has recently implemented camera support into pygame as a way
>>> to
>>> interact with a game. However, this camera module is limited to the Linux
>>> platform. The goal of my project is to extend this camera module to the
>>> Mac
>>> OSX platform, and thus extending the portability of games written in
>>> pygame
>>> that use a webcam as mean to interact with the player.
>>>
>>> I will be using the OSX QiuckTime multimedia framework to work with the
>>> camera. The camera module shall be implemented in C as a python
>>> extension.
>>> It is my intension to fully port the capabilities of the existing camera
>>> module. If there are any existing capabilities in the QT Isight
>>> framework,
>>> that could be useful to have in the pygame module, I will make these
>>> available by writhing a wrapper around them.
>>>
>>> I will use pyobjc to experiment during the project. For the final code I
>>> will use objc and C wrappers,since pyobjc is no longer used in
>>> pygane.
>>>
>>> When I am finished implementing the camera module for OSX, I will work on
>>> optimizing the existing code, like optimizing the sbggr8_to_rgb function.
>>> Ather this I will write documentation and a simple game to demonstrate
>>> the
>>> capabilities.
>>>
>>> I am planning to make a branch of my code available on github.com so
>>> everybody who like can follow my daily work on the proje

Re: [pygame] GSOC: Extending Camera support for PyGame to Mac OSX Updates!

[el lauwer]

Hoi,

Those mask functions sound useful. Do you think it would be a good  
idea to
implement a kalman filter in pygame that can be used for color based  
object

tracking.

Is there a good place I can find computer vision related information.

Grtz


On 9-apr-09, at 18:08, Nirav Patel wrote:


Excellent.  Making your code available as you work on it is a great
idea, especially for something like this that needs to be tested on a
wide range of hardware.

About pattern recognition, something like face recognition is probably
too heavy for pygame purposes and would be better suited for pyehci or
opencv-python.  However, extending some of the basic computer vision
stuff would certainly be useful, like higher or even arbitrary moments
[0] in masks, thresholding with hysteresis, hole detection in masks, a
mask to surface function, etc.

Nirav

[0] http://en.wikipedia.org/wiki/Moment_(mathematics)

On Thu, Apr 9, 2009 at 11:44 AM, el lauwer   
wrote:

Hoi,

I recently posted my proposal for GSOC to socghop. There where some  
comments
about the content, so I have updated my proposal, and hereby posted  
it to

this mailing list so guys can comment further on my proposal...


Rene Dudfield maid the following remark about my original proposal:

"
Also a section on user testing would be good.  Where you ask others  
to
download pygame to run your tests - to make sure it works ok with  
their

computer/camera.

Finally a change in your proposal to seek feedback from the  
community on
what changes you will do after the osx stuff is finished would be  
good.
 Since I have a feeling that you should have some time left over at  
the end.

"
I am planning to make a branch of my code available on github.com so
everybody who like can follow my daily work on the project.
Later on in the project I intend to make some blog post about my  
work and

post them on reddit.com/r/python, reddit.com/r/mac,
pygame ML and other communities so people can test my code. I have  
2 mac at

home and know some other people with macs who
would be willing to test out my work.

Pattern recognition is a complicated subject, But I think that it  
would be a

good thing if there where some basic pattern recognition
included like a steering wheel or a face. This would allow any gygame
programmer to use this feartues in there game without any
additional work. A possible interesting project to experiment with  
could

be http://code.google.com/p/ehci/wiki/pyehci

If you have any suggestions, remarks or questions please comment.

original
proposal: 
http://socghop.appspot.com/student_proposal/show/google/gsoc2009/abe/t123872941171
updated
proposal: http://socghop.appspot.com/document/show/user/abe/gsoc_updates


=

Updated proposal:

Instructions

Start by getting in contact with the mentor(s) familiar with your  
proposed
project.  They will help you polish your proposal and introduce you  
to the

developer team you'd be working with over the Summer.



Summary:

Nirav Patel has recently implemented camera support into pygame as  
a way to
interact with a game. However, this camera module is limited to the  
Linux
platform. The goal of my project is to extend this camera module to  
the Mac
OSX platform, and thus extending the portability of games written  
in pygame

that use a webcam as mean to interact with the player.

I will be using the OSX QiuckTime multimedia framework to work with  
the
camera. The camera module shall be implemented in C as a python  
extension.
It is my intension to fully port the capabilities of the existing  
camera
module. If there are any existing capabilities in the QT Isight  
framework,

that could be useful to have in the pygame module, I will make these
available by writhing a wrapper around them.

I will use pyobjc to experiment during the project. For the final  
code I

will use objc and C wrappers,since pyobjc is no longer used in
pygane.

When I am finished implementing the camera module for OSX, I will  
work on
optimizing the existing code, like optimizing the sbggr8_to_rgb  
function.
Ather this I will write documentation and a simple game to  
demonstrate the

capabilities.

I am planning to make a branch of my code available on github.com so
everybody who like can follow my daily work on the project.
Later on in the project I intend to make some blog post about my  
work and

post them on reddit.com/r/python, reddit.com/r/mac,
pygame ML and other communities so people can test my code. I have  
2 mac at

home and know some other people with macs who
would be willing to test out my work.

Pattern recognition is a complicated subject, But I think that it  
would be a

good thing if there where some basic pattern recognition
included like a steering wheel or a face. This would allow any gygame
programmer to use this feartues in there game without any
additional work. A possible interesting project to experiment with  
could

be http://cod

Re: [pygame] GSOC: Extending Camera support for PyGame to Mac OSX Updates!

[Nirav Patel]

Excellent.  Making your code available as you work on it is a great
idea, especially for something like this that needs to be tested on a
wide range of hardware.

About pattern recognition, something like face recognition is probably
too heavy for pygame purposes and would be better suited for pyehci or
opencv-python.  However, extending some of the basic computer vision
stuff would certainly be useful, like higher or even arbitrary moments
[0] in masks, thresholding with hysteresis, hole detection in masks, a
mask to surface function, etc.

Nirav

[0] http://en.wikipedia.org/wiki/Moment_(mathematics)

On Thu, Apr 9, 2009 at 11:44 AM, el lauwer  wrote:
> Hoi,
>
> I recently posted my proposal for GSOC to socghop. There where some comments
> about the content, so I have updated my proposal, and hereby posted it to
> this mailing list so guys can comment further on my proposal...
>
>
> Rene Dudfield maid the following remark about my original proposal:
>
> "
> Also a section on user testing would be good.  Where you ask others to
> download pygame to run your tests - to make sure it works ok with their
> computer/camera.
>
> Finally a change in your proposal to seek feedback from the community on
> what changes you will do after the osx stuff is finished would be good.
>  Since I have a feeling that you should have some time left over at the end.
> "
> I am planning to make a branch of my code available on github.com so
> everybody who like can follow my daily work on the project.
> Later on in the project I intend to make some blog post about my work and
> post them on reddit.com/r/python, reddit.com/r/mac,
> pygame ML and other communities so people can test my code. I have 2 mac at
> home and know some other people with macs who
> would be willing to test out my work.
>
> Pattern recognition is a complicated subject, But I think that it would be a
> good thing if there where some basic pattern recognition
> included like a steering wheel or a face. This would allow any gygame
> programmer to use this feartues in there game without any
> additional work. A possible interesting project to experiment with could
> be http://code.google.com/p/ehci/wiki/pyehci
>
> If you have any suggestions, remarks or questions please comment.
>
> original
> proposal: http://socghop.appspot.com/student_proposal/show/google/gsoc2009/abe/t123872941171
> updated
> proposal: http://socghop.appspot.com/document/show/user/abe/gsoc_updates
>
>
> =
>
> Updated proposal:
>
> Instructions
>
> Start by getting in contact with the mentor(s) familiar with your proposed
> project.  They will help you polish your proposal and introduce you to the
> developer team you'd be working with over the Summer.
>
>
>
> Summary:
>
> Nirav Patel has recently implemented camera support into pygame as a way to
> interact with a game. However, this camera module is limited to the Linux
> platform. The goal of my project is to extend this camera module to the Mac
> OSX platform, and thus extending the portability of games written in pygame
> that use a webcam as mean to interact with the player.
>
> I will be using the OSX QiuckTime multimedia framework to work with the
> camera. The camera module shall be implemented in C as a python extension.
> It is my intension to fully port the capabilities of the existing camera
> module. If there are any existing capabilities in the QT Isight framework,
> that could be useful to have in the pygame module, I will make these
> available by writhing a wrapper around them.
>
> I will use pyobjc to experiment during the project. For the final code I
> will use objc and C wrappers,since pyobjc is no longer used in
> pygane.
>
> When I am finished implementing the camera module for OSX, I will work on
> optimizing the existing code, like optimizing the sbggr8_to_rgb function.
> Ather this I will write documentation and a simple game to demonstrate the
> capabilities.
>
> I am planning to make a branch of my code available on github.com so
> everybody who like can follow my daily work on the project.
> Later on in the project I intend to make some blog post about my work and
> post them on reddit.com/r/python, reddit.com/r/mac,
> pygame ML and other communities so people can test my code. I have 2 mac at
> home and know some other people with macs who
> would be willing to test out my work.
>
> Pattern recognition is a complicated subject, But I think that it would be a
> good thing if there where some basic pattern recognition
> included like a steering wheel or a face. This would allow any gygame
> programmer to use this feartues in there game without any
> additional work. A possible interesting project to experiment with could
> be http://code.google.com/p/ehci/wiki/pyehci
>
> Schedule:
>
> I intent to work about 42 hours a week on the project
>
> April:
> Third week: study the camera implementation in linux version and see which
> methods must me re-i

Re: [pygame] GSoC Proposal Feedback

[Erisvaldo Junior]

Thank you. Nice feedback =]

I'll make the changes.

[]'s

--
From: "René Dudfield" 
Sent: Friday, April 03, 2009 12:47 PM
To: 
Subject: Re: [pygame] GSoC Proposal Feedback


one minor thing...
"To maintain backwards compatibility, Sprite would become a more
abstract type that supports either the actual Sprite system (which
would receive some improvements) and the growing up engine."

The end of this sentance sounds funny... "the growing up engine."

cheers,



On Sat, Apr 4, 2009 at 2:44 AM, René Dudfield  wrote:

Hi,

there are already layer sprite classes:
 eg. http://pygame.org/docs/ref/sprite.html#pygame.sprite.LayeredUpdates

Apart from that your application looks pretty good.  I like pretty
much all of your proposed enhancements (tiles, animated sprites, and
scenes).  I think they'd all be useful for many different games.

I'm going to work on giving as much feedback to all proposals as I can
over the weekend ( as will Marcus and Nirav in their time ).

The only other main point(which I've been giving to everyone applying)
I can give you is to consider submitting an application for one of the
core python ideas, or an application to another project (SDL for
example).  You are allowed to make multiple proposals - and are
allowed to modify your applications after the deadline.  We've had
lots of applications this year, and we will definitely not be able to
mentor them all, or even get allocated slots for all the projects.


cheers,




On Sat, Apr 4, 2009 at 1:56 AM, Erisvaldo Junior  
wrote:

Hi guys,

I would like to receive some feedback about my proposal "Improved Sprite 
and

Scene System for Pygame".

Draft at:
http://socghop.appspot.com/student_proposal/show/google/gsoc2009/erisvaldojunior/t123873664199?subscription=on

Also attached.

Please provide me some tips because deadline is very close. I'll 
appreciate.


Regards,

Erisvaldo.

Re: [pygame] GSoC Proposal Feedback

[René Dudfield]

one minor thing...
"To maintain backwards compatibility, Sprite would become a more
abstract type that supports either the actual Sprite system (which
would receive some improvements) and the growing up engine."

The end of this sentance sounds funny... "the growing up engine."

cheers,



On Sat, Apr 4, 2009 at 2:44 AM, René Dudfield  wrote:
> Hi,
>
> there are already layer sprite classes:
>  eg. http://pygame.org/docs/ref/sprite.html#pygame.sprite.LayeredUpdates
>
> Apart from that your application looks pretty good.  I like pretty
> much all of your proposed enhancements (tiles, animated sprites, and
> scenes).  I think they'd all be useful for many different games.
>
> I'm going to work on giving as much feedback to all proposals as I can
> over the weekend ( as will Marcus and Nirav in their time ).
>
> The only other main point(which I've been giving to everyone applying)
> I can give you is to consider submitting an application for one of the
> core python ideas, or an application to another project (SDL for
> example).  You are allowed to make multiple proposals - and are
> allowed to modify your applications after the deadline.  We've had
> lots of applications this year, and we will definitely not be able to
> mentor them all, or even get allocated slots for all the projects.
>
>
> cheers,
>
>
>
>
> On Sat, Apr 4, 2009 at 1:56 AM, Erisvaldo Junior  
> wrote:
>> Hi guys,
>>
>> I would like to receive some feedback about my proposal "Improved Sprite and
>> Scene System for Pygame".
>>
>> Draft at:
>> http://socghop.appspot.com/student_proposal/show/google/gsoc2009/erisvaldojunior/t123873664199?subscription=on
>>
>> Also attached.
>>
>> Please provide me some tips because deadline is very close. I'll appreciate.
>>
>> Regards,
>>
>> Erisvaldo.
>>
>>
>

Re: [pygame] GSoC Proposal Feedback

[René Dudfield]

Hi,

there are already layer sprite classes:
  eg. http://pygame.org/docs/ref/sprite.html#pygame.sprite.LayeredUpdates

Apart from that your application looks pretty good.  I like pretty
much all of your proposed enhancements (tiles, animated sprites, and
scenes).  I think they'd all be useful for many different games.

I'm going to work on giving as much feedback to all proposals as I can
over the weekend ( as will Marcus and Nirav in their time ).

The only other main point(which I've been giving to everyone applying)
I can give you is to consider submitting an application for one of the
core python ideas, or an application to another project (SDL for
example).  You are allowed to make multiple proposals - and are
allowed to modify your applications after the deadline.  We've had
lots of applications this year, and we will definitely not be able to
mentor them all, or even get allocated slots for all the projects.


cheers,




On Sat, Apr 4, 2009 at 1:56 AM, Erisvaldo Junior  wrote:
> Hi guys,
>
> I would like to receive some feedback about my proposal "Improved Sprite and
> Scene System for Pygame".
>
> Draft at:
> http://socghop.appspot.com/student_proposal/show/google/gsoc2009/erisvaldojunior/t123873664199?subscription=on
>
> Also attached.
>
> Please provide me some tips because deadline is very close. I'll appreciate.
>
> Regards,
>
> Erisvaldo.
>
>

Re: [pygame] GSoC Application

[Marcus von Appen]

On, Thu Apr 02, 2009, d...@amberfisharts.com wrote:

> 
> Hello,
> 
> I did as you recommended my application with some changes (mainly changeing 
> the focus from pygame to general use with pygame as a usecase).
> 
> It seems though that I can't publicly link to my proposal. 
> Can the Mentors review the submitted student applications?

Yes, and we will do so :-).

Regards
Marcus


pgpBpNW84W2Vo.pgp
Description: PGP signature

Re: [pygame] GSoC Application

[don]

Hello,

I did as you recommended my application with some changes (mainly changeing 
the focus from pygame to general use with pygame as a usecase).

It seems though that I can't publicly link to my proposal. 
Can the Mentors review the submitted student applications?

If I get accepted it's going to be an very exciting summer...

regards
Lorenz



On Thu, 2 Apr 2009 12:31:22 +1100, René Dudfield  wrote:
> Hi,
> 
> yes, submit it to:
> http://socghop.appspot.com/
> 
> under "Python Software Foundation" now.
> 
> You are allowed to make changes after you have submitted it.  So just
> submit now, and we can give feedback later.
> 
> Your proposal looks pretty good(I only gave it a quick read so far).
> The main feedback I can give now is that perhaps try and make your
> proposal for types available to be included in python as well -- not
> just pygame.  Also perhaps mention what underlying types they will be
> for (python float,   c float, c double, 32bit fixed etc).
> 
> 
> 
> cheers,
> 
> 
> 
> 
> On Thu, Apr 2, 2009 at 12:23 PM, Lorenz Quack 
> wrote:
>> Hello pygamers,
>>
>> as I wrote a few weeks ago I'm also interested in the math project for
> this
>> years GSoC. I know I'm a bit late for feedback but if you have some it
>> definitely is still welcome!
>>
>> Am I correctly assuming that I should submit this via the GSoC homepage
> to
>> the "Python Software Foundation" by Friday April 3rd 19:00 UTC?
>>
>>
>> sincerely yours
>> Lorenz
>>
>>
>>
>> So here is my application:
>>
>> Student Application to Google Summer of Code 2009
>>
>> Name: Lorenz Quack
>>
>> Contact Information:
>>email: d...@amberfisharts.com
>>ICQ  : 149873705
>>
>> Time Zone: UTC+1
>>
>> Preferred Language: English, German
>>
>> Time Commitment:
>>I roughly estimate that I could spend about 20-30 hours a week on
>>this project with development mainly happening on weekends.
>>This summer I have to work on my thesis (German: Diplomarbeit).
>>Furthermore I'm teaching C++ at university which will take some
>>time to prepare for.
>>Nevertheless I am confident that I can complete this project this
>>summer while maintaining high quality.
>>
>> Programming Experience:
>>I took some programming classes at school and really got into C++
>>in 2003 when I joined the amberfisharts [1] team. There I first
>>worked on the engine especially the pathfinding algorithm.
>>I was also lead developer on the savage [2] engine which is a
>>flexible 2D game engine written in pure python with a pygame
> backend.
>>Furthermore I was involved in the development of pyphant [3] a
>>framework for visual data analysis.
>>Besides that I have committed some patches to various open source
>>projects including python and pygame.
>>My experience in numbers:
>>   C++ 5 years
>>   python 4 years
>>   pygame 3 years
>>
>> Other skills:
>>I'm studying theoretical physics so I guess you could count that as
>>having some math knowledge.
>>
>> About my project:
>>I want to implement some math functionality (especially linear
> algebra)
>>as a python C extension for inclusion into the pygame package.
>>It should provide vector and matrix types in two, three and four
>>dimensions. In addition quaternions should also be included for
> their
>>special usefulness for rotations.
>>To ensure a seamless integration into pygame I would pay special
>>attention to the new types interoperability with built-in types
>>e.g. vectors should smoothly interact with other sequence types.
>>Also the existing pygame modules should then be changed to take
> advantage
>>of these new types and accept them as arguments to function calls
> and
>>return them where appropriate.
>>A test suite is considered mandatory.
>>
>> The need for this project:
>>While I was working on savage [2] I often found myself in need of
>>some vector math. I believe that this need is virtually universal
> in
>>game development so having an standard implementation written as an
>>C extension for speed seems natural.
>>Using other existing packages like numpy often seems overkill and
> their
>>API is too complex since they are targeting a much broader audiance
>>with much richer functionality than what is usually needed for game
>>development.
>>
>> Rough time line:
>>20. April  -  8. May   : Assess the needed functionality in
> cooperation
>> with the community and the
> mentor.
>> 9. May- 22. May   : Develop the API.
>>23. May- 27. July  : Write a feature complete implementation
> with
>> test suite.
>>28. July   - 10. August: Optimize the implementation.
>>11. August - 17. August: Clean up code, test suite and
> documentation.
>>
>> Origin of this proposal:
>>I was actually working on this when I stumbled upon the pygame GSoC
>>website [4]. There they sugges

Re: [pygame] GSOC: pygame module for tinypy

[Denis Kasak]

On Thu, Apr 2, 2009 at 4:41 AM, René Dudfield  wrote:
> Hi,
>
> I spoke to Phil, and I don't think he's interested in mentoring it.
> Maybe ask on the tinypy list or psf list*[0] to see if anyone else is
> interested in mentoring.  Or instead think of a separate project
> proposal(maybe python or SDL related).

Hey,

Thanks for the effort. I'll try both of those lists.

-- 
Denis Kasak

Re: [pygame] GSOC: pygame module for tinypy

[René Dudfield]

Hi,

I spoke to Phil, and I don't think he's interested in mentoring it.
Maybe ask on the tinypy list or psf list*[0] to see if anyone else is
interested in mentoring.  Or instead think of a separate project
proposal(maybe python or SDL related).


cheers,

*[0] http://mail.python.org/mailman/listinfo/soc2009-general





On Thu, Apr 2, 2009 at 1:26 PM, Denis Kasak  wrote:
> Hi René,
>
> Here's my proposal. Looking forward to your feedback.
>
> --
> Denis Kasak
>

Re: [pygame] GSOC: pygame module for tinypy

[Denis Kasak]

Hi René,

Here's my proposal. Looking forward to your feedback.

-- 
Denis Kasak
About You
=

1) Your Name: 
Denis Kasak

2) Contact Information:
denis.ka...@gmail.com
IRC nick: dkasak
ICQ: 46413957
XMPP: denis.ka...@gmail.com/Laptop
Mobile: (+385) 99 / 595 - 2655

3) Time Zone and Preferred Language: 
UTC+1 (CEST), English

4) Time Commitment:
During the three months of GSOC, I would be available full-time, more 
or less. I've taken care of major commitments (like exams) so they should not 
be disruptive over the summer. I'm confident I could port the major part (if 
not everything) of pygame to tinypy.

5) Programming Experience:
10 years experience in C
6 years experience in C++
6 years experience in Python
A few years experience in LISP, Prolog, Pascal (not an expert, but I 
have a good working knowledge with all)
I was GSOC participant last year under tinypy and I've implemented a 
sandbox feature (memory and time limit) for it. As a result I'm very familiar 
with tinypy's internals.
I'm a teaching assistant for Programming classes in my university
I've written a small plotting/linear regression/statistical analysis 
library for personal use (for laboratory work in Physics classes)
A few small personal games like a text adventure and a curses Snake game
I've submitted small patches/bugfixes to FOSS projects (like Miranda IM)

6) Pygame Experience:
Not much, but I've often played with it and I use it often to 
demonstrate Python programming in Programming classes mentioned above. I've 
also ported the aforementioned Snake to Pygame sometime in the past (and 
subsequently lost the code in a hard disk failure :-( )
 
7) Other skills and experience that are of interest for your aplication:
A good knowledge of Mathematics, Physics, Electronics, Signal Theory, 
Game Theory, etc. (my university is a sadistic place :-) )
I believe I can write pretty good documentation and I enjoy doing it
Experienced with SVN and some other VCSs (I've particularly been 
interested in DVCS lately, e.g. Mercurial)
A good knowledge of Linux, POSIX, etc. (I'm a 6+ years user)

About Your Project
==

1) Please explain in 2 to 3 paragraphs the project you intend to complete. 
My intention is to port pygame to tinypy by using tinypy's C API. This 
would mean implementing most (possibly all, if the schedule allows it) 
submodules of pygame. It would also include implementing unit tests to test the 
new pygame port, either by reimplementing the tests or reimplementing the 
Python unittest module (more likely).

The benefits of such a project are rather obvious; pygame would support 
another cool platform and expand its userbase/usefulness, tinypy would become a 
much more interesting game development platform and it would be of interest to 
the entire game development community.

2) What existing or future need does your proposed project fulfill? 
My project would help pygame by providing a very small and tightly 
integrated Python implementation which could potentially be very attractive for 
game developers (particulary for embedded platforms). tinypy still has a lot of 
room left for optimization and it could provide pygame a very small, fast and 
"no baggage" platform. It would also make tinypy more attractive to game 
developers. Overall, it would be beneficiary to the whole game development 
community.

3) Provide a rough timeline for how you intend to complete your project, test 
it, and document it within the allotted time period. 
week 1: Reimplement the unittest module to tinypy so pygame's tests can 
be used directly. Study the code and documentation for pygame to familiarize 
with the codebase.
weeks 2-3: Implement the pygame module stub. Port the most important 
submodules to support basic drawing, along with relevant helper modules (the 
surface, display, draw, color, locals etc. submodules)
weeks 4-5: Port some of the more advanced graphical features, like the 
ability to render fonts and images (obviously, the font and image submodules 
along with transform and rect)
weeks 6-7: Port interactive features to start being really useful (key, 
time, event and mouse modules)
weeks 8-9: Port other "usability" modules (like pixelarray, overlay and 
mask (for collisions))
weeks 10-11: Port high-level features (mixer, music, movie, cdrom 
modules) - this chunk of work could also be resized (by omitting some of the 
modules) to be a safety net in case something goes awry and we need to 
reschedule.
week 12: Fix bugs, write documentation, packaging.

In the case that some additional unit tests are needed or some need to 
be reimplemented, this would be implemented incrementally after porting each 
module.
   

Re: [pygame] GSoC Application

[René Dudfield]

Hi,

yes, submit it to:
http://socghop.appspot.com/

under "Python Software Foundation" now.

You are allowed to make changes after you have submitted it.  So just
submit now, and we can give feedback later.

Your proposal looks pretty good(I only gave it a quick read so far).
The main feedback I can give now is that perhaps try and make your
proposal for types available to be included in python as well -- not
just pygame.  Also perhaps mention what underlying types they will be
for (python float,   c float, c double, 32bit fixed etc).



cheers,




On Thu, Apr 2, 2009 at 12:23 PM, Lorenz Quack  wrote:
> Hello pygamers,
>
> as I wrote a few weeks ago I'm also interested in the math project for this
> years GSoC. I know I'm a bit late for feedback but if you have some it
> definitely is still welcome!
>
> Am I correctly assuming that I should submit this via the GSoC homepage to
> the "Python Software Foundation" by Friday April 3rd 19:00 UTC?
>
>
> sincerely yours
> Lorenz
>
>
>
> So here is my application:
>
> Student Application to Google Summer of Code 2009
>
> Name: Lorenz Quack
>
> Contact Information:
>    email: d...@amberfisharts.com
>    ICQ  : 149873705
>
> Time Zone: UTC+1
>
> Preferred Language: English, German
>
> Time Commitment:
>    I roughly estimate that I could spend about 20-30 hours a week on
>    this project with development mainly happening on weekends.
>    This summer I have to work on my thesis (German: Diplomarbeit).
>    Furthermore I'm teaching C++ at university which will take some
>    time to prepare for.
>    Nevertheless I am confident that I can complete this project this
>    summer while maintaining high quality.
>
> Programming Experience:
>    I took some programming classes at school and really got into C++
>    in 2003 when I joined the amberfisharts [1] team. There I first
>    worked on the engine especially the pathfinding algorithm.
>    I was also lead developer on the savage [2] engine which is a
>    flexible 2D game engine written in pure python with a pygame backend.
>    Furthermore I was involved in the development of pyphant [3] a
>    framework for visual data analysis.
>    Besides that I have committed some patches to various open source
>    projects including python and pygame.
>    My experience in numbers:
>       C++ 5 years
>       python 4 years
>       pygame 3 years
>
> Other skills:
>    I'm studying theoretical physics so I guess you could count that as
>    having some math knowledge.
>
> About my project:
>    I want to implement some math functionality (especially linear algebra)
>    as a python C extension for inclusion into the pygame package.
>    It should provide vector and matrix types in two, three and four
>    dimensions. In addition quaternions should also be included for their
>    special usefulness for rotations.
>    To ensure a seamless integration into pygame I would pay special
>    attention to the new types interoperability with built-in types
>    e.g. vectors should smoothly interact with other sequence types.
>    Also the existing pygame modules should then be changed to take advantage
>    of these new types and accept them as arguments to function calls and
>    return them where appropriate.
>    A test suite is considered mandatory.
>
> The need for this project:
>    While I was working on savage [2] I often found myself in need of
>    some vector math. I believe that this need is virtually universal in
>    game development so having an standard implementation written as an
>    C extension for speed seems natural.
>    Using other existing packages like numpy often seems overkill and their
>    API is too complex since they are targeting a much broader audiance
>    with much richer functionality than what is usually needed for game
>    development.
>
> Rough time line:
>    20. April  -  8. May   : Assess the needed functionality in cooperation
>                             with the community and the mentor.
>     9. May    - 22. May   : Develop the API.
>    23. May    - 27. July  : Write a feature complete implementation with
>                             test suite.
>    28. July   - 10. August: Optimize the implementation.
>    11. August - 17. August: Clean up code, test suite and documentation.
>
> Origin of this proposal:
>    I was actually working on this when I stumbled upon the pygame GSoC
>    website [4]. There they suggested exactly this project as an GSoC entry.
>
> Further notes:
>    I already started work on this project which might compensate for
>    my estimated workload falling a bit short of the expected 40 hours
>    pensum.
>
>
> [1] http://www.amberfisharts.com
> [2] http://sourceforge.net/projects/savage
> [3] http://sourceforge.net/projects/pyphant/
> [4] http://pygame.org/wiki/gsoc2009ideas
>

Re: [pygame] GSoC A* for AI

[René Dudfield]

hi,

I don't know if that is enough for a 3 month project.  Perhaps a few
more things could be added.

cheers,

On Thu, Apr 2, 2009 at 12:02 PM, Orcun Avsar  wrote:
> its only little time left for submiting deadline but i want to share
> quickly my ideas with you about AI module and i can work for a
> proposal. I red some discussions about this on the mailing list. Here
> is my opinion. A* algorithm is not a very hard thing to write. Porting
> it from C may make it faster but i think main question here how to
> make it more usable. It should be used with minimal effort. Finding
> shortest way is not as good as finding shortest way in shortest time
> but algorithm or code can be healed, changed in future but usage must
> be same and good. I plan to write a astar pathfinding module that is
> practical to use.
> something like first registering sprites or rects to module(rect
> objects have coordinates and size ). Rect objects are general with all
> games and this is better than creating a matrix or scanning a surface
> for colorkeys.
> pathfinder.register( user.rect )
> pathfinder.register( enemy.rect )
> pathfinder.register( house.rect )
>
> and any time using some function like this  pathfinder.findway
> (start=user.rect,dest=house.rect)
> and it can return a result like node points of shortest path like
> (  (12,32), (12,300), (400,300)  ) that each node consist of x and y
>

Re: [pygame] GSoC Easy simple software 3d

[René Dudfield]

hi,

@Mike:  would you like to be put down as a backup part time mentor?  I
could probably go as the full time/other mentor in that case.

It would be a very useful project for people making opengl
games/programs who want backup software rendering, as well as being
useful in its own right.


cheers,




On Wed, Apr 1, 2009 at 9:35 AM, Mike C. Fletcher  wrote:
> Ian Mallett wrote:
>>
>> There is an .obj loader on pygame.org already in the cookbook...
>>
>
> There's also one in Pyglet with a modified version in OpenGLContext:
>
>
> http://bazaar.launchpad.net/~mcfletch/openglcontext/trunk/annotate/head%3A/OpenGLContext/loaders//obj.py
>
> Regarding the proposal in general, it sounds fine.  BTW, I can't
> realistically commit to being a full-time mentor this summer, but I'd be
> willing to help out with mentoring and/or answering questions.
>
> HTH,
> Mike
>
> --
> 
>  Mike C. Fletcher
>  Designer, VR Plumber, Coder
>  http://www.vrplumber.com
>  http://blog.vrplumber.com
>
>

Re: [pygame] GSOC: pygame module for tinypy

[René Dudfield]

Hi Denis,

looks like a good project...

I've forwarded your email onto Phil, so hopefully if he has time he
will consider being your mentor for this.

Definitely submit your application.



- to reuse existing pygame tests, a simple port of the module unittest
would save your time.  It's not such a big module.
- Marcus has separated out pygame specific code... so you could use that.
- will send you more feedback when you send your proposal.




cheers,



On Thu, Apr 2, 2009 at 1:55 AM, Denis Kasak  wrote:
> Greetings pygame-users,
>
> I'm a second year undergraduate student at the Faculty of
> Electrotechnical Engineering in Croatia, Osijek. I was a participant
> in the last year's GSOC under the PSF (working on the tinypy project,
> more specifically) and would like to reapply again this year. My
> project last year was sandboxing the tinypy interpreter (I suspect
> there are some tinypy mailing list users here that may know me).
>
> I've looked through the ideas page for pygame and found the one about
> porting pygame to tinypy very interesting. As it is, tinypy is already
> an interesting platform with much potential and a great deal of it is
> still to be unlocked. Porting pygame would be one major step in that
> direction. Combining such a great game library with such a neatly
> packed interpreter is definitely a winning combination, particularly
> when you think of all the CPython's baggage you needn't carry anymore
> :-)
>
> The benefits of such a project are rather obvious; pygame would
> support another cool platform and expand its userbase/usefulness,
> tinypy would become a much more interesting game development platform
> and it would be of interest to the entire game development community.
>
> The "how" part of the project is pretty straightforward. Most of the
> CPython's API functions pygame uses has a direct (or nearly direct)
> counterpart in tinypy so porting would be a pretty smooth process. As
> to the order of submodules to be ported, I already have a general idea
> of how it should be done, i.e.
>
> 1. first the stub for the pygame "metamodule" would be implemented
> 2. then the most important submodules to support basic drawing, along
> with relevant helper modules (the surface, display, draw, color,
> locals etc. submodules)
> 3. then some of the more advanced graphical features, like the ability
> to render fonts and images (obviously, the font and image submodules
> along with transform and rect)
> 4. the next goal would be to make pygame really useful by adding
> interactive features (key, time, event, mouse; probably mask too, to
> support collisions)
> 5. some more "usability" modules (like pixelarray and overlay)
> 6. and finally, the more "high-level" features (like mixer, music,
> movie, cdrom, etc)
>
> The order of the last two items should possibly be inverted.
>
> Concerning documentation, most of the original pygame docs should
> apply but all things that differ would, of course, be documented.
> Tests would also be added along the way as tinypy already has a
> testing framework implemented; this will probably save a lot of
> bug-induced pain in the long run. :-)
>
> As for my schedule, last year was a bit of a turmoil for me (because
> of an incompatible university schedule and some personal problems) but
> this year I'm taking (and mostly have already) care of exams earlier
> so I don't get caught up with them in the summer, meaning I'll be
> available full time, more or less.
>
> I'll be writing the proposal today; I just wanted to share this with
> the list beforehand in case anyone has any suggestions, corrections or
> anything that could help me write a better proposal.
>
> Thanks in advance,
>
> --
> Denis Kasak
>

Re: [pygame] GSoC Easy simple software 3d

[René Dudfield]

Also, there's one in cgkit.  I think the cgkit one worked the best for
complex maya obj files last I tried.  However I haven't tried the
blender one recently.

cu,


On Wed, Apr 1, 2009 at 9:35 AM, Mike C. Fletcher  wrote:
> Ian Mallett wrote:
>>
>> There is an .obj loader on pygame.org already in the cookbook...
>>
>
> There's also one in Pyglet with a modified version in OpenGLContext:
>
>
> http://bazaar.launchpad.net/~mcfletch/openglcontext/trunk/annotate/head%3A/OpenGLContext/loaders//obj.py
>
> Regarding the proposal in general, it sounds fine.  BTW, I can't
> realistically commit to being a full-time mentor this summer, but I'd be
> willing to help out with mentoring and/or answering questions.
>
> HTH,
> Mike
>
> --
> 
>  Mike C. Fletcher
>  Designer, VR Plumber, Coder
>  http://www.vrplumber.com
>  http://blog.vrplumber.com
>
>

Re: [pygame] GSoC Easy simple software 3d

[Mike C. Fletcher]

Ian Mallett wrote:

There is an .obj loader on pygame.org already in the cookbook...
  

There's also one in Pyglet with a modified version in OpenGLContext:

   
http://bazaar.launchpad.net/~mcfletch/openglcontext/trunk/annotate/head%3A/OpenGLContext/loaders//obj.py


Regarding the proposal in general, it sounds fine.  BTW, I can't 
realistically commit to being a full-time mentor this summer, but I'd be 
willing to help out with mentoring and/or answering questions.


HTH,
Mike

--

 Mike C. Fletcher
 Designer, VR Plumber, Coder
 http://www.vrplumber.com
 http://blog.vrplumber.com

Re: [pygame] GSoC Easy simple software 3d

[Ian Mallett]

Yes.  It's fairly robust.  I use a modified version which puts everything
into NumPy/Numeric arrays for easy integration into vertex arrays/VBOs.

Re: [pygame] GSoC Easy simple software 3d

[pymike]

http://www.pygame.org/wiki/OBJFileLoader?parent=CookBook
-- 
- pymike

Re: [pygame] GSoC Easy simple software 3d

[Ian Mallett]

There is an .obj loader on pygame.org already in the cookbook...

Re: [pygame] GSoC Easy simple software 3d

[Marcus von Appen]

On, Tue Mar 31, 2009, Campbell Barton wrote:

> The OBJ loader for blender3d could quite easily be modified to have
> the blender parts removed,
> OBJ looks like a simple format but there are quite a few corner cases
> that we had to account for in blender to support OBJs for lots of
> different programs.
> 
> Main drawback with OBJ is no lights or vertex colors.

Does the license of the code portion match our needs (LGPL or more
free)?

Regards
Marcus


pgpxELBsl65IR.pgp
Description: PGP signature

Re: [pygame] GSoC Easy simple software 3d

[Campbell Barton]

The OBJ loader for blender3d could quite easily be modified to have
the blender parts removed,
OBJ looks like a simple format but there are quite a few corner cases
that we had to account for in blender to support OBJs for lots of
different programs.

Main drawback with OBJ is no lights or vertex colors.

On Mon, Mar 30, 2009 at 1:08 PM, René Dudfield  wrote:
> Hi,
>
> your application looks pretty good.
>
> +1 for obj rather than 3ds.  Obj has more wide spread editor support.
> However, it sounds like you have written a 3ds loader/renderer already
> - so that knowledge will be useful.
>
> I'd note in the title it will be opengl based, since then you will
> likely get more support from the non-pygame people too.
>
> Also, unittests will be required, so please mention them in your
> outline.  It's good for the tests to be written as you go, rather than
> at the end.
>
>
> cheers,
>
>
>
> On Tue, Mar 31, 2009 at 6:25 AM, Marcus von Appen  wrote:
>> On, Mon Mar 30, 2009, Kurucsai Istvan wrote:
>>
>> [...]
>>
>>> About My Project
>>>
>>>     1. My project is about implementing "Easy Simple Software 3D" support 
>>> for
>>>     pygame. It would be capable of loading and rendering 3D models and 
>>> handling
>>>     basic OpenGL functionality like lighting. I divided the task into 3
>>>     subprojects:
>>>
>>>         I. Choosing/wrapping an appropriate software OpenGL implementation.
>>>             There are several candidates for this (tinygl, sdl-tinygl, 
>>> vincent).
>>>             The chosen implementation has to be fast, reasonably bug-free 
>>> and
>>>             appropriately licensed.
>>>
>>>         II. Choosing a model format and developing a loader for it.
>>>             3ds and obj are the most likely to be used. Both of them has 
>>> plenty
>>>             of documentation/example code, obj is simpler but I already have
>>>             some experience with 3ds.
>>
>> I'd recommend to focus on the obj format here. It's even more common
>> than 3ds and most modelers support export/import facilities for it. If
>> you have enough time at your hands later on, you can go ahead and add
>> 3ds support or whatever else, so you should add an optional task about
>> adding more loaders.
>>
>>>         III. Writing the engine.
>>>             The main goal is to make the interface of the engine as simple 
>>> as
>>>             possible while retaining functionality. Loading and displaying a
>>>             model should be as simple as 2 function calls.
>>
>> The internals of the engine should be nicely layered (using as less
>> complexity as possible to keep it fast), so it can be exchanged easily
>> with another software engine or even hardware bindings.
>>
>> Besides that, your proposal looks all good to me.
>>
>> Regards
>> Marcus
>>
>



-- 
- Campbell

Re: [pygame] GSoC application reminder

[René Dudfield]

Also note, that you can revise your application after you submit it.

cheers,



On Tue, Mar 31, 2009 at 6:34 AM, Marcus von Appen  wrote:
> Hi,
>
> this just a quick reminder for all, who want to participate in the
> Google Summer of Code.
>
> The submission deadline for student applications is April, the 3rd, 19pm
> UTC. Those of you who already sent us their applications, received
> feedback and have their final application ready, are advised to submit it
> to the PSF organisation soon.
>
> Those of you, who are still writing their application are recommended to
> send it to us as soon as possible to get some feedback before finally
> submitting it. This eases the process of revising the the final
> submission :-).
>
> Regards
> Marcus
>

Re: [pygame] GSoC Easy simple software 3d

[René Dudfield]

Hi,

your application looks pretty good.

+1 for obj rather than 3ds.  Obj has more wide spread editor support.
However, it sounds like you have written a 3ds loader/renderer already
- so that knowledge will be useful.

I'd note in the title it will be opengl based, since then you will
likely get more support from the non-pygame people too.

Also, unittests will be required, so please mention them in your
outline.  It's good for the tests to be written as you go, rather than
at the end.


cheers,



On Tue, Mar 31, 2009 at 6:25 AM, Marcus von Appen  wrote:
> On, Mon Mar 30, 2009, Kurucsai Istvan wrote:
>
> [...]
>
>> About My Project
>>
>>     1. My project is about implementing "Easy Simple Software 3D" support for
>>     pygame. It would be capable of loading and rendering 3D models and 
>> handling
>>     basic OpenGL functionality like lighting. I divided the task into 3
>>     subprojects:
>>
>>         I. Choosing/wrapping an appropriate software OpenGL implementation.
>>             There are several candidates for this (tinygl, sdl-tinygl, 
>> vincent).
>>             The chosen implementation has to be fast, reasonably bug-free and
>>             appropriately licensed.
>>
>>         II. Choosing a model format and developing a loader for it.
>>             3ds and obj are the most likely to be used. Both of them has 
>> plenty
>>             of documentation/example code, obj is simpler but I already have
>>             some experience with 3ds.
>
> I'd recommend to focus on the obj format here. It's even more common
> than 3ds and most modelers support export/import facilities for it. If
> you have enough time at your hands later on, you can go ahead and add
> 3ds support or whatever else, so you should add an optional task about
> adding more loaders.
>
>>         III. Writing the engine.
>>             The main goal is to make the interface of the engine as simple as
>>             possible while retaining functionality. Loading and displaying a
>>             model should be as simple as 2 function calls.
>
> The internals of the engine should be nicely layered (using as less
> complexity as possible to keep it fast), so it can be exchanged easily
> with another software engine or even hardware bindings.
>
> Besides that, your proposal looks all good to me.
>
> Regards
> Marcus
>

Re: [pygame] GSoC Easy simple software 3d

[Marcus von Appen]

On, Mon Mar 30, 2009, Kurucsai Istvan wrote:

[...]

> About My Project
> 
> 1. My project is about implementing "Easy Simple Software 3D" support for
> pygame. It would be capable of loading and rendering 3D models and 
> handling
> basic OpenGL functionality like lighting. I divided the task into 3
> subprojects:
> 
> I. Choosing/wrapping an appropriate software OpenGL implementation.
> There are several candidates for this (tinygl, sdl-tinygl, 
> vincent).
> The chosen implementation has to be fast, reasonably bug-free and
> appropriately licensed.
> 
> II. Choosing a model format and developing a loader for it.
> 3ds and obj are the most likely to be used. Both of them has 
> plenty
> of documentation/example code, obj is simpler but I already have 
> some experience with 3ds.

I'd recommend to focus on the obj format here. It's even more common
than 3ds and most modelers support export/import facilities for it. If
you have enough time at your hands later on, you can go ahead and add
3ds support or whatever else, so you should add an optional task about
adding more loaders.

> III. Writing the engine.
> The main goal is to make the interface of the engine as simple as
> possible while retaining functionality. Loading and displaying a
> model should be as simple as 2 function calls.

The internals of the engine should be nicely layered (using as less
complexity as possible to keep it fast), so it can be exchanged easily
with another software engine or even hardware bindings.

Besides that, your proposal looks all good to me.

Regards
Marcus


pgpRc3yns5rv7.pgp
Description: PGP signature