Posts Tagged ‘polar coordinates’

Day 1.5 recap

Posted by (twitter: @Eliot_L)
Sunday, April 22nd, 2012 5:04 am

We’re currently 35 hours in and have some decent progress to show. I got a full player movement and collision system working using arcs to define platforms and walls. You can now run and jump around the level, and the ‘camera’ follows you.

Here’s a screenshot of what the game looks like now, complete with debugging info on collision arcs and background tiles:

I figured out a workaround to the issue I posted about earlier thanks to the help of some twitter buddies. Thank you also to everyone in the LD community who chimed in. I am splitting arcs that cross the polar axis into two arcs, and everything works fine so far. You can see the seam of the axis, i.e. 0 degrees, and the arcs that cross it have been split in twain.

I thought you all might be interested to see how we made this level and translated it into code, so here is a screenshot of that process in action:

Daniel designed a level on paper using a compass, and scanned it in so he could paint it in Photoshop. He then sent me the image, which I measured using a handy screen protractor (which doesn’t have a setting to measure angles clockwise, WTF!) and entered into the giant blob of setup code that is our one and only level. I worked out a function that adds a ring segment based on its start and stop angles and ‘valence’, i.e. what level it’s on. It figures out the maximum and minimum radius of each arc segment based on the even spacing that Daniel set up in his design. So that has sped up the process quite a bit. You could say that without it, the process of making levels would be too protracted. Ba-dum psshhhh.

Now, for some technical rambling…

I’ve been having some pretty disheartening performance issues in Processing.  It’s a prototyping tool that excels at real-time procedural graphics – it doesn’t do so well when you expect it to be blitting bitmaps to the screen at 30 FPS. As soon as I threw in some background art, the framerate dropped significantly. I tried reducing the size of the art and scaling it up in-engine but the exact same issue persisted. In a hail-mary attempt, I rolled back from the Processing 2 beta to Processing 1.5.1 so I could try the now-deprecated P2D renderer. And what do you know, it performed way better than the Processing 2 2D renderer, Java2D!

Unfortunately, since the level is laid out in polar coordinates, it’s a pain in the ass to line up raster graphics since they are all rectangles. Also, my jam partner Daniel requested that we use raster graphics so he can paint them in Photoshop.

What this amounts to, for a 1024 x 768 game like ours, is a level that is 6144 x 6144. And we can’t build platforms out of standard square tiles since the entire level is curved. So we split the image up into 1024 x 1024 slices and tiled them in-engine in the hopes that we might save on performance somewhat, since I can cull tiles if they are out of the camera’s view. This doesn’t seem to be helping a ton.

Also, the image loading needs some tuning. I was loading everything at runtime but the load time for the game was awful that way. So I switched to asynchronous loading on an as-needed basis, but now I’ve created a thundering herd, each thread requesting a 1024×1024 image from disk at once! And there are 18 of these during launch to load the images at and around the player. I think I’ll need to throw these image load requests into some sort of prioritized queue so I can throttle them. I also need to make the game update steps independent of framerate.

So overall, perf is in pretty bad shape now, and I’m apprehensive about what things will be like once we start adding animated sprites for the player and enemies. Also, it appears as if the P2D renderer may have a really bad memory leak, my swap file grew to 8 GB when I was testing the game! Bleaahhh…

I’d like to learn openFrameworks for my next game, maybe I can optimize the rendering better. There remains the option of me trying to implement my own renderer on top of Processing’s P3D (OpenGL) renderer but god knows if that will help at all.

There’s a ton of stuff to do tomorrow. i.e. turn this movement/art prototype into a game!

Good luck, and rest well, fellow jammers!

Looking for advice on arc/point collision detection

Posted by (twitter: @Eliot_L)
Saturday, April 21st, 2012 11:29 pm

I’d appreciate some advice on whether my collison system can be salvaged or if I need to rewrite it.
My game is using polar coordinates and I am defining sections of arcs like so for the level geometry:


Right now I wrote checks to see if a point at polar coordinate (r, theta) is inside the region between the greater and lesser arc that makes up a solid object, like so:

class Arc {
  //Not a true arc, more of a segment of one or a "Block Arc", but it's much easier to type.
  float startAngle;
  float stopAngle;
  float maxRadius;
  float minRadius;
  //...
  boolean collidesWith(PolarCoord point) {
    return !( startAngle > point.t ||
              stopAngle < point.t ||
              minRadius > point.r ||
              maxRadius < point.r );
  }
  //...
}

(Full class is here.)

It appears my math doesn’t work out for arcs on certain intervals. Previously I had encountered issues with this code not working when a radian was less than 0 or greater than 2*pi, so I wrapped my radians between 0 and 2*pi which fixed it. But I need to define some arcs that start around, say, the radian equivalent of ~270 degrees and end at ~45 degrees, making the shape of the letter C and crossing the 0 degrees mark. This kind of arc breaks my collision check above.

So I’m thinking, I can either fix my math for the check somehow, or abandon this method completely. Unfortunately I can’t find many resources on how to do this type of collision check properly. I couldn’t even find what these arc segment shapes are actually called.

In addition, I’m seeing occasional tunneling issues and would like to switch to doing an arc segment + line segment test for continuous collision instead of just an arc/point test.

The alternative I thought of was to define my arcs based on a vector at the center and an angle, and use the dot product to the player to do my collison checks, similar to the FOV check described here.

But it will take time to do that and I’d rather salvage this code if possible. If anyone has any advice, please let me know.

Off to a good start

Posted by (twitter: @Eliot_L)
Saturday, April 21st, 2012 1:49 am

My first Ludum Dare Compo was the previous one, LD #22. I had a good time and I learned a ton, and have used what I learned to make several physics-based games in Processing for various jams afterwards. However, I felt that my LD22 game suffered due to my poor art skills, so I decided I wanted to team up for the jam this time with a talented artist, for maximum awesome.

I’m working on a jam entry for LD #23 with my friend Daniel. He had an idea for a metroidvania where you traverse a rather small planetoid, where the curvature is actually visible.

We’re cutting the metroidvania part and trying to make a 2d action platformer set on a very small planet. The idea is that everything conforms to the planet’s curves, even your shots.

Here are some concept sketches of the planet and possible level designs that Daniel drew, along with some of my own drawings explaining how I will set up the collision volumes (using 2D arcs) and orient sprites.

I was pleased with how much progress I made on coding tonight, especially since I have never written anything like this before. I am using a generic template I made for writing games in Processing that I am calling QEngine. I will be publishing this game on the TinyWorld branch of the QEngine git repo.

As you can see from this screenshot, I have set up a class to define an arc section in code, and draw it for debugging purposes. These will be used as collision volumes, and I will draw a sprite in the same location. I couldn’t find what the real name of this sort of shape is, it’s a sort of wide arc, or arc with a circle segment removed from it. Microsoft calls them “block arcs” in their software but I couldn’t find any references to that being a widely used term.

I vaguely remembered reading about polar coordinates, and after looking them up again concluded that they would be a perfect way to store the position of objects in this game. It should be simple to move the player around and test for collision with arc segments if everything is stored in polar coordinates. And I even found some easy trig to convert to cartesian coordinates when needed (i.e. for drawing.) Here’s a screenshot of collision in action – the player (the white dot) is inside the upper left arc segment, which is why it’s red:

To move the player, I just add or subtract from his radial coordinate (vertical position) or angular coordinate (horizontal position). I love that math is providing such an elegant solution to what I thought might be  a pretty hairy problem! It’s times like this I’m glad I’m writing the game mostly from scratch in Processing since I have the flexibility to do stuff like this with ease.

There is one bug that I know of currently, I’m not accounting for the fact that there are multiple representations of a single angle in radians, so if you rotate the player past 360 degrees, the collision basically stops working. But I think this should be fixable if I can find a function to normalize the angle or whatever, if not I can always force it to wrap around with some custom logic.

Yay math! Yay game jams!

Here’s a hopeful sign-off for a productive day tomorrow. Good luck everyone!

[cache: storing page]