PySoy Blog

GCI Low Hanging Fruit

2011-12-16T12:06:28+00:00

I have to admit I'm pretty surprised that at halfway through Google Code-In 2011 only about a quarter of the tasks we posted for the first half have been completed or in-progress. Further, most of the tasks thus far haven't been coding tasks.

I'm going to publish here a list of what we consider "low hanging fruit"; coding tasks which are fairly easy to get started with. If you're a student age 13-17 these would be an easy way to earn a Google tshirt and some cash. All of these tasks deal with OpenGL rendering, usually just arrays for points and lines/triangles which connect the points. There's a lot of examples in the code already for this and numerous tutorials on the web (such as NeHe).

Simple Rendering: We have 2 new tasks listed for rendering simple models; Camera and Light. Camera is very simple, while Light can be as simple or complex as you want to make it.
Shapes Rendering: We have 3 tasks for rendering shapes, Box, Room, and Sphere. Any of these could be knocked out in a few hours even without prior OpenGL knowledge.
Joints Rendering: We have 6 new tasks up for rendering joints; Ball, Fixed, Hinge, Piston, Slider, and Universal. Joints (soy.joints) connect two bodies such that they can only move in respect to each other in a certain way, such as a door hinge or piston. These are all documented with graphic depictions. This is slightly more complex than the simple rendering tasks (above) in that there's two pieces to each joint and they can be rendered as either wireframe or solid (with provided materials).

As always, we're on IRC if a student wants to discuss these or other tasks.

PyTTY 0.3

2011-12-14T00:27:30+00:00

Continuing my annual end-of-year coding sprint, I just released PyTTY 0.3.

PyTTY is a Python serial communication package I started last year after a friend said he couldn't use Python 3 yet because pyserial wasn't ported. The point of writing this was to show him that he didn't need an ancient, bloated, poorly-maintained package to do something as simple as serial communication.

What I wrote over an afternoon turned out to be a little over 100 lines of fairly useful code which I've since used in quite a few microcontroller projects (eg, Arduino). Its by no means complete, the only setting is baud rate and there's no Windows support, but its done everything I've needed it to over the last year. The only problem that's been reported is poor documentation which this release aims to fix. It includes a short code example ("pydoc pytty.TTY") which runs on both legacy Python and Python 3.

PyTTY 0.3 is under 135 lines of pure Python and relies only on the Python standard library. If there's a feature you need which this doesn't have either email me a patch or a feature request so I can add it. The Mercurial repository is http://hg.pytty.org/pytty.

NodeTree 0.2 Released

2011-12-08T12:05:03+00:00

I just shipped NodeTree 0.2.

This version will not parse an XML stream. All it contains are some basic types representing XML nodes such as Comment, Document, and Element. As promised, text is also handled as a node but uses standard Python strings (UTF-8 strings/bytes and unicode). These should all be fairly intuitive to use.

The magic is the XML data is being managed in C using a libxml2 DOM tree but accessed through a Pythonic object-oriented API. For example, in DOM each node may have exactly one parent - in NodeTree a node may be added to any number of parents with a separate DOM node and context for each.

I started this project because the existing XML packages for Python proved too difficult to use with XMPP. Fritzy's SleekXMPP uses lxml but had to jump through several hoops to get stream parsing to work, looking over his work I certainly didn't want to repeat it with Concordance-XMPP.

Beyond this the leading XML API for Python, ElementTree, includes several unfortunate design decisions that make it frustrating to use in the best cases and unusable in others. A full list of why can be left for another time, but the difference to NodeTree can be described in their names - ElementTree is a tree of XML Element nodes with other kinds of nodes either silently dropped, mangled, or made available in bizarre ways (eg, .text and .tail). In contrast, NodeTree provides XML data as a tree of nodes starting with the Document node and includes comment and text nodes in its tree. I plan to provide 100% XML 1.0 support in a future release while maintaining a clean, simple, and intuitive API.

Storing XML data in libxml2 DOM format gives us a few advantages over other XML libraries. First, we'll have XPath, XInclude, and XSLT available without having to convert the data between formats. Second, Python objects only need to be created for nodes Python wants a reference to so when we get to parsing data this will happen much faster and with less memory.

At version 0.2 NodeTree is still in its infancy but some of its API can be demonstrated. Here's a short example:


Python 3.2.2 (default, Oct  3 2011, 00:20:58) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import nodetree
>>> doc = nodetree.Document()
>>> doc.append(nodetree.Comment(' Start '))
>>> doc.append(nodetree.Element('data'))
>>> doc.append(nodetree.Comment(' Fini '))
>>> doc[1].attributes['thing'] = 'normal'
>>> doc[1].append(nodetree.Element('record'))
>>> doc[1][0].append('First') 
>>> doc[1].append(nodetree.Element('record'))
>>> doc[1][1].append('Second')
>>> doc
<?xml version="1.0"?>
<!-- Start -->
<data thing="normal">
  <record>First</record>
  <record>Second</record>
</data>
<!-- Fini -->

NodeTree 0.2 is tested to work with Python 2.6, 2.7, 3.1, 3.2, and 3.3-pre. The next release is intended to support basic file and stream parsing.

XMPP on the web

2011-12-03T20:55:59+00:00

A short thread on G+ has prompted this longer sharing of my vision for XMPP on the web.

For XMPP use on a website we currently have BOSH and, in an extreme-alpha state, XMPP over websockets. The advantage of websockets is obvious, BOSH is a high overhead protocol that we'd all rather not have to use, however both have the same problem: you either must share your login credentials (and thus access to your account) with every website you use a single account with, or must create a new account (JID) for every XMPP-based website you use.

Oauth2 for XMPP might be a partial solution to this by requiring your authorization through a central identity site and using the resulting token for logging in, however, you're still opening yourself up to the 3rd party website accessing your roster, sending spam messages on your behalf, and potentially worse. All this really gives you is the ability to later disable access to websites who misuse your account.

This is the crux of the issue: when using an Javascript library provided by a website and using a proxy provided by that website, whether BOSH, websockets, or otherwise, you're giving that website unlimited access to your account. I have not seen a workable proposal to solve this and until this is solved XMPP cannot see widespread use on the web.

I'm proposing that we solve this by putting XMPP in the browser, either directly or through a plugin. Expose a standard javascript API for allowing websites to use an XMPP connection along with a security model which gives users control as to what a website is allowed to use their connection for. Ie, if a script on a website wants access to their roster the user will be prompted for it, if they want to join a MUC room display a standard prompt for that. Browsers can have multiple XMPP sessions at once and allow the user to select which account they'd like to use with an XMPP-enabled site.

This is just some early ideas, I'm nowhere near implementing this though I think the conversation would be useful to get started.

OpenGL ES support complete

2011-11-28T02:04:56+00:00

The experimental branch, where the OpenGL ES migration was being done, has just been closed and merged into the default branch of PySoy.

Thanks to Steve Anton, one of our Google Code-In 2011 students, for some of the last bits of work to complete the merge. We are now one step closer to mobile support! If you're a student ages 13-17 and would like to earn a Google tshirt and some cash by helping us with Android support, sign up for Google Code-In and claim this task.

Google Code-In 2011 is Open

2011-11-21T04:49:33+00:00

Google Code-In has officially begun!

From today through January 16th students age 13-17 can earn up to $500 working on small tasks for software projects such as MoinMoin, SymPy, and PySoy!

Tasks include coding, documentation, graphic design, video production, testing, translation, research, public speaking, and many other kinds of challenges of varying difficulty.

Completing just one task earns a student a Google tshirt. Every 3 tasks they complete earns them $100, and the 10 top students worldwide will earn an all-expense paid trip to Mountain View, CA to receive an award at Google.

PySoy has over 75 tasks offered for the first half of the program and another 75-100 will be made available December 16th. Our mentors are on Freenode channel #PySoy ready to help students start earning their tshirt and cash today.

Sign up today and get started!

Rugby season nearly over, getting back to work

2011-11-10T01:15:57+00:00

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!

Rugby 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.

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!

Post Gsoc musings

2011-08-30T20:39:00+00:00

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.

Less than a week

2011-08-16T16:47:57+00:00

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.

Final week

2011-08-15T08:15:40+00:00

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.

One week to "pencils down"

2011-08-09T13:23:40+00:00

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.

Finally, scroll is done.

2011-08-06T18:19:03+00:00

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.

fields update

2011-08-02T12:39:45+00:00

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.

eglib

2011-07-29T01:04:42+00:00

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.

Transcoding FLAC to Ogg Vorbis

2011-07-21T12:46:50+00:00

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.

The best way isn't always the sexiest

2011-07-18T13:55:43+00:00

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.

Learning OpenGL

2011-07-17T10:43:48+00:00

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.

Quick update

2011-07-14T05:34:33+00:00

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.

I have diabetes

2011-07-11T23:40:54+00:00

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.

Week 7

2011-07-11T15:35:11+00:00

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.

Scenes and Dictionary

2011-07-11T13:02:50+00:00

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.

It's scrolling :)

2011-07-10T18:36:43+00:00

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.

Atomic Cleanup

2011-07-09T16:22:02+00:00

Yesterday (and the day before that as well) I fixed some bugs with HBox and VBox. Today I'm helping Arc with the atomic cleanup of position/color in various files to fit the newly updated Atoms.

OpenGL and Scrollbar

2011-07-07T11:33:31+00:00

In the previous post, I said the only thing that was missing for V/HScroll widgets was the scrollbar. So I ran into Gtk/Gdk examples to start the bar implementation. After some tests outside PySoy, I decided to try to integrate the example with the PySoy code. I waste some time doing that and discovered I'm not able to do it. Arc Riley told me I have to implement the bar using OpenGL.

Then I started to read an OpenGL tutorial. My mentor, David, said me I had to use Vertex Buffer Object (VBO) and told me to look at some examples in PySoy's code. After that, we shared the VScroll file, using Gobby, and he explained me a lot about OpenGL and VBO.

Yesterday (actually today), before I get to sleep, the first version of the bar appeared! It's a blank rectangle, placed on the right side of the widgets. The next step is to configure the viewport correctly and make the scroll actually roll.

Sphere, box, collisions

2011-07-05T22:08:49+00:00

In the last posting I planned to work on new models (box and sphere) and immovable bodies and gravity settings for TDSide.

I have now implemented new models box and sphere.
These still need changed to use VBO and added to use textures later on, but anyhow they are usable now.

About immovable bodies, I have figured three ways to create them:
setting new category bits for the body in question (eg.box.shape.geom.SetCategoryBits(<some_unique_integer>), to reverse: box.shape.geom.SetCategoryBits(0)), using a fixed joint to fix the body to the world and just setting the body as null for the geom of the shape of the body (eg. box.shape.geom.SetBody(null), to reverse: box.shape.geom.SetBody(box.body)). The first approach is actually meant for setting "collision categories" for different categories of bodies, so I'm not using that. Fixed joint approach seems to cause some weird slowdowns in my test program so I'm not using that either, but the null body setting approach that is also suggested in the ODE FAQ. Sadly, slowdowns still occur with that too in cases where 2d body with a motor on it to make it move constant velocity collides with an immovable body (eg. player is walking towards a wall). In this case, the body will continue to infinitely collide with the immovable body, thus jamming everything. This needs some kind of special handling that I have not figured out yet.

About gravity, the Scene class has a method for setting gravity for ALL bodies, but I want to give the 2d object in TDSide their own gravity setting so that they do not interfere with whatever foreground/background (graphical) bodies there might exist. Not sure how to do this easily.

Week 6

2011-07-03T12:09:03+00:00

So, this week I had almost completed my controller when I got stuck on an issue of multithreading. The problem came when I tried to trigger an event for button press on wiimote from the main thread (unaware that I was triggering on the main thread). And It must have collided with some other event and I was getting a nasty segmentation fault which wasn't even debuggable in gdb. Arc will help me with writing a new thread for controllers on tuesday.
Before that I had implemented message callback function and used it in wiibuttonTest file. Thus, I was able to print the wiimote button codes as and when they were pressed.
A brief note on how the codes are generated:
1. When you press say button 1: 0001 is generated.
2. If you next press button 2: 0001+0002 is generated.
3. Now if you release button 1: 0002 is generated.
4. And releasing button 2: 0000 is generated.

After midsummer & demo

2011-06-28T20:38:17+00:00

Last weekend was midsummer so I didn't get much done over the weekend, but before that worked on the ODE vapi to add param names for stops and motors for joints (namely Plane2D for now). I have now added methods for TDSide to make it easy to move 2D object at constant velocity. I will probably make changes to these, tough.

There is a small demo program called tdside to test the custom scene.
To run it, follow the normal installation of libsoy:
./waf configure build && sudo ./waf install

then run program "tdside" from the command-line (should be on your PATH).
At the moment, you can only collide some boxes to each other on a 2D plane.

Next, I plan to work on following features:
- Add way to set gravity on 2d bodies on TDSide
- Add way to add immovable bodies on TDSide
- Split TDSide to TDSide and TDOverhead classes (inheriting from TDBase or something)
- Models: Implement soy.models.Sphere and soy.models.Box (like Cube but with customs measurements). (it would be nice to be able to use arbitrary models from, say, blender, but that is really not a priority now)

Interactive Console!

2011-06-28T08:19:12+00:00

I found a good way to implement the interactive embedded console for the scene designer! (After a bit of sifting through search results about implementing an embedded python console in C++.)

Now onto to figuring out Pickle. Which is basically serving in place of the future .soy format, as that hasn't been implemented yet in PySoy. As I'm sure most of people reading this know, you wouldn't want to use pickle in the long run due to it being insecure.

Test Improvements

2011-06-26T13:41:32+00:00

This week David told me to change the HScroll/VScroll tests to better visualize they working. He said I could use canvas to do so. At first I faced some problems, because canvas wasn't rendering as expected. After some debug, I found an inconsistency in the Container code. Containers were rendering their children with their own width/height instead of doing this resize using the children's width/height.

After fix Container render method, I had to overrode render method for VScroll and HScroll, to render their children in the correct position. After that, the test seemed more representative and I believe the only thing is missing for VScroll/HScroll is the scroll bar. VScroll render method is shown below.

def override render (x: int, y : int, width : int, height : int)      
    // Render each child widget in order              
    var _x = x              
    var _y = y            
    for widget in self.children  
            widget.render(_x, _y, widget.width, widget.height)

Week 5

2011-06-26T03:48:01+00:00

So, I achieved whatever I had set as targets last week.
1. To detect any wiimote, I had to vapify the BDADDR_ANY and then use it in code in place of hardcoded address.
2. For proper exit, I used the key_press_handler coded by fzzbt earlier.
3. And handled wiimote key input in wiibuttonTest. The problem with that one is that it takes input every n number of seconds as given in the usleep function and so my function gets wii state every n number of seconds. I'll have to think of some other way to handle this. Removing usleep creates crazy reponses.
4. And yeah I have started up on the controller. The challenge I have to face here is that I get all wiimote states via the variable wii state. So, I have to make the controller check wii state every some n number of seconds. Plus connecting the functions with each change.
So, Targets for next week:
1. Complete controller (atleast like the current keyboard or pointer controller)