Last night our humble 3D game engine reached 1000 commits to it's Subversion repository.
PySoy has been contributed to by 20 developers, 7 of which are currently active. The project's IRC channel is in nearly constant use by developers working on different tasks.
The external API has drawn considerable praise by users, despite it's state as beta, and the constructive feedback we've received has led many of the post-Beta2 API changes.
The internal API, while having some rough edges, has been commented on by several new developers as remarkably clean. We've passed the point which the COMPLETED list exceeds the TODO list, despite the latter constantly growing, and focus has largely shifted toward debugging, documentation, and polish.
Most notably, we've reached the point of needing a legal entity for the project. Using the Software Freedom Conservancy as a rough template, we've started the process to form a non-profit corporation with a focus on copyleft game projects. An announcement about this will be posted as more details are firmed up.
Wednesday, February 27, 2008
Tuesday, February 26, 2008
PySoy goes from 3 threads to 5
We're doing the final work now to replace CoreLoop with TransportLoop, WindowLoop, and SceneLoop. All three are instances of soy._internals.LoopThread which (should) play well with Python's threading system and should never hold the GIL.
The increased performance this has brought for multi-core users is amazing, some have reported more than twice the framerate!
To be fair, an equal number of subversion Trunk users are experiencing frequent segfaults since we've not finished adding mutexes and rearranging the internal API post-move. Obviously these issues are being resolved prior to the Beta-3 release next month.
The increased performance this has brought for multi-core users is amazing, some have reported more than twice the framerate!
To be fair, an equal number of subversion Trunk users are experiencing frequent segfaults since we've not finished adding mutexes and rearranging the internal API post-move. Obviously these issues are being resolved prior to the Beta-3 release next month.
Wednesday, February 20, 2008
why we're blocking Microsoft Live
While going through server logs I noticed something funny, Microsoft Live has surpassed Google in the number of hits we've received. Weird, eh? I didn't think anyone actually used it.
The terms people arriving at our site through search.live.com are just... weird, though. Most are outright vulgar, searching for obscure pornography or celebrity names, drugs, sex aids... Here's an few examples:
These hits were to small obscure pages on our site, such as svn changelogs, and then I noticed the source IP addresses were in just a few IP ranges, so I ran a whois to see if one ISP tied connected them all;
You read that correctly. Microsoft, in a desperate attempt to make themselves seem more important, or perhaps just to flood free software project's websites with unwanted traffic, is running bots which act like normal web crawlers. Indeed, over 97% of the hits we got from search.live.com were from Microsoft's own IP subnets. Searching Google, I found this story was previously covered by others more observant of their logs.
In response, I'm adding a special rule to block all future traffic from the offending netblocks, including MICROSOFT 131.107.0.0 - 131.107.255.255 and MICROSOFT-1BLK 65.52.0.0 - 65.55.255.255.
The terms people arriving at our site through search.live.com are just... weird, though. Most are outright vulgar, searching for obscure pornography or celebrity names, drugs, sex aids... Here's an few examples:
65.55.165.36 http://search.live.com/result.aspx?q=valtrex&mrt=en-us&FORM=LVSP
/log/trunk Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; .NET CLR
1.1.4322)
131.107.0.95 http://search.live.com/result.aspx?q=breast+enhancement&mrt=en-us&FORM=LVSP /
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; Win64; x64; SV1)
65.55.165.122 http://search.live.com/result.aspx?q=ferarri&mrt=en-us&FORM=LVSP
/browser/media/tutorials Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2;
.NET CLR 1.1.4322)
These hits were to small obscure pages on our site, such as svn changelogs, and then I noticed the source IP addresses were in just a few IP ranges, so I ran a whois to see if one ISP tied connected them all;
arc@sobek ~/work/pysoy $ whois 65.55.165.83
OrgName: Microsoft Corp
OrgID: MSFT
Address: One Microsoft Way
City: Redmond
StateProv: WA
PostalCode: 98052
Country: US
NetRange: 65.52.0.0 - 65.55.255.255
CIDR: 65.52.0.0/14
NetName: MICROSOFT-1BLK
You read that correctly. Microsoft, in a desperate attempt to make themselves seem more important, or perhaps just to flood free software project's websites with unwanted traffic, is running bots which act like normal web crawlers. Indeed, over 97% of the hits we got from search.live.com were from Microsoft's own IP subnets. Searching Google, I found this story was previously covered by others more observant of their logs.
In response, I'm adding a special rule to block all future traffic from the offending netblocks, including MICROSOFT 131.107.0.0 - 131.107.255.255 and MICROSOFT-1BLK 65.52.0.0 - 65.55.255.255.
Thursday, February 14, 2008
libjingle disappointments
Last year we chalked libjingle as our choice for a XMPP library, since it handled all the networking we needed (ICE-UDP, HTTP, etc) tightly integrated with XMPP through a standard protocol.
On closer inspection, we found why libjingle hasn't really been adopted by the community yet. For starters it requires patches to build the latest release with GCC 4, and no release has been made to include these patches in months. Not a good sign.
Next we find there are no dynamic libjingle libraries, it builds as static only, and doesn't build for C programs (only C++). Unless we transformed our project to build as C++ this isn't an immediate option.
Looking over the libjingle code structure, it's in a severe state of poor maintenance. The internal name for it appears to be "libcricket", with naming confusion all over the place, code format inconsistencies, and extremely poorly documented.
Thus, libjingle integration is unlikely until after PySoy's Beta-3 release when we'll have time to write the C shim code as a dynamic library.
All this said, libjingle appears to have great potential for us and the entire free software community, it's just in need of attention from a few detail-oriented developers.
On closer inspection, we found why libjingle hasn't really been adopted by the community yet. For starters it requires patches to build the latest release with GCC 4, and no release has been made to include these patches in months. Not a good sign.
Next we find there are no dynamic libjingle libraries, it builds as static only, and doesn't build for C programs (only C++). Unless we transformed our project to build as C++ this isn't an immediate option.
Looking over the libjingle code structure, it's in a severe state of poor maintenance. The internal name for it appears to be "libcricket", with naming confusion all over the place, code format inconsistencies, and extremely poorly documented.
Thus, libjingle integration is unlikely until after PySoy's Beta-3 release when we'll have time to write the C shim code as a dynamic library.
All this said, libjingle appears to have great potential for us and the entire free software community, it's just in need of attention from a few detail-oriented developers.
Monday, February 11, 2008
consolidated _core-*/ to _core/
Last year Pyrex, then version 0.9.5.1a, did not support compile-time conditions for things such as platform specific code. To work around this used different _core directories, one for each platform, and a platform test in setup.py would determine which directory soy._core was compiled from.
While functional, this created duplicated work and a fairly messy source tree with four different _core-* directories. With Pyrex 0.9.6 release came support for code such as this:
... and, thus, we could finally merge those _core-* directories into src/_core and remove kludge from setup.py. Tonight that's exactly what I did. Behold, http://svn.pysoy.org/trunk/pysoy/src
While functional, this created duplicated work and a fairly messy source tree with four different _core-* directories. With Pyrex 0.9.6 release came support for code such as this:
IF UNAME_SYSNAME == "Windows":
include "icky_definitions.pxi"
ELIF UNAME_SYSNAME == "Darwin":
include "nice_definitions.pxi"
ELIF UNAME_SYSNAME == "Linux":
include "penguin_definitions.pxi"
ELSE:
include "other_definitions.pxi"
... and, thus, we could finally merge those _core-* directories into src/_core and remove kludge from setup.py. Tonight that's exactly what I did. Behold, http://svn.pysoy.org/trunk/pysoy/src
Wednesday, February 06, 2008
website makeover and new logo
We've been working with the same website design (www.pysoy.org) for a year now. While it got the job done, we're in need of a makeover - and that's exactly what's going on. The basic layout from Planet PySoy is going site-wide with a new docs section, info on how to get involved with development, separate bug and task/idea/etc filing forms, and a ton of new features that will make the site more community-oriented.
In the spirit of community inclusion, I'm also opening the new logo for collaboration and competition for. Draft logos can be worked on in http://svn.pysoy.org/media/logos with the final designs voted on by all active developers near the end of this month. We'll aim to include this in the beta-3 release next month as a special mesh and texture.
In the spirit of community inclusion, I'm also opening the new logo for collaboration and competition for. Draft logos can be worked on in http://svn.pysoy.org/media/logos with the final designs voted on by all active developers near the end of this month. We'll aim to include this in the beta-3 release next month as a special mesh and texture.
Friday, February 01, 2008
normals (dot3) texture
With a few minor bugs left to be worked out, we now have normals mapping. This was written by Jaroslaw Tworek, a high school student in Poland who also added recently volumetric fog and billboards. These features and more will be included in the Beta-3 release next month.Bump Mapping; yet another feature PySoy has over it's predecessor.
downtime and new server
As many people have noticed, *.pysoy.org was down yesterday. Since our former server is still offline (thanks, Verizon) I've paid out of pocket for a new colocated server hosted at ServerBeach.
After an all-nighter getting it setup, www.pysoy.org is back up, as is svn, and hopefully everything else. I'll resolve any problems tomorrow, as I'm in serious need of sleep now.
After an all-nighter getting it setup, www.pysoy.org is back up, as is svn, and hopefully everything else. I'll resolve any problems tomorrow, as I'm in serious need of sleep now.
Subscribe to:
Posts (Atom)