10 Nov 2011

feedPySoy Blog

Arc Riley: Rugby season nearly over, getting back to work

Wow its been a long time.

We wrapped up Google's Summer of Code 2011 in August. The Python Software Foundation did wonderfully overall, for PySoy 6 of our 7 students passed. A great year overall - thanks to all the mentors and students!

Five man scrum vs WarringtonRugby has been a life changer for me. My first game was in September, after floating in and out of practice for years and training pretty heavily since April. No serious injuries, but no shortage of pain; I've frequently needed to sleep in a reclining chair to keep blood from pooling in my shoulders and nurse bruised ribs, dislocated fingers and toes, shin splints, and pulled muscles everywhere. All so worth it.

These guys are like family to me. I know it sounds sappy, but I've come to trust the men in my pack with my life - in a way we all do every time we bind onto each other a scrum. Its not that big of an adjustment culturally though due to the large number of programmers, lawyers, and IT professionals on the team. When you work behind a desk all day its nice to balance it out with a physically intensive training in the evening and games on Saturday.


Renegades Reds at Hellfest 2011

The climax of the season was Hellfest October 29th in Dallas, TX. Washington Renegades brought our B-side to compete and returned with the 1st place trophy. My teammate Jimbo has more pics on his blog of the tournament, I was wearing #23 as tighthead prop.

We have two more games this season before we settle in for the Winter and indoor off-season training at the gym. A group of us plan to do a 8-week program run by a professional rugby player this Winter to get ready for the Spring season and the Bingham Cup 2012 in Manchester UK next June.

Today the PySoy project was accepted to Google Code-In. We've got a number of student tasks lined up, with many more being worked on for the first batch set to release in less than two weeks. Interested students should hop on Freenode (#PySoy) and get oriented before the program starts so they're ready to jump right into their first task!

10 Nov 2011 1:15am GMT

30 Aug 2011

feedPySoy Blog

Mayank Singh: Post Gsoc musings

It's been a long time since I last blogged. And yes my gsoc got over officially and successfully on 26th. So, I thought of this to be a nice occasion to blog.

I got a really nice oppportunity to work on a game engine still in its nascent stages and observe all the hurdles and problems related to creating such an engine when I got into the gsoc program under python software foundation this april. And yes I experienced all those showstoppers. But due to enormous help from my mentor Arc and google, I was able to surpass them.

To begin with the tale, I was supposed to create a controller for wiimotes to be used with PySoy. But this first involved getting the wiimote communicate with the PC. A wiimote communicates via bluetooth. I googled a lot about this communication and found out that it was almost fully reverse engineered. The best place to visit regarding all this revengs would be wiibrew.org. However, I didn't want to delve into sockets and all considering there were ready-made libraries for wiimote communication. I did a study of all those libraries. I found two libraries that seemed to catch my eye and thus suit for this purpose. One of them was cwiid and the other wiiuse. Cwiid seemed to be the most popular considering its packages in all major linux distros. So, I went forward with cwiid (I would regret this later). Having decided upon the library, next step was to figure out how to use it in the game engine. Since, the backend of our engine(libsoy) was being written in vala and genie (abstractions over C and gobject based), I had to write the vala apis of each non-gobject C library I used. For me, there were two: cwiid and bluez. I spent the first fifteen days understanding the concept of vala apis, and writing vala apis(vapis) for cwiid and bluez. At the end of this period, I was able to write code in Genie(pythonic form of vala) and connect to a wiimote. In the next period that lasted upto the mid-term evaluations, I created various examples to leverage the functions of the library with our game engine. One example allowed to control a cube via the accelerometer though it wasn't calibrated properly. Another allowed to control the same cube via the buttons on the wiimote. However, the technique used to control the cube was to query the wiimote every time for state information and use it to move the cube. As is clear, this wasn't a nice method. Near the end of this period, I started to correct this and write callback functions to act as interrupts for events happening on the wiimote. However, Due to a possible race condition I got stuck on a segmentation fault. Arc suggested to create a separate thread for non-window controller events. I embarked on that. However, in a discussion with Arc later, we discovered that the library cwiid was already using three threads inside it and had a lot of redundant code as well. That's when I had to take tough decision to dump cwiid and do something else.

At this point, Arc started taking great interest in my project and found out that another gsoc student David herrmann was working on writing a bluez driver for wiimote. He even got him on Google+. There we checked out his kernel driver and bluez plugin which were all working great (Kudos to him). The good part about it was that this made the wiimote directly accessible by the x11 xinput2 (something that allows multiple pointers and cursors on the same screen). Also in the meantime, Arc made the major decision to dump Gdk for windowing and is currently using vanilla x11 with egl on top (this is currently in experimental). At this very time, I did my first custom kernel compilations patched with the kernel driver after which numerous more followed due to some mistakes here and there. When I finally got wiimote pairing with my laptop natively, I started looking into the usage of his kernel driver. Turned out, he had switched off accelerometer and IR pointer information reporting due to large usage of bandwidth and you could switch it on by writing to sysfs files created for the wiimote on pairing. I tried googling on a library to edit sysfs files but turned out they did not need any special library but normal file handling to write to them. Also, Arc wasn't happy with sysfs file editing in the game engine so I resolved upon writing an x.org driver for wiimote to handle all this and also map buttons and handle accelerometer and IR data. Currently, the driver isn't yet complete and I am taking a bit of rest post-gsoc. You can check it out at here. I plan to complete it after my college tests. Meanwhile, to test the IR pointer, I had made a makeshift circuit on a breadboard using some IR emitters from certain obstacle detectors I had from an earlier project.

All in all, my gsoc experience was a perfect example of a real-world coding environment filled with all its ups and lows.

30 Aug 2011 8:39pm GMT

16 Aug 2011

feedPySoy Blog

Anthus Williams: Less than a week

With less than a week the firm "pencils down" date, I'm feeling a little disappointed in where my project is. I'm at the point where mesh morphs are operational (albeit buggy), with what I consider is a solid and simple API.

 mesh = soy.models.Mesh()

mesh.size = 6
mesh[0] = face //a soy.atoms.Face object
// repeat for mesh[1] through mesh[5]
clone = mesh.clone()
//clone is a Mesh object that can be rendered in its own right, if it is bound to a body
//change the face and vertex data for clone[0] through clone[5]
target = soy.models.Target(mesh)
morph = mesh.morph(clone,0.5) //mesh.morph(variantMesh,delta) spins off a soy.atoms.Morph object
target.morphs.add(morph)
//now you bind target to a soy.bodies.Body, and when its render() method is called, it will apply all its morphs at their given deltas

Rendering has not been done yet for Mesh, and this process will be complicated on the back-end once we perform optimization. Basically we have to maintain the public vertex ordering while shifting vertices around on the backend so that OpenGL can render faces that have the same material consecutively (having to switch between materials needlessly is costly). This is already done for getters and setters for Mesh, but not honored by clone(), soy.atoms.Morph, or by the Target constructor.

Odds are this process won't even be kind of complete by pencils down, but I would expect something more fully functional by PyCon.

16 Aug 2011 4:47pm GMT

15 Aug 2011

feedPySoy Blog

Juhani Åhman: Final week

Today starts the final week of GSOC.
Yesterday was supposed to be a "pencils down" day, so I won't be implementing any new features to 2DSide any more. I will spend the remaining week on porting all my changes in default branch to experimental and hopefully to write python bindings for everything I have done in pysoy side. If time permits, I will try to write a small example program in python for the 2Dside class.


15 Aug 2011 8:15am GMT

09 Aug 2011

feedPySoy Blog

Anthus Williams: One week to "pencils down"

We have a little less than a week until the soft "pencils down" deadline. In theory, we are supposed to spend the remaining time after that point doing cleanup, documentation, etc. In practice, that will hardly be the case. The firm "pencils down" deadline is two weeks away. I'm on track to have the basic morph completed by Thursday. Then I will spend the weekend figuring out a basic keyframe pattern using atomics. Then the final week will be spent working on Mesh itself -- e.g. on rendering and optimization, which still has not been done.
At first our thinking was that a morph target is a type of model. One would render the target instead of rendering the original mesh. That idea is incorrect because it makes it difficult to apply multiple morphs to the same mesh.
The direction I've been going is this: you create a morph atom, which is calculated as the difference between two meshes. Mesh has to honor a public array of vertices as it is (even though it will be performing optimizations behind the scenes), so we assume the public ordering is valid for both methods. This means for any given vertex, mesh A contains that vertex's position, normal, etc. when the morph is at 0.0, and mesh B contains that information when the morph is at 1.0.
Then you can specify a delta, between 0.0 and 1.0, and the atom computes the vertex interpolation. Then you bind the morph atom (which is basically a matrix of values to be added) to the original mesh. This means that rendering is done on the original mesh, rather than a target model, and multiple morph atoms can be added to a single mesh.p
Animation is a little more difficult problem, but expressing morph as an atomic makes it more tractable. I'm thinking the morph atom will have an optional property (some sort of soy.atoms.Keyframe), which basically expresses what the transformation matrix will look like at some point in the future. Then as we step through the thread, we compute the matrix by multiplying the delta by the ratio between the current time and the keyframe. This could get costly if we are generating new objects every time, but it should work, especially if we have an OpenGL VBO doing the actual work of applying the matrices for us.

09 Aug 2011 1:23pm GMT

06 Aug 2011

feedPySoy Blog

Amaury Medeiros: Finally, scroll is done.

It's been a while since the last time I posted here. I spent this time to continue working on VScroll and HScroll. Good news: they're ready. I've read a chapter of the Red Book of OpenGL that helped me a lot on the implementation of Scrollers. The most annoying part of that is OpenGL uses a different coordinates system from the usual.

After some reading and testing, I solved the problem I was having in the last post using glOrtho. The results can be seen on the pictures below. The next step is beggining the implementation of collapsible branches.


06 Aug 2011 6:19pm GMT

02 Aug 2011

feedPySoy Blog

Juhani Åhman: fields update

quick update about fields: I have now managed to port fields to libsoy almost completely, but not quite. This was quite much larger work than I originally thought as much of the stuff in soy.scenes.Scene required for fields (tags, mass, etc.) weren't ported to libsoy either, so porting those has taken quite much time. I have managed to port the fields stuff now mostly, but I still have some issues actually using them in soy.scenes.Scene as the original code in pysoy seemed to be partially broken as well (it was commented out completely). I'm trying to work up a demo program to test fields now and I hope to get it working soonish as soon as I figure out this little problem.

02 Aug 2011 12:39pm GMT

29 Jul 2011

feedPySoy Blog

Anthus Williams: eglib

Not much interesting in the way of updates this week. PySoy is facing a bit of a transitional period. We're wanting to move away from GTK 2.x, because gtkglext does not support nVidia cards, among other reasons. But the question has been -- moving where? We toyed with GTK 3 but we need something with better bluetooth support, etc. Clutter was an option but seems to be no good because it does not support OpenGL features like cubemapping, which will become very important to us.

So now it looks like we are going to be writing our own library to work with EGL. It's called eglib. It sounds like an interesting proposition, but I worry that it may be increasing the scope of our project beyond our ability to quickly roll out. We'll see what happens.

29 Jul 2011 1:04am GMT

21 Jul 2011

feedPySoy Blog

Arc Riley: Transcoding FLAC to Ogg Vorbis

Last night I hit a dilemma; a very old CD I ripped to FLAC and now can't find was playable only on certain players, not my Android phone (despite FLAC support) and behaving strange on many desktop players.

Usually I just use something like oggenc -q 4 *.flac since vorbis-tools supports FLAC as a source format (and preserves metadata like artist, title, etc). Strangely, oggenc didn't recognize the files in this album.

GStreamer to the rescue; for file in *.flac; do gst-launch-0.10 filesrc location="$file" ! decodebin ! audioconvert ! vorbisenc quality=0.4 ! oggmux ! filesink location="$file.ogg"; done;

Even though its much slower and more complicated, this should have done the trick. It didn't, and ogginfo showed that the Ogg muxer in GStreamer has some issues;


WARNING: granulepos in stream 1 decreases from 218558 to 205632
WARNING: granulepos in stream 1 decreases from 666174 to 655680
WARNING: granulepos in stream 1 decreases from 3150206 to 3142208
WARNING: granulepos in stream 1 decreases from 3605054 to 3597376
WARNING: granulepos in stream 1 decreases from 3828670 to 3822400
WARNING: granulepos in stream 1 decreases from 4741630 to 4733312
WARNING: granulepos in stream 1 decreases from 5636158 to 5630784
WARNING: granulepos in stream 1 decreases from 5858494 to 5854208
WARNING: granulepos in stream 1 decreases from 6096126 to 6090560
WARNING: granulepos in stream 1 decreases from 6317758 to 6314048
WARNING: granulepos in stream 1 decreases from 7668798 to 7665088
WARNING: granulepos in stream 1 decreases from 7902718 to 7898240



So with GStreamer not an option, I looked at the original FLAC files and found that whatever encoder I used added ID3 tags (which are not part of the FLAC spec). A quick ID3 removal command stripped these out so oggenc would recognize the files and work;


find . -name "*.flac" -exec id3v2 --delete-all {} \;
oggenc -q 4 *.flac



Done.

21 Jul 2011 12:46pm GMT

18 Jul 2011

feedPySoy Blog

Anthus Williams: The best way isn't always the sexiest

This week I had to abandon my attempts to develop on Ubuntu. It seems NVidia's Ubuntu drivers lack support for some of the OpenGL calls libsoy's windowing system is making. So I am now developing solely on Mac OS X. My OS X install has X11 support, so after my initial struggle trying to compile libsoy at the beginning of the summer, I've been able to run libsoy almost without a hitch.

One thing missing, though, is cwiid support. That's fine, since cwiid is an optional dependency for the Wiimote controller. It's easy to set a dependency as optional in wscript: you just add the "Mandatory=false" flag to your conf.check_cfg(). So the configuration doesn't error out. However, the one deceptively difficult issue was in telling waf to avoid compiling the Wiimote.gs controller if cwiid is not installed. So the build breaks.

I'm the only one really affected by this issue, so I set out to learn a little about Waf (by reading the Waf Book). And I found myself trying all afternoon to make a change that on its surface seems quite simple. There are too many source files to add them to Waf's task generator one by one, and bld.add_subdirs() does not make it easy to add constraints. So I toiled around with extending Waf's TaskGenerator class for a while. Nothing doing. So, failing that, I just used ant_glob to generate a list, and wrote an if statement that removes the file Wiimote.gs from the result, if cwiid cannot be found in the configuration.

I spent hours trying to build a sexy solution, only to settle for a kludge. It's a lesson I have a hard time learning -- I should have rolled out that little bit of hackery to begin with. Sometimes the best way makes you feel a little dirty, but it's still the best way. Problem solved; onto the next one.

18 Jul 2011 1:55pm GMT

17 Jul 2011

feedPySoy Blog

Sara Foster: Learning OpenGL

So today and yesterday to a lesser extent, I've been reading the "Red Book" on OpenGL. It's seems long overdue since I'm working on an OpenGL based game engine. I just didn't realize until now how necessary it would be. This way I'll be able to start making commits on the OpenGL side of things. To think that before this summer I thought OpenGL WAS a game engine...derp.

I hope to get some code done today as well, although I haven't made much headway on implementing scenes as a dictionary. So it will be unrelated to that. It's a little bit over my head to be honest, so it's definitely taking some time to figure out what's what with Mapping Protocol and such, and how it actually would be used in the context necessary to actually get this all to work.

17 Jul 2011 10:43am GMT

14 Jul 2011

feedPySoy Blog

Juhani Åhman: Quick update

Managed to fix some bugs in models, atom abuse and ode vapi. Still have not been able implement gravity for 2d bodies. It looks like the solution is not so easy as I thought. Thankfully, Toba&Arc have now suggested me to use, Toba's work, soy.fields to gauge this. Unfortunately, soy.fields have not been ported to libsoy yet, so it looks like I am going to be porting his work to libsoy next.

14 Jul 2011 5:34am GMT

11 Jul 2011

feedPySoy Blog

Anthus Williams: I have diabetes

I have been diagnosed with Type I diabetes. I am the first in my family to have it. It's been a rough ride but on the plus side I now know why I have been so tired and practically non-sentient over the past month. And suddenly having insulin in me makes me feel once again as though I can take on the world.

The past few months of gradual emaciation has affected a lot more in my life than just GSOC. My odds of failure are tremendously high at this point, for GSOC and other areas of my life. But I'm not so far gone as to believe my actions cannot effect the outcome. There's still ~6 weeks to go, and I plan to do some damage with them.

11 Jul 2011 11:40pm GMT

Mayank Singh: Week 7

So, I have started up on threads which is a completely new topic to me. First I'll have to understand how the threads work internally because I tried running sample thread programs in Gdk and couldn't figure out why a certain command was executing before the other. I have started up on the _ControllerThread.gs and will keep updating as and when I gather more knowledge. After this thread is ready and I figure out how to use this with my wii controller events, I'll be back on track to creating my wii controller api.

11 Jul 2011 3:35pm GMT

Sara Foster: Scenes and Dictionary

So today I'm working on changing a scene to work as sequences of bodies. As right now there is no way to know which bodies belong to which scene based upon only have the scene as information. Creating an external storage only makes the code using it really messy. I tried this originally before I realized how silly it was to do it that way, when it could be changed in the API to work better. So I asked Arc about it.


Originally Arc said it was intended to implement this as a sequence of bodies, but after we talked he came to conclusion that it would be better implemented as a dictionary of bodies. This way bodies can be created outside of a scene, be removed from a scene and essentially exist outside of a scene. (In a void scene which contains all bodies not contained in a scene.) Also with the dictionary it helps reference the various different bodies of different names.

So what I'll be doing is looking into Python3's Mapping Protocol, and figure out how to make this all work.

11 Jul 2011 1:02pm GMT

10 Jul 2011

feedPySoy Blog

Amaury Medeiros: It's scrolling :)

From the last post to now, I could progress more. After the entire scrollbar appears on the screen, the next step was the scroll itself also appears. So the correct size to the scroll is now being calculated and it's being drawn on the screen (when it's necessary). The color of the scroll is different from the bar, so we can see it better.

To drag, move and drop the scroll with pointer, I used some previous work from another PySoy student: Juhani Åhman. Thank him for it. The limits of the scroll are set, so you can't drag the bar beyond the limits it should be dragged. The pictures below show how HScroll looks right now.



As you can see, they're not ready. The total content is being displayed but the screen should show just the content that's inside the widget area and as the scroll rolls, the content should change. I'm trying to make those changes to make the widget work as expected. The expected behaviour of the widget can be visualized below.



Last night and today, Arc made some changes in PySoy properties. He told me to take a look at the widgets I'm writting to see how I'm using them. The result: I made a bit cleanup in the code, changed some attributes' visibility and remove some that were obsolete.

I'd like to thank my mentor, David, again for the help he's giving me. Mid-term is coming and I think I'll have to change my timeline a bit.

10 Jul 2011 6:36pm GMT