int main(void)
{

My Blog

Posted 02/24/12 @ 3:19am - By Ross

Day One DLC…more like Day None!

OK, so it’s a lame pun. The point is I’ve seen a lot of talk about DLC content being available on launch day lately, most recently with Mass Effect 3. The reaction to this can be summed up as follows:

To be perfectly honest I think some of that is justified. I can’t say that EA or Bioware has done a terribly good job of handling the PR surrounding this. Its easy to look in from the outside and say that they took time away from making the game to make DLC that they could charge for before the game was even released. The reality, though, is that it’s not that simple.

Looking at it from the dev cycle side of things, by the time the game is largely finished the content generation team is about done. They might help fix bugs as the testing team finds them or correct small things here and there. But their primary function is over. Then, once the game is fully tested, you have to send it off to production. The point is, there is a fair amount of potential wasted time. Why not keep the content generation team generating content after they’ve finished the game? It seems very reasonable and more efficient in terms of resource use.

However, if you take issue with DLC in general then I see your argument as being completely valid. The industry is largely changing direction towards a micro payment system and not everyone is on board with that. Still, EA and Bioware should be given some slack. It may not be hats, but at least they are trying to provide content.

Posted 02/17/12 @ 11:09pm - By Ross

Interviews

Interview questions are the bane of my existence. Something about someone waiting on you to solve a problem causes me to second guess everything I do. However, I do find them interesting to think on after the interview is over. In a recent interview I was asked a question about removal of spaces from a string. My first take on the problem came up with the standard O(n2) version of the algorithm.

Here was my take on it:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
void TrimSpaces(char* word, int size)
{
  int ii, jj;

  for(ii = 0; ii < size;ii++)
  {
    if(word[ii] == ' ')
    {
      for(jj = ii; jj < size - 1; jj++)
      {
        word[jj] = word[jj + 1];
      }
      size--;
    }
  }
}

It’s a fairly straightforward implementation. Loop through and find each space and then shift over all the other characters in the string. In use it actually shouldn’t be too bad since spaces are typically less than half of the characters in a string. Regardless, it’s still not as efficient as it could be.

So as I laid in bed the other night a better solution occurred to me that can be done in linear time.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
void TrimSpaces(char* word, int size)
{
  int ii;
  int offset = 0;

  for(ii = 0; ii < size;ii++)
  {
    if(word[ii] == ' ')
    {
      offset++;
    }
    else
    {
      word[ii - offset] = word[ii];
    }
  }
}

In going through the string we simply keep track of how many spaces we have, then we know how much to shift the string as we go.

Another possibility is the allocation of a new string and copying over all characters except for spaces. This works well if you must preserve the original string. However, if you are merely editing the string an in place solution is superior.

Posted 02/15/12 @ 5:13pm - By Ross

Dashed Lines!

So I recently have been playing around with shaders on my Android project and with the removal of stippling from the OpenGL I thought that I had found the perfect opportunity to use a shader. With some thoughts in mind I decided to search the interwebs to see if I was thinking along the right lines. Unfortunately there isn’t much out there on OpenGL ES 2.0 yet. So it fell to me to come up with something that would work, and work it does!

The basic premise was pretty simple. Find out the world coordinates of each fragment and then, using that, determine it’s length from the line origin. Then plug that into a cosine function and alternate drawing it based off if the value returned is negative or positive.

The key to the whole thing is sourcePoint being passed in as the origin of the line. It’s also worth noting that I pass in the modelview matrix and multiply it with the vertex to determine where it is in world space. The use of position as a varying variable is also important since it is interpolated based off all the vertices that affect it. This allows for the position variable in the fragment shader to be the actual position of the fragment in world space.

With all this, I determine the distance between those two points and then use the cosine function (modified based off how I want the dashes to look) to decide to draw it or not.

So without further ado, here is my vertex shader:

1
2
3
4
5
6
7
8
9
10
11
12
uniform mat4 u_modelViewProjectionMatrix;
uniform mat4 mv;
attribute vec4 a_position;
attribute vec4 a_color;
varying vec4 v_color;
varying vec4 position;

void main() {
  gl_Position = u_modelViewProjectionMatrix * a_position;
  position = mv * a_position;
  v_color = a_color;
}

and the fragment shader:

1
2
3
4
5
6
7
8
9
10
11
12
precision mediump float;
uniform vec2 sourcePoint;
varying vec4 v_color;
varying vec4 position;

void main() {
  if (cos(0.1*abs(distance(sourcePoint.xy, position.xy))) + 0.5 > 0.0) {
    gl_FragColor = vec4(0,0,0,0);
  } else {
    gl_FragColor = v_color;
  }
}
Posted 02/11/12 @ 1:19am - By Ross

Added some old sites

Went through some of my old files and found a few of the old sites I designed. Unfortunately they aren’t fully functional, but they are the basic designs I came up with so I figured I might as well put them on here to preserve their memory. I wish I had all the sites I’ve made over the years but, hindsight being 50/50 and all, I’m glad I have these few.

Check out my portfolio page if you’re curious what they look like!

Posted 02/08/12 @ 3:31pm - By Ross

GLES2 conversion

The game I’m developing for Android utilizes an open source OpenGL library called AndEngine. I’ve been experimenting with it for about a year now and finally feel as though I’ve got a solid handle on it. But about a month ago I got thrown a curve ball. The core got a huge update as they converted it to support OpenGL ES 2.0. While this is great as it increases it’s functionality, there is a whole new slew of relearning I had to do.

So what changed? First off, the use of a VertexBuffer manager that is now referenced on all drawn objects. This obviously follows from the other big benefit of going to ES 2.0, programmable shaders! I haven’t yet played around with writing my own GLSL programs as I’ve been updating my code to work with the new update, but it’s high on my list to see what it can do. Another nice change is the division of extensions out of the main library. The library itself was starting to get bloated with the inclusion of things like the tmx file format and box2d physics.

The best thing about the conversion is I got a HUGE performance increase after the upgrade. Previously, zooming out all the way on the tmx map would drop frame rates down to the teens. Now it rarely dips below 50. This is credited to big improvements with tmx handling and the A* path generation along with better hardware use.

Another nice side effect is I’ve been going through and rewriting a lot of my code to clean it up. This project started during my junior year in college and there were many mistakes to be found. Not to say it’s now perfect, but it is much better than what it was.

return 0;

}