Hex Messages when Reverse Engineering

One of the things I did in 2018 was a bit of reverse engineering, the company I worked for had bought a bunch of older hardware which had to be reused, the trouble being?  They had bought the hardware NOT the software.

It look a lot of USB sniffing and signal trapping but eventually I had the device handshake and could see it spew me messages, from these I saw the header format was pretty simple just a pair of bytes and then a length byte followed by whatever the message was.

Interacting with the device stimulated it into sending more messages, so we could start to map physical actions to these USB packet ghosts, eventually we had all the ones we could just prod out of the unit, so it was time to work on more advanced interactions and actually try to tell the device to carry out actions for us.

This immediately met with problems, you see the messages coming out had a counter in the footer, it turned out that if you sent a message you had to use the next number... so receiving messages 1, 2, 3 and then you send 4 and receive 5.  Keeping this in sync was a little bit of black magic, but it soon made sense the unit was serial in operation, you could only talk when it was listening, and it only listened after certain choice messages it sent to you.

This all made sense.... What didn't make sense was a four byte message I saw every few minutes, this frustrated me no end....

10111110111011111101111010101101

I converted these to two into an integer... 3203391149... It didn't ring any bells, but I persisted and was rewarded when I switched it into hex...

BEEF DEAD

This is a common message left in hex in code, as a joke, but it was also apt, the board was not going to talk until a full handshake was given again and the packet series stream started over to order things.  Cute.

I've found other hex strings, but this one was the first on this particular board

That Time I Found a Pub

I don't mean just I was out in the country having a stroll and happened upon watering hole.

No, I was in my garden, and I found a pub.  Specifically the pub's kitchen floor.  The pub in question was the Miners Arms at Selston, obviously long since demolished, but they'd not broken the ground concrete up, just dug the nice neighbour diagonal's garage hole into it and so about seven inches down under my lawn was the white tile floor.

This made my lawn growing efforts a bit of a pest, they kept drying out.

Tree's also rooted along the tile level and it was impossible to landscape effectively.

The ground itself, the natural ground was very clay riddled, clay deposited during the last ice age as part of Alma Hill.  But still a challenge to dig out.

Not as challenging as the neighbours, but then, I've mentioned their mania before.

Music : A 40 Something's Service Announcement

If you hear someone playing Rage Against the Machine's "Wake Up", but only know it as "That song at the end of the Matrix...

Or you spot a 40 something co-worker in their Nirvana T-shirt and comment "I didn't think you'd know who they were"...

Or you hear a bit of Beastie Boys' Sabotage peeping out said coworkers headphones... You do not ask "Is that the song from <insert film here>"....

My Home Game Engine - Motion Decay (Physics) Bug

A few of you may have noted I've been writing my own graphics engine at home, this has fast become my own home game engine; which is more or less just a play ground for me play about with.

And over the weekend I've started to flesh out the physics engine, beginning with a physically reactive camera.  I want to make this thing tilt and shake and move like it's organic, not on the end of your keyboard or mouse.

The motif is going well.

I designed a head for many edge cases I expected, one of them being floating point in accuracy and so I built two things into the movement, first a dead-zone, so zero isn't the ONLY value which doesn't move the camera, instead an area of 0.0004 around the camera forms a null - don't move - zone for all my motion calculations.

And the second was the force of friction or wind resistance, this is just called "Decay" in my engine, you decay from moving to  no longer moving.  Because wind, water or surface friction are going to come into play at different times and from different directions on each object.

Anyway, do work out the motion which needs applying to any object I build a vector of motion actions, these themselves are stored in a set of efficient constexpr static arrays per object type; for not I have so few object types this is fine, it leads to faster code (one day, if I have more than ten moving object types I may need to revisit this.

Alas, this smartness immediately bit me in the arse... And I just spent nearly half an hour pawing over the wrong piece of code to figure out why when switching to an object known to be at rest (0, 0, 0) with no actions on it... it'd slowly jiggle backwards at a very slow rate.

I checked my maths, my direction vectors, my initialization of the actual speed of the object, everything checked out.  I made sure I was giving no inputs, so I wasn't landing in the accelerate or decelerate motion actions.

So I was properly confused, I took a moment and I re-read the code I'd done yesterday (oh the difference a day makes) and suddenly I realized I had two kinds of decay... if you're moving forward you slow down... and if you're moving backwards you also slow down... both heading to zero, or at least the 0.0004 null zone.

Other objects were not moving, just this one particular type... and having a quick squizz, sure enough the acceleration and deceleration decay were BOTH being applied, even at rest this object would jump to a speed and start to decay, this would then swing it below -0.0004 in the null zone and the deceleration decay would kick in... and the deceleration was MORE than the acceleration so then the object was trying to decelerate a little but more each third frame... zero to backwards to null zone to backwards to nullzone... on and on, tiny increments.

This was a flat out bug, the decay should have only been applied to make the object come to, but not beyond the nullzone.

However, I was still perplexed how the forward decay was being applied, sure enough it is, in the above call to "GetMotionActions" we can see it's both ForwardSpeedDecay and BackwardSpeedDecay are "valid" motion actions for objects receiving no input.

And they'd been doing this all the time, every frame... the specialty of this one particular object?  Just the numbers, the profile for motion, specifically the braking, was a larger number taking it beyond nullzone.  And this is multipled by delta time for the frame... all following frames are small, short, but the first frame?... or a frame after a break point... HUGE....

In short I made a bunch of mistakes, but I learned, and I enjoyed myself.  This is perhaps the key thing when trying something new.

I also have a healthy appreciation for just taking a physics engine off of the shelf having done some of this ground work - and I'm literally just playing.