[pygame] GSoC
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 signature.asc Description: This is a digitally signed message part
Re: [pygame] GSoC
GSOC=Google summer of code -Zack On Feb 21, 2012, at 4:36 PM, Sam Bull sam.hack...@sent.com 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
[pygame] GSoC
-- Nikhil Murthy
Re: [pygame] GSoC
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 pyshell#2, line 1, in module
dict(ev)
TypeError: 'Event' object is not iterable
ev.dict()
Traceback (most recent call last):
File pyshell#3, line 1, in module
ev.dict()
TypeError: 'dict' object is not callable
ev.__dict__
Traceback (most recent call last):
File pyshell#6, line 1, in module
ev.__dict__
AttributeError: event member not defined
ev.dict
{'internal': False, 'id': 'test'}
Re: [pygame] GSoC
On 07.02.2011 05:37, David Burton wrote: On Sun, Feb 6, 2011 at 4:42 PM, Greg Ewing greg.ew...@canterbury.ac.nz 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 http://www.flounder.com/mcgrews_view.htm!/ 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
On Mon, Feb 7, 2011 at 1:28 PM, DR0ID dr...@bluewin.ch 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
On Feb 6, 2011, at 9:37 PM, David Burton wrote: On Sun, Feb 6, 2011 at 4:42 PM, Greg Ewing 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! 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
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 ca...@pandora.com 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
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
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
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 ca...@pandora.com 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 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: [pygame] GSoC
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
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 pyshell#2, line 1, in module
dict(ev)
TypeError: 'Event' object is not iterable
ev.dict()
Traceback (most recent call last):
File pyshell#3, line 1, in module
ev.dict()
TypeError: 'dict' object is not callable
ev.__dict__
Traceback (most recent call last):
File pyshell#6, line 1, in module
ev.__dict__
AttributeError: event member not defined
ev.dict
{'internal': False, 'id': 'test'}
On Sun, Feb 6, 2011 at 2:19 PM, Lenard Lindstrom le...@telus.net 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 pyshell#6, line 1, in module
ev.__dict__
AttributeError: event member not defined
ev.type
24
ev.id http://ev.id
'test'
ev.internal
False
repr(ev)
Event(24-UserEvent {'internal': False, 'id': 'test'})
*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 greg.ew...@canterbury.ac.nz
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
On Sun, Feb 6, 2011 at 4:42 PM, Greg Ewing greg.ew...@canterbury.ac.nzwrote: 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 http://www.flounder.com/mcgrews_view.htm!* Dave
Re: [pygame] GSoC
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 sam.hack...@sent.com 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 part
Re: [pygame] GSoC
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 2011 ideas for pygame
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 kunal...@gmail.com wrote: From: kunal kunal...@gmail.com 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
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, kunalkunal...@gmail.com wrote: From: kunalkunal...@gmail.com 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
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, kunalkunal...@gmail.com wrote: From: kunalkunal...@gmail.com 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
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, kunalkunal...@gmail.com wrote: From: kunalkunal...@gmail.com 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
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 kunal...@gmail.com wrote: From: kunal kunal...@gmail.com 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, kunalkunal...@gmail.com wrote: From: kunalkunal...@gmail.com 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
[pygame] GSOC 2011 ideas for pygame
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
[pygame] GSoC
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 part
Re: [pygame] GSoC
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 sam.hack...@sent.com 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
Hi, On Thu, Sep 16, 2010 at 7: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. Uhm, yeah, not sure why I thought it was addressed to me personally... Sorry for the on-list brain-malfunction :) Best Regards Neilen
[pygame] GSoC Article for PSF and my blog
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 Anyway, since the PSF blog article will be brief, I thought I would also write up a longer article about your projects on my personal blog as well. The information I found on the Python wiki page was pretty brief, so I would appreciate it if you could tell me the following: 1) What was worked on during the GSoC project 2) How many students helped with a guess at how many hours were put in 3) Your experiences being a mentor If possible, I would like the student's perspective too. Feel free to forward my information to them. Also feel free to opt out and I won't write anything more than the already public info I can find. Thanks a lot for your help! -- - Mike Driscoll Blog: http://blog.pythonlibrary.org
Re: [pygame] GSoC Article for PSF and my blog
Hi Mike, On Thu, Sep 16, 2010 at 4:08 PM, Mike Driscoll 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
Re: [pygame] GSoC Article for PSF and my blog
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 nmar...@gmail.com wrote: Hi Mike, On Thu, Sep 16, 2010 at 4:08 PM, Mike Driscoll 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
Re: [pygame] GSoC Article for PSF and my blog
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 m...@pythonlibrary.orgwrote: 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 nmar...@gmail.com wrote: Hi Mike, On Thu, Sep 16, 2010 at 4:08 PM, Mike Driscoll 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
Re: [pygame] GSoC Article for PSF and my blog
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 m...@pythonlibrary.orgwrote: 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 nmar...@gmail.com wrote: Hi Mike, On Thu, Sep 16, 2010 at 4:08 PM, Mike Driscoll 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
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 mailto: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 m...@pythonlibrary.org 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 nmar...@gmail.com mailto:nmar...@gmail.com wrote: Hi Mike, On Thu, Sep 16, 2010 at 4:08 PM, Mike Driscoll m...@pythonlibrary.org 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
Hi Lenard, Thanks for the heads-up! - Mike On Thu, Sep 16, 2010 at 2:26 PM, Lenard Lindstrom le...@telus.net 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 mailto: 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 m...@pythonlibrary.org 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 nmar...@gmail.com mailto:nmar...@gmail.com wrote: Hi Mike, On Thu, Sep 16, 2010 at 4:08 PM, Mike Driscoll m...@pythonlibrary.org 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: pygamedraw - status update
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
[pygame] gsoc: pygamedraw - status update
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: # ... red = pygame2.Color(200, 0, 0) blue = pygame2.Color(0, 0, 200) my_pen = SolidPen(color=red) my_pen.width = 6 rect1 = pygame2.Rect(20, 60, 200, 150) my_pen.width = 1 my_pen.ellipse(screen, rect1) rect2 = pygame2.Rect(30, 20, 50, 80) my_pen.ellipse(screen, rect2, start=30, stop=250) my_pen.color = blue my_pen.fill = True my_pen.cirlce(screen, (150, 170), 60, stop=90) my_pen.fill = False points = [(20, 50), (60, 10), (70, 80)] my_pen.line(screen, points, closed=True) # ... This should be mostly self-explanatory. In comparison to the current draw module(s) you will notice that it is object oriented! Draw functions on module level are replaced by draw methods on class level. This is the main change that brings along some advantages and changes: 1.) possibility of inheritance This is a great new feature that allows it to manipulate the way of drawing without touching any shape algorithms. These are implemented in the Pen base class and work on a mask as intermediate. This mask is then passed to the Pen.render() method that does some preparation and then calls the Pen.draw() method that implements the actual drawing. So you just need to subclass Pen and overwrite one method (namely Pen.draw()) and have a completely new drawing behavior for all shapes. Of course there will be some default Pens that already implement the most common drawing methods. There are some screen shots of already implemented Pens at my blog: http://pygamedraw.wordpress.com/2010/06/02/from-mask-to-surface/ If you have any ideas for further Pen classes please tell me. 2.) shorter parameter lists Having a Pen object allows it to store general parameters as class attributes, so drawing methods take only a minimum of parameters. However, I plan to add a way to set these class attributes on method class, so if you don't like to write my_pen.width=1/2/... all the time, you could set it directly on method call (like with the current pygame.draw module): my_pen.rect(surf, rect, width=2). 3.) cleaner code I think this makes the code cleaner, more structured and more pythonic. A more complex example is included with the sourcecode: http://bitbucket.org/schlangen/pygamedraw/get/2c2c8b815137.zip or hg clone http://bitbucket.org/schlangen/pygamedraw Regards, Julian
Re: [pygame] gsoc: pygamedraw - status update
sweet as :)
Re: [pygame] gsoc: pygamedraw - status update
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 ren...@gmail.com wrote: sweet as :)
Re: [pygame] gsoc: pygamedraw - status update
Looking good. Lenard
Re: [pygame] gsoc: pygamedraw - status update
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
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 d...@amberfisharts.com 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 2010: A New Draw Module
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
[pygame] GSoC 2010: A New Draw Module
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
Yay. Pygame has needed this for a LONG time. Good luck! Keep us updated. On Sun, May 2, 2010 at 5:55 PM, jug j...@fantasymail.de 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
[pygame] GSoC - last time reminder and a quick application advice
Hi, those of you who want to participate at the GSoC this yesar, make sure you apply (if you did not already) until tomorrow, 7pm UTC. If you submitted a proposal already on this list, but did not get any fdeedback yet, do not hesitate to submit it to the google webapp anyways. We will read it and give you further advice, but did not have time for now to do so (bear with us, we're only humans). As you know, not anyone will be selected for for working on pygame (this year probably even less than the years before), so make sure, that you file a 'backup' application for another project (be it Python or something else) in case you are really eager to work on some GSoC task. If you filed or file a backup application, it would be nice to inform us for which project you did it, so we do not run into trouble and lengthy discussion, if both, us and the other project wants you to mentor. Note that a backup application will _not_ have an impact on your chance of being selected by us, but instead means a higher chance to get selected in general, so it is strongly recommended and definitely in your interest ;-). Regards Marcus pgpAfCZhX25Zc.pgp Description: PGP signature
[pygame] GSoC - two days left for application
Hi, all students who want to participate in the GSoC this year, are recommended and advised to sign up for the GSoC and submit their proposals under the PSF now. http://socghop.appspot.com/gsoc/org/home/google/gsoc2010/python There are only two days left for submitting the proposal (until Friday, 7pm UTC), so whether or not you are finished with it or (or not) received feedback for your proposal already - submit it. There is a twelve day interim period, where your proposals will be ranked, discussed and such a like, which will give you enough time to bring it into shape on further request. Regards Marcus pgpSBrt74grG0.pgp Description: PGP signature
Re: [pygame] GSoC project proposal: A new draw module
On Sat, Apr 3, 2010 at 4:25 PM, Kris Schnee ksch...@xepher.net 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 project proposal: A new draw module
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.
[pygame] GSoC: Sprite and scene system
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: Sprite and scene system
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 cloudneoz...@gmail.com 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
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: A new draw module
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?
[pygame] GSOC :: OSC Networking Project
Hello everyone, My name is Gabriel Silk, and I'm a fifth-year undergraduate computer science student at the University of British Columbia in Vancouver, B.C. I'm interested in networking, audio, game dev, and I'm a huge fan of open source software -- that's why Pygame's OSC project is a natural fit for me. I have experience with c (I've written a proxy server, an ftp client, and simple TCP-like protocol on top of UDP for coursework). Recently I wrote an on-line multiplayer game called Squabble as a personal side-project, with a server written in Java, and a client written in Flash/AS. Last term I wrote a world-modeller in c++ using Ogre. This term, I'm working on a multi-touch, collaborative, UML diagram creation tool for the SMART Table as a course project. I'm also working on a web-based CMS for the BC Cancer Agency. All of these projects will be finished by the end of April. I've also worked for Electronic Arts (primarily graphics-related with some toolset work), and Merck Frosst (writing tools for Confluence, their on-line wiki system). It's nice to meet you all, and I hope to have a concrete proposal ironed out in the next week. If there are any suggestions as to what I should research and/or include in my proposal, or just things I should be doing or thinking about w.r.t. the project, I'd like to hear about it. Thanks, Gabriel Silk http://gabrielsilk.wordpress.com
Re: [pygame] GSoC project proposal: A new draw module
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
On Sun, Mar 7, 2010 at 2:30 PM, Evan Kroske e.kro...@gmail.com 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: Pygame on rails
On Sat, Mar 20, 2010 at 6:16 PM, Luke Paireepinart
rabidpoob...@gmail.com wrote:
On Sun, Mar 7, 2010 at 2:30 PM, Evan Kroske e.kro...@gmail.com 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.
[pygame] GSoC project proposal: A new draw module
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. Regards, Julian [1] http://bitbucket.org/schlangen/pexdra/ [2] http://bitbucket.org/schlangen/pexdra/src/tip/doc/source/images/simple_example.png#
Re: [pygame] GSoC project proposal: Pygame on rails
On Sun, Mar 7, 2010 at 8:03 AM, Nikhil Murthy murthyn...@gmail.com 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
[pygame] GSOC project proposal: Finishing the movie module
Hello all! So I am applying again this year, to properly finish my project last year. The movie module was largely finished in last year's GSoC project, however, it wasn't quite ready for release, with a few bugs and not compiling on windows. My proposal is to fix up those bugs, get it compiled on windows and polish it up for general release. The bugs were if I recall correctly: -Sometimes desyncs -memory leaks -slow performance for SDL screens. ...various other as-yet undiscovered bugs In addition, I'd be able to fix and complete the alternative video players. Thank you in advance, -- Tyler Laing Science and Tech Editor The Phoenix Newspaper (1) 250 863-4869 University of British Columbia - Okanagan University Way Kelowna, BC UNC 109 Student Services Building
Re: [pygame] GSoC project proposal: Pygame on rails
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 http://welcome2obscurity.blogspot.com The personal blog of a novice software developer. |
[pygame] GSoC project proposal: Pygame on rails
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
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 e.kro...@gmail.com 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
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 thade...@thadeusb.comwrote: 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 e.kro...@gmail.com 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.
[pygame] GSOC: Improving the sprite and scene system
Hello again, I am still interested in working for pygame for GSOC 2010, and would like to work towards improving the sprite and scene system. If this is possible, than I will start gathering information as to what people would like to see in the sprites and scenes immediately. Also, would it be possible for me to work on integration with rabbyt for this? Thank You, Nikhil Murthy
Re: [pygame] GSOC commited camera module to svn
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
[pygame] GSOC commited camera module to svn
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
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 commited camera module to svn
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 lauwerel.lau...@gmail.com 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
[pygame] gsoc midterm report for the camera module
Midterm report
##
With the midterm evaluation behind us I thought it would be useful to
post a update
on the progress on the camera module for Mac OSX. The current version on
github.com/ab3/pygame-mirror/ can read a frame from the camera and
copy it to
the surface. There is still something wrong with the colors, this has
probably
something to do with the masks in surf-format. I have tried out some
combination
but non seem to work, so if you have suggestion on how to get the
colors write pleas
post them on the pygame mailinglist.
I have thoroughly cleaned up the camera_mac.m file and have removed
all Cocoa
code because it caused to many problems. Only the
mac_gworld_to_nsimage used
Cocoa so I didn't have to trow away too much code. The following
functions are now
available:
* mac_list_cameras()
* mac_open_device ()
* mac_init_device()
* mac_close_device()
* mac_start_capturing()
* mac_stop_capturing ()
* mac_read_raw()
note: When I try to print the string I get nothing, this is probably
because
of a \0 byte in the array.
* mac_read_frame()
* mac_camera_idle()
* mac_copy_gworld_to_surface()
note: There is something wrong with the colors.
The PyCameraObject strct has altered a bit because I don't use a
ImageSequence
anymore because it was easier to get the frame copy the frame directly
instead of
recording a frame into a sequence and then decompressing a frame out
of it. In
addition to removing the ImageSequence I make use of the buffer
struct. Here is the
current PyCameraObject struct:
typedef struct {
PyObject_HEAD
char* device_name; // unique name of the device
SeqGrabComponent component; // A type used by the
Sequence Grabber API
SGChannel channel; // Channel of the Sequence
Grabber
GWorldPtr gworld; // Pointer to the struct that
holds the
// data of the captured image
Rect boundsRect;// bounds of the image frame
long size; // size of the image in our
buffer to draw
short bytes;// number of bytes in gworld
struct buffer pixels; // pixels
} PyCameraObject;
A usual you can find the latest version on github.com/ab3 so if you
would like to test
the latest changes or would like to help with the color problem or the
read_raw function,
you are always welcome.
ToDo
Here is a list of thing I still have to finish I still have to do:
* fix the colors of read_frame()
* fix read_raw()
* implement set_controller() and get_controller()
* add simple computer vision stuff
* thresholding with hysteresis
*...
* optimization, sbggr8_to_rgb???
* implement proof of concept game...
Conclusion
==
So this concludes my midterm report, feel free to post any bugs,
comments and
suggestions
Slu
Re: [pygame] gsoc midterm report for the camera module
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 lauwerel.lau...@gmail.com wrote: * mac_copy_gworld_to_surface() note: There is something wrong with the colors.
[pygame] gsoc project blogs, coding has started, and week 1 has past!
hello, just in case anyone missed it, each of the GSOC participants have a blog up now: - Tyler Laing http://oddco.ca/zeroth/zblog will improve the movie support in pygame, by adding an ffmpeg-based module (bloghttp://oddco.ca/zeroth/zblog). http://www.oddco.ca/zeroth/zblog/ - Vicent Marti will improve font handling using the freetype library ( blog http://www.bellverde.org/gsoc). 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/). 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=PyGamesortby=date Vicent Marti: http://www.seul.org/viewcvs/viewcvs.cgi/branches/pgreloaded/?root=PyGamesortby=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 project blogs, coding has started, and week 1 has past!
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=PyGamesortby=date Vicent Marti: http://www.seul.org/viewcvs/viewcvs.cgi/branches/pgreloaded/?root=PyGamesortby=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
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 ren...@gmail.com mailto:ren...@gmail.com 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 br...@hamsterrepublic.com 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 el.lau...@gmail.com 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
On Mon, May 4, 2009 at 4:44 PM, Lenard Lindstrom le...@telus.net 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
René Dudfield wrote: On Mon, May 4, 2009 at 4:44 PM, Lenard Lindstrom le...@telus.net mailto:le...@telus.net 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
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 ren...@gmail.com wrote: Hi, more below... On Sun, May 3, 2009 at 2:50 PM, el lauwer el.lau...@gmail.com 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
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 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 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 ren...@gmail.com wrote: Hi, more below... On Sun, May 3, 2009 at 2:50 PM, el lauwer el.lau...@gmail.com 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
Re: [pygame] [GSOC] svn and compile problem with pygame-svn
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 br...@hamsterrepublic.comwrote: 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 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 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 ren...@gmail.com wrote: Hi, more below... On Sun, May 3, 2009 at 2:50 PM, el lauwer el.lau...@gmail.com 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
Re: [pygame] [GSOC] svn and compile problem with pygame-svn
... 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 ren...@gmail.com 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 br...@hamsterrepublic.comwrote: 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 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 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 ren...@gmail.com wrote: Hi, more below... On Sun, May 3, 2009 at 2:50 PM, el lauwer el.lau...@gmail.com 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
[pygame] [GSOC] svn and compile problem with pygame-svn
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. 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.
Re: [pygame] [GSOC] svn and compile problem with pygame-svn
Hi, more below... On Sun, May 3, 2009 at 2:50 PM, el lauwer el.lau...@gmail.com 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] svn and compile problem with pygame-svn
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 ren...@gmail.com wrote: Hi, more below... On Sun, May 3, 2009 at 2:50 PM, el lauwer el.lau...@gmail.com 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: Extending Camera support for PyGame to Mac OSX Updates!
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 el.lau...@gmail.com 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
Re: [pygame] GSOC: Extending Camera support for PyGame to Mac OSX Updates!
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 el.lau...@gmail.com 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 el.lau...@gmail.com 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
[pygame] GSOC: Extending Camera support for PyGame to Mac OSX Updates!
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-implemented for OSX. Fourth week: Read about things like the SequenceGrabber from the QT api. May First week: make simple python extension in C to get familiar with the concept. Read more doc about python extensions. Second week: Implement simple app that grabs images from the camera with the QT SequenceGrabber API in C (obj-C). this is to get a good feeling with the QT api. Third week: start coding on the project, implement the ‘list_cameral’ function and open_device, … Fourth week: write functions that deal with the controllers… June First-third week: implement rest of the functions Fourth week: write wrapper around some additional functionality that the QT framework provides that isn’t in the existing module. I will
Re: [pygame] GSOC: Extending Camera support for PyGame to Mac OSX Updates!
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 el.lau...@gmail.com 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-implemented for OSX. Fourth week: Read about things like the SequenceGrabber from
[pygame] GSoC Proposal Feedback
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. Improved Sprite and Scene System for Pygame Pygame's Sprite system does not fit the requirements for many games. This proposal focus on writing a new Sprite engine that would support layers, easy animation, moving and transforming functions. 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. Also, a basic scene system will be developed, supporting screen flow, event triggers and scene elements. About Me 1a) Erisvaldo Gadelha Saraiva Júnior 1b) Contact information: E-mail: erisvaldojun...@gmail.com / cont...@erisvaldojunior.com Gtalk: erisvaldojun...@gmail.com MSN and Hotmail: jun1nho...@hotmail.com Skype: erisvaldojunior Website: http://www.erisvaldojunior.com 1c) Time zone: GMT -3:00 (Brazil). Languages: English / Portuguese 1d) Time commitment: I would devote 40h / week for GSoC project. It will be my only job over the three month period. Full-time is necessary because the project is really big. 1e) Programming experience: ~ 2 years Python programming (Panda Engine / Pygame / AI scripts); ~ 4 years Java programming (focused on JavaME. Developed some mobile games); ~ 6 years C/C++ programming (good OpenGL/SDL experience and also used game engines like HGE (2D) and 3D ones like Ogre, Irrlicht and Crystal Space). 1f) Pygame experience: Some small games like Pong and Sokoban clones. Studied the engine structure and thought about improvements that could be made. 1g) Other skills and experience: Good analysis and project skills; Use of Design patterns; Commented and Indented code; Nice communication through forums, messengers, mailing lists and irc; Knowledge of both Linux and Windows operating systems; Experience with project management, version control, home development; Overwork to achieve the desired result, if necessary. Some of my projects, including two mobile educational games and two C/C++ games (Allegro/OpenGL/SDL) are available at http://erisvaldojunior.com/projetos (Portuguese language). About My Project 2a) Please explain in 2 to 3 paragraphs the project you intend to complete. My proposed project is to write a new Sprite engine and a Scene system. The first one intends to give a more powerful Sprite engine to the developer so he doesn't have to write his own one. The new Sprite class will extend an abstract one called Layer and as every Layer, Sprite's location can be changed and and it can also be made visible or invisible. When you instantiate a new Sprite, you can specify a image, a frame width and a frame height to provide animation. You can get the next Sprite frame only using the method nextFrame of Sprite class. The frame sequence can be changed by the developer. The new Sprite also has methods for getting some transformations like rotation and mirroring and also has a powerful collision method for checking collision with any kind of Layer (remembering that Sprite is a kind of Layer in this new engine). As a bonus, Sprites could have state flags for effects like lighting and bumpmapping. To maintain backwards compability, Sprite would become a more abstract type that supports either the current Sprite system (Sprite and Group classes with some improvements) and the new Sprite engine. About the current one, improvements would be made to collision system. Rects would support both int and float types, work with vectors and support other shapes (including a polygonal generic shape). The Scene System would be composed by some classes like Scene, Layer and SceneManager. A Scene, on the other hand, would be composed by a set of Layers. Sprite and TiledLayer are examples of Layers. A TiledLayer could be used to make a tile-based level and would be able to load a image, separate the tiles and prepare the matrix for that level. A Scene, for example, could have a background layer, a opaque layer (which collides with Sprites) and a couple of Sprites. The SceneManager would be responsible for setting the Scene flow (scene 1 - scene 3 - ...) and also manage the event triggers for the scenes. 2b) What existing or future need does your proposed project fulfill? Many developers claim that current Sprite stuff in Pygame is not enough to produce more complex games, so they have to write their own Sprite engine. Also, the lack of a scene system is very frustrating for developers who want to make great games but don't have enough experience (or time) to make their own scene system. Improving Sprite stuff and adding a basic scene system would definetely attract more young programmers to the community, and also
Re: [pygame] GSoC Proposal Feedback
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 jun1nho...@hotmail.com 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
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 ren...@gmail.com 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 jun1nho...@hotmail.com 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
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 ren...@gmail.com 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 d...@amberfisharts.com 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
[pygame] GSoC Proposal Review
Hi, my name is Evan Kroske, and I would like some input on my GSoC proposal: http://socghop.appspot.com/student_proposal/show/google/gsoc2009/evankroske/t123863226991 I am applying for the pgreloaded example suite project, but I use tutorial to mean example. As the project mentions, I'm a complete PyGame beginner, but I have plenty programming experience. @Marcus the Mentor Do I need to post a couple examples of my writing to be eligible for the project? Regards, Evan Kroske Future GSoCer
Re: [pygame] GSoC Application
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
[pygame] GSOC: pygame module for tinypy
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: pygame module for tinypy
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 denis.ka...@gmail.com 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
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 mcfle...@vrplumber.com 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
[pygame] GSoC A* for AI
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 A* for AI
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 orc@gmail.com 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
[pygame] GSoC Application
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 Application
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 d...@amberfisharts.com 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: pygame module for tinypy
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: pygame module for tinypy
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 denis.ka...@gmail.com wrote: Hi René, Here's my proposal. Looking forward to your feedback. -- Denis Kasak
