Building firefox

First attempt was to clone the repo at Seneca on the wireless connection. This failed because the wireless is slow and I didn't have the time to sit around and wait for it to download.
So then I did it at home. I forked and cloned the mozilla-central repo and then started doing the build pre-requisite steps.

I entered the command to update macports (a very old version of which was on my machine) and then waited while it did its thing. Then it refused to update properly because it had a really old version of ncurses and apparently it switched development branches or something at some point and couldn't autoupdate it. So I decided not to bother changing that.

So I used homebrew instead to do the prerequisites and, after removing macports, it worked really well.

Then the compilation failed because I had xcode 3 installed on my machine and it needed xcode 4. Which I can't get because it requires that you have OSX 10.7 installed. Which I can't do because my mac has a 32 bit processor and 10.7 requires 64 bits.

Not seeing any way around this I decided to do it on my windows machine instead. I installed visual studio 2010, the directx sdk, and then the mozilla build package, and used git to clone my fork of mozilla-central. I then attempted to build it and ran into an error.

The error was "This source tree appears to have windows-style line endings. To convert it to Unix-style line endings, run "python mozilla/build/wind32/mozilla-dos2unix.py".
The problem is that that file doesn't exist.

So I fixed the error by following the instructions at help.github.com/articles/dealing-with-line-endings to change the git global configuration to unix style endings and then reset the working tree. This time it compiled without any problems, and it took around an hour to finish. Here is a screenshot of the result.

 

I made a game!

For the past few weeks I've been given the opportunity to spend my time on whatever I want to so long as it's shippable by the end of the month. So I decided to make a game using gladiusjs!

I have two reasons for doing so, the first being that making a game would allow me to see flaws/missing features in the engine that you really can't see unless you are forced to use it. This is called eating your own dogfood, and is a very important process for anyone shipping software that is going to be used by other people. The second reason is that it would provide a great example that other people can hack on or build off of to make their own game- anyone can just copy it and then skip whatever setup steps are required to make the engine work properly. I feel that this would make creating your own game as a new developer a much easier process.

You can see the game on the gallery page at dperit.github.com. Just click on the tank example to play it, or go directly to http://dperit.github.com/gladius/examples/tank/index.html

I found a number of ways to improve the engine while I was working with it. Here is a little change log detailing the enhancements I've made. It is rather jargon-y

Transform

• Added a directionToLocal function that takes a vector3 direction in the world frame and returns that vector3 direction in the local transform's frame of reference
• Added a transformToLocal function that takes a transform and returns the vector3 location of that transform in the current transform's frame of reference
• Added a toWorldPoint function that returns the vector3 location of this transform in the world's frame of reference

 Box2D

• Exposed the setAngularVelocity and setLinearVelocity functions of bodies
• Added a dimension mapping feature where you can specify the dimensions that you want box2D to map to in a 3D world. So you can have it map to XY (default), XZ, or ZY. This is done by giving arguments to the resolver when you are initializing the extension-there is code near the top of the tank example that maps the physics to the XZ plane
• Exposed the bullet property of the body definition, which indicates that this dynamic body is expected to collide with other dynamic bodies and should be monitored more closely for collisions as a result
• Exposed the friction, restitution (bounciness), and collision filter options for fixture definition. Collision filtering allows you to set, through bitmasks, the categories of objects that a given fixture will and will not collide with. There's an example of this being used in tank.js on line 286
• Changed boxshape so that the size you give it will match up exactly to size in transform
• Added a circleshape which makes a circle

General

•   Added a procedural sphere loader which allows you to put spheres in your game. Goes well with circleshape in Box2D

At the moment these changes can only be seen in various branches on my forks of gladius, gladius-core, and gladius-box2d.

Working out of Mozilla's offices

I've spent 2 days working at Mozilla Toronto's offices (MoTo) and I've found it to be a really effective space for getting work done.

The building itself is secure, meaning that I don't have to pay any attention to preventing my stuff from being stolen, and (unlike CDOT) I also don't have to ask wanderers what they are doing here or direct them to a prof's office.

I like the aesthetic of the office- wood flooring, support beams, and ceiling combined with brick exterior walls creates an atmosphere that ranges from cozy in the lounge area to professional in the meeting rooms.

There are many places available where I can work. A number of meeting rooms with sliding glass doors are available on a first come, first serve basis. These can be grabbed to do large meetings, pair programming, or even just solo work when you need absolute quiet. There's also a small lounge area, a kitchen, and a small dining area.

Supplies are quite plentiful. All of the spaces are equipped with Apple power adapters, so that I don't even have to unplug my adapter to move to a new space as wanted/needed. The entire office is also blanketed with wireless internet access that doesn't have any restrictions on it that have impacted my work ability. It's also clear that Mozilla employees have high priority placed on the supplies and equipment that they need, and there are resources in place to get those things to them quickly and reliably.

There's also a lot of food and snacks available. Various fruits and nuts, a wall of snacks, a cooler full of drinks, and (I'm sure) more are freely obtainable.

The combined effect of the things I've noted has been to remove obstacles from my workflow and substantially reduce the number of non-software development related tasks I have to think about in my day.
Aside from getting lunch I don't have to worry about making sure that I have a steady supply of food available to keep me thinking effectively throughout the day.
If I want to move and work at a new location I don't have to spend time unplugging my laptop and unlocking it and then dragging it plus my backpack with me to the new spot.
If I need to have a remote or in person meeting or do pair programming I don't have to take the time to reserve a meeting room or find someone with keys to unlock an office, nor do I have to manually reconfigure my network connection for the new wired connection because I can't rely on the wireless.
I don't have to spend time thinking about the security of my belongings because the doors to the office close and lock automatically, always.
The office environment also makes me feel valued and trusted, things that I want to return to the company in the form of lots of hard work, and I'm not even employed by them!

This has all made working with Mozilla on the gladius engine a very productive experience. I should mention that we're always looking for more people to contribute to or use the project- please don't hesitate to hop into #games on irc.mozilla.org and talk to dperit or ack or dmose about gladius!

I made a game!

I made a game! It's called Uprooted, and is part of the set of 4 Turtlesback games made for Native Earth by me and some other people. It's written in processing, and ported onto the web browser using processing.js
You can play it at http://turtlesback.ca/creationgames/
Enjoy!

Gladius introduction

I have been assigned to work on Mozilla's gladius game engine project!

The processes in use with this team at Mozilla are quite effective. They use trello for keeping track of and assigning development tickets. This makes it very easy to keep track of what has been done/needs to be done on a project, and if the tickets are small enough then you can clear out multiple ones in a day. This is a tremendous morale booster as it reminds you of everything that you complete every day, giving a real sense of accomplishment.  It can also serve as a reminder of how much work is left to do on a project, and how much has been done.

Trello is synced manually to github- new tickets are entered into github and then placed onto Trello through a process that I haven't witnessed yet.

Google Hangout has proved to be a good tool for doing group conferencing. Interface features, like automatically switching to show the viewpoint of the person who's talking, are the kind of subtle effectiveness that marks good UI design. It's also somewhat reliable! It sucks at notifying you that you've been invited to a hangout, though.

We've done daily standup meetings (performed sitting down, of course, this is the internet, we do things differently here) through Hangout. They're useful for letting people know about problems and what your plans are for the day, so that you have an ideal chance to fix problems, and it forces you to hear other people's plans. If you forget what a person is working on you can check on Trello. It would be easy to forget to check Trello and lost touch with other people on the project, but then the daily standups put you back into contact again.

Screen sharing has been working well for doing pair programming on Hangout, which has been extremely useful in getting me up to speed on javascript and the gladius engine. It's definitely been the most effective way I've seen so far of introducing a new person to a programming project.

As always github remains an effective source control/lazy backup mechanism. Though the actions that make up a typical workflow in git remain pretty arcane. Seems like a limitation of the whole command line interface in general- I remember having similar frustrations in old adventure games that took text input- the syntax of what you want the program to do won't always match up with what it is trained to recognize.

Webstorm continues to be an awesome IDE. A great deal of care has obviously been taken with its UI and design- it streamlines all of my processes, I've never had to fight with it very much to get it to do something, and it has all sorts of nice features (like github integration) built in. Getting started with it is quite simple, too- I just drag the project folder onto the icon in my dock and it just works.

The p5 IDE is not very good.

A project that I've been working on for the last 4 months at CDOT has involved making a relatively complex game (39 files, 240 KB of code). This was my first experience making an actual structured program in the Processing IDE and it really served to highlight the inadequacies of that program, which are as follows:

1. No debugging. Yes, you'd better get used to println statements to narrow down a program's behaviour.
2. Call stack on crash is not useful. The thing that normally tells you what line number your program crashed on as well as the set of calls that led to that point is less useful because all of your code files get jammed together by P5 when it compiles. So the line number that it gives you is the line number in the concatenated stack of code files. Which is a completely useless number because you have no way of finding that line.
3. Their tabbed interface sucks for a large number of files. If it doesn't have enough space on the tab line to write the names of all the tabs than it collapses the tabs that don't fit into tabs without names on them, which makes it annoying to switch between them because you can't tell what file the tab you are clicking on contains.

In short, try using Eclipse with a plugin to develop processing applications. It involves more overhead because you have to specify the names of the objects that you are calling when you do things like draw() or image() but you will at least be able to debug the program and see where it is crashing. And it has much better tools for managing the files in your project as well.

Parallax scrolling in processing and processingJS

A very special secret project that I am working on at CDOT involves the creation of a very large scene- one that extends well beyond the actually visible area. Here is an abstract representation of how that scene is laid out:






















The viewable area is the part of the scene that the user actually sees. You can set this area by calling translate(-screenCornerX, -screenCornerY), where screenCornerX and Y are the co-ordinates of the top left corner of the viewable area, at the start of each draw loop. This moves the entire sketch over so that the elements you want the user to see are placed on their screen.

A smooth scrolling effect can be created by keeping track of the amount of time between draw calls. The millis() function tells you the amount of time between now and the start of the program. Storing this value and subtracting what it is now from what it was in the previous frame tells you the number of milliseconds between frames. You can multiply that value by a scrollRateXPerMillisecond and scrollRateYPerMillisecond to get values to add to screenCornerX and screenCornerY which will cause the screen to scroll at a constant rate over time.

But there is a problem with this approach. You can see in the image that there are foreground objects and background objects. The background objects are intended to appear far, far behind the foreground objects but because they both scroll at the same rate the viewer sees that they are at the same height!
The solution to this problem is to use the technique known as Parallax scrolling.

With parallax scrolling when we are drawing a scene we want to draw the background elements first, so that the foreground elements appear on top of them. But we don't want to translate the full screenCornerX and screenCornerY values over- instead we want to translate(-screenCornerX/10, -screenCornerY/10). We refer to the 10 in that function call as our parallax factor- it's actually a good idea to take the 10 out of there and put it in a constant variable so that our call looks like translate(-screenCornerX/PARALLAX_FACTOR, -screenCornerY/PARALLAX_FACTOR) instead.


You can then draw all the background elements as normal, but because our translate call is different the purple area in this image will end up being our background instead of the green area.
Next we reverse the translation (this is most easily done by calling pushStyle() before the translation and drawing and popStyle() afterwards) and then translate the full screenCorner amounts and draw our foreground elements.


This image shows the results of the new drawing mechanism after the foreground has scrolled 90 pixels down and 90 pixels to the right. The background area only scrolled 9 pixels down and 9 pixels right during the transition, and the user perceived the foreground objects moving 10 times faster on the screen then the background objects did. This creates the illusion that the background elements are much further away than the foreground elements, adding a great sense of depth to the scene.