Friday, February 27, 2015

Innovation is Saying No to 1000 Things

Having just read this over at Daring Fireball I was reminded of this video shown by Apple at WWDC in 2013:


It made me think about the oft-debated and ongoing argument about why some companies produce as many varied products and Apple doesn't, while Apple is roundly criticised at every turn for not including every feature under the sun while still making 90% of the market's profit.

Companies like Samsung see value in producing as many variations of a product to appeal to as many customers as possible. The failure in that strategy is that it requires the majority of those variations to not be attractive to most customers. The reason that strategy can be put into action at all is because those numerous variations can be produced at low cost, which itself incurs a penalty of low quality.

Wednesday, February 25, 2015

Force VMWare Fusion Windows 7.1 on Retina Mac to Reasonable Resolution

Running Windows 7.1 under VM Ware Fusion on a Retina MacBook Pro will cause each restart (whether shutdown or put into sleep mode) to start back up in the highest resolution available. Windows does not cater for this the same way that Mac OS does and the upshot is that everything on your screen will be tiny.

To force Windows into a reasonable resolution the VMWare VMX config file for the instance needs to be modified to set the max width and height. Finding the config file is the first step. Adding three lines is the second.

The long way is to follow the instructions on these two pages in order:
The short version of those is to shutdown your VM Windows (not suspend) and open the following menu:
  • Window -> Virtual Machine Library ->
  • Then, while holding alt / option, open the menu over the Windows instance in the left menu
  • "Show in Finder" will change to "Open Config in File Editor"
Then, in your text editor, paste these three lines to the bottom of the config file and save it over the original (make a backup):
svga.autodetect = "FALSE"
svga.maxWidth = 1920
svga.maxHeight = 1200
This will set the default resolution to 1920x1200. Choose whichever is best for you.

Thursday, January 29, 2015

Sample Code

Bunch of sample codes I've written for use in lua on the Corona SDK, utility and math libraries.
Some of these may appear in both lists due to being a library within a demo.

I have now added a third list of other people's libraries as they are proving quite useful.



Sample/Demo code:


Wednesday, October 29, 2014

Payment Security

There has been a lot of talk in the tech and regular media recently about digital security so I just wanted to write a word about some of these issues by passing on some links to read.

Firstly, a note about mobile payments in shops:

The gist here is that many shops are doing whatever they can to deter people from using Apple Pay over other solutions because Apple Pay stops the shops and related merchants from accessing personal information about the people shopping with them.

If you’re wondering why this would be a bad thing, here is an article about the type of information that shops are trying to collect about every single person who walks through their doors:

If you didn’t read that (TL; DR), it says that what Target (huge chain in America) is trying to do is work out if you’re pregnant even if you don’t want them to know from your spending habits.

Yes, this stuff is possible. And we are at the start of an enormous digital path. Many people thought that contactless payments would not catch on because of the insecurity – if you have a mobile register you can walk past someone’s pocket and charge them up to £20 without them knowing (this has happened) – however we now have contactless everywhere because of the convenience.

We have actually been on this path for a while – contactless was introduced back in 1997. Consumers have been wanting a “pay by phone” method for a long time (I even pay for parking using an iPhone app) simply for the convenience.

What we have gained in convenience we have lost in security. Be careful out there. Choose what you pay with and who you pay with care.

Further reading: 

Tuesday, October 14, 2014

Thursday, August 28, 2014

Fighting The Physics Engine

I've seen way too many posts on the forums where a developer asks about the best way to control the absolute position of a dynamic physics object when using Box2D. This lead me to thinking that there should be a catch-all place for someone to read the right answer and as I've answered these questions on the forums many times, I'll start logging them here. Should have done this a long time ago.

Here is a really great blog post on the subject of common physics problems, though I'll try to tackle even trickier issues below:
  • How do I control the position of an object in Box2D?



    Dynamic objects in the Box2D physics engine are under the constant control (at least, while not asleep) of the physics engine. If you attempt to change their .x or .y values and move them with your own code you are trying to force the engine to accept a different world position for it's own, managed objects. Because of this change, sometimes it's own internal values will effectively break during computation and the result is that, in Corona SDK, the display objects will be lost from their physics object.
    In short, forcing the physics engine to accept different positions for it's bodies is fighting the engine for control and it will break.


    The way to control the position of physics bodies is to use the engine to position the them itself. This can be done by attaching a touch joint to the body and controlling the position of the joint and thus the position of the body.
    It has been mentioned that static bodies can be used to absolutely position dynamic bodies, via a weld joint, but this is similarly inadvisable due to the the reasons above.
  • How can I group the physics bodies like I do with display objects?


    Many developers want to group many physics objects into a single display group so that they can move them all together. The physics engine uses the top level display group as the starting 0,0 point for all physics bodies, so trying to move a display object's parent group will not work, because 0,0 never moves.

    Grouping the display objects which have physics bodies attached into display groups is not a problem. You just can't move the parent groups at all. This is usually fine because moving a physics body should be done using a touch joint, which will cause any bodies attached by physics joints to move with it.
  • When I reset my physics scene the objects don't stop moving or reset wrong!


    Description:Some games provide a sandbox environment which allows the player to edit a scene. Whenever the player chooses they can hit a run button and test their scene. They physics objects will move around and then reset back to the player's edited positions, rather than continuing to roll around uncontrolled. Some developers find that resetting their physics scene is a problem because the physics bodies do not want to stay where they should.

    This problem is similar to the first problem discussed, but there is also one confusing factor: once physics bodies have been allowed to move, by collision impact, gravity or some other force, they will have built up energy and while energy can be mostly dissipated there will be momentum and other internal, Box2D values which cannot. The best way to avoid objects moving off on their own is to simply destroy them and rebuild. Use a non-physics body display object during the editing and create the physics bodies only when the player hits Run. Sometimes this is not possible. The solution here is also similar to the first problem- simply weld your objects in place either by creating a weld joint between the body and a static object or by using a touch joint. The touch joint is a great solution because you can have each body listening, on it's own free will, to the Runtime (or even the current scene, if you're using Composer) for freeze/reset and unfreeze/play events. When the freeze/reset event is received the physics on the body is turned off, the display object is moved absolutely (using .x and .y positioning) and the body turned back on. A touch joint is then added and used to keep the object in place. object.isFixedRotation=true can even be used to stop rotation. When the unfreeze/play event is received the touch joint is removed (and isFixedRotation=false) and the body runs free again.
  • Why do stacks of blocks keep falling down?


    In Angry Birds, and so many clones, objects are stacked - sometimes precariously - on top of each other and need to be knocked over. Because all objects in the Box2D world contain inertia, density and various energies, building a tower of even simple squares can be perilous. For now clear reason they will shudder and push each other out the way, collapsing the tower.

    The reason the blocks generate this energy is that they have nowhere to dissipate it other than the blocks around them. Those blocks then acquire that energy and need to dissipate it again, back into the blocks surrounding them. The pattern continues until the blocks fall onto something which does not return any energy or they simply drop off the screen. There are two things at play here and the solution, again, is similar to our first problem's solution. Firstly, all objects have energies that may (depending on your particular scenario) need to be controlled (these are the afore-mentioned inertia, density and gravity.) Secondly, holding objects down is usually a good way to make sure they don't wander off on their own. However, here we want the blocks to be able to fall down, just not when they feel like it. One popular solution is to weld them in place or even set their object.bodyType to "static". Static objects do not move and they absorb all energies applied to them. This can be a problem because, as anyone attempting to build a Box2D-Corona rag doll demo has discovered, static objects will absorb all your motion and tear otherwise reliable physics joints apart. The other solution is to set their linear and angular damping values to something small. Usually, this will help the bodies absorb any excess energy, rather than passing it to their neighbours. A compromise on the "nail them down" solution is to simply hold them in place with a touch joint (so useful!) until a pre-collision event occurs, then remove the joint. The best advice is simple: Never use static bodies if you can possibly avoid it. This will be explained in the next problem...
  • Where is this object going to go?


    Angry Birds, again, has another interesting element where the flight path of one of the moody projectiles is shown before the launch takes place. This is a common feature in many games but is a very difficult thing to calculate. This difficulty comes not because the mathematics for calculating trajectory is difficult (see: but because the Box 2D physics engine is a real world simulation. This means that it does not guarantee the same result every time. In fact, it pretty much guarantees at least a slightly different result every time. It is also because other environmental factors, such as the weight (simplified: area*density) of your physics body, need to be taken into account.

    As you might have guessed, there are many ways to solve this problem. The first is simply to control the path of travel with a touch joint (see the first problem for why absolute positioning is not a good idea) after calculating it using the HyperPhysics link above. The second is to actually calculate the path for real. A great resource here is the iForce2D site: which deals with Box2D physics in many scenarios, though mostly with C++. However, the solutions are easy to translate. The third solution is to throw an invisible copy of our physics body which is created with collision masks such that it will not collide with anything in it's path. Allow the body to travel for a given amount of time or distance and plot it's travelled course with non-physics graphics objects. This gives the benefit of a nice, realistically animated series of dots or lines showing not just the path but the time taken, as well.
  • Textured surfaces are impossible!


    Imagine a plan (top-down) view of a race track. The race cars rush round and need to hit different road surface types. We're talking mud, ice, grass, etc. Of course, when one object hits another, with Box 2D, it will simply bounce off, so we can't layer physics objects on top of each other.

    Box 2D does give us sensors with the use of body.isSensor=true and this property can be set not just at creation time, but at any time. For this problem, we'll just set it at creation time. Taking just thick, gooey mud as the problem, let's say we've got a PNG of mud with a nice transparent background. Use the graphics.newOutline() function to get the physics outline of the mud. Then load the image as normal and apply the physics outline as per the documentation. Set the physics body to be a sensor and add a collision listener. When a car hits the mud it will not bounce off the mud but simply fire a collision event. You can now use one of many methods to apply the muddy drag effect to the car. We'll go with: Simply increase the linearDamping value of the car by a tiny amount to see the car slow down. You'll have to play around with the values to get the right effect, but if the mud needs to be layered on top of more mud you can have each muddy layer increase the amount of drag and make the ground even worse to drive through.