NoshBar's Dumping Ground





When testing an exporter, you always see interesting things...
I simply liked the resulting shape.
(click the image for a larger version)

Modelled in Blender
Rendered in Indigo

[ view entry ] ( 195 views ) permalink print article

It might not seem like I did much, for this weeks update, but loads under the hood has changed.



  • I learnt that the size of the Box2D world has an enormous affect on the speed of the simulation, so I've simply divided by 10 to keep the world smaller.
  • As such, I've got to re-tweak the physics of the bridge elements, as the bridge is now waaay too elasticy.
  • I couldn't for the life of me figure out how to make the parallax zoom in on the middle focal point of the screen using Cocos2D's Parallax Node, so I simply implemented parallax scrolling myself.
  • I started just changing the Menu text to "Play Game", but got carried away and made a lame intro screen.


[ view entry ] ( 261 views ) permalink print article

Just minor tests this week:

  • test menu system, want to make it into a nice expanding sun, and highlight the ray that's selected
  • test pin moving and editing "widget"

The only sensible way to create bridge segments is for the user to put a finger down on the start joint, and drag to the desired position, then let go.

The only problem is, you can't possibly accurately position the pin underneath your finger.
So I figure: create it inaccurately, and drag it with the widget afterwards (which should hopefully give a clear view of the pin).

I'm also mighty jealous of Moto X Mayhem's graphics and parallax scrolling.



[ view entry ] ( 240 views ) permalink print article

Summary: this week I used Tiled to create a map for a parallax game level in Cocos2D, processing it with a custom written tool to calculate the Box2D collision area for the map automatically.




  • Tiled is a nice and portable tile map editor
  • There is a plugin here to export the level data to a TGA file that Cocos2D expects.
  • The plugin expects 3 layers, "tile", "bkgr" and "code"
  • I use the tile layer to store graphical tiles
  • Any tile in the code level is used to signify the tile it covers is collidable
  • The plugin exports "tile" data to the Red channel
  • The plugin exports "code" data to the Blue channel
  • Cocos2D only uses the Red channel
  • I wrote a poorly coded tool to calculate
    1) from left to right, the first tile in each column that is collidable, and stores that row value as the first Green value in the row
    2) the first collidable pixel on the left in the selected tile, which is stored in the second Green value in the row
    3) the first collidable pixel on the right in the selected tile, which is stored in the third Green value in the row
  • In the app, a static edge object is created from vertices calculated from TileYOffset + TileYOffet information
    (or at least it would add static edges, if they weren't acting funky... so instead, I create a 4 sided poly object per column for now)
  • For kicks, I added some parallax layers, the sky as the background, the level as the focal point, and the sea as the forefront layer.

Get the source here.

[ view entry ] ( 191 views ) permalink print article

In order to finally start iPhone development, I decided to start with something I would enjoy, required the least amount of Objective C fiddling, and had a graphics API I was familiar with, OpenGL.

Enter left, the bridge building game. The physics are beyond my capabilities, so I figured Box2D would be just what I wanted.
Turns out, you still need to have a brain, nuts.

When I first started, I used the Box2D bridge testbed as a starting point, where it creates bridge segments, connected by revolution joints.
This works fine if all you're doing is creating a single layer of bridge segments to go from one side to the next.
The problem comes when you try add support structures, as you cannot add 3 bodies to one joint, as seen below.



Mnem was kind enough to suggest swapping the roles, replacing the bodies with distance joints, and the joints with bodies to hold them together.
This works great, as you can use the distance or reaction force of the joint to snap the joint when the force is too great.
The problem with this, is that you can't collide with a joint, so any vehicle travelling over the bridge would just fall through the structure segments.



My latest thinking involves a mixture of distance and revolution joints, and bodies acting in different roles.
So for the main structure segments, that the vehicle will travel over, you have a pin(body), connected to a joint(revolution), which is in turn connected to a structure segment, and/or a support joint(distance).
This means that the bridge is still flexible, can still be supported, and can still break, without uneven tension across its structure.



[ view entry ] ( 429 views ) permalink print article

<<First <Newer | Older> Last>>