1. Updating the segments could be made a bit simpler, so enhancing both efficient and readability:
// updating segments: 1st the dependents in reverse order, then the head
for (var i:int = m_nodes.length - 1; i > 0; --i)
{
m_nodes[i].x = m_nodes[i - 1].x;
m_nodes[i].y = m_nodes[i - 1].y;
}
m_nodes[0].x += m_nodes[0].vx * (100) * dt;
m_nodes[0].y += m_nodes[0].vy * (100) * dt;
2. Your loop following the update of the segments again iterates all segments. This is wrong. It has to be run for the head only (hence no loop needed at all), because only the head is able to initiate a change in movement. You can see that the loop variable i is never used again (with the exception of initializing savedDir which itself is never used again. So remove those lines:
for (var i:int = 0; i < m_nodes.length; i++)
{
var savedDir:int = m_nodes[i].vx;
...
}
If you don't, then collision detection and correction is done as often as segments are available. Together with your delayCounter this yields in more or less arbitrarily looking decisions of direction updates.
3. I've mentioned to use memorized directions (or velocities if you wish). Your code snippet instead operates without a memory, as can be seen here from brick collision handling code:
m_nodes[0].vx = 0;
m_nodes[0].vy = 1;
delayCounter++;
if (delayCounter > 5)
{
delayCounter = 0;
m_nodes[0].vx *= -1;
m_nodes[0].vy = 0;
}
From a principle point of view: You change the movement to (0,1), i.e. downwards, in each pass. In each (!) fifth pass you then change the movement to (0*-1,0) == (0,0)! This is obviously not what you want.
I would try to use said memorized velocity. If you want to defer changing back velocity until after some passes, then can it be done the following way:
At collision detection, set the new downward direction immediately. Further set the next direction memory immediately. Further set a delay counter to e.g. 5 also immediately. Decrement the delay counter each pass through the simulation loop if it is still greater than zero. In that pass where the delay counter becomes 0 (i.e. set from 1 to 0) override the current velocity with the memorized one. You can use m_delayCounter>0 also to avoid repeated collision detection.
Maybe there is also an issue with checking the borders, but I think that can be seen better when the mentioned issues are corrected.
BTW: It would be nice if you could preserve indentation when posting code. I've also the impression that you mix several programming styles; e.g. some non local variables are not prefixed, one is prefixed with an underscore, and some are prefixed with m_ (should probably denote an object member, but is used inside the game loop).
