A blog about my rantings, including Games, Game Development, Gaming, Consoles, PC Gaming, Role Playing Games, People, Gaming tips & cheats, Game Programming and a plethora of other stuff.
Monday, 7 August 2023
Amber Valley Planning aren't very good
Wednesday, 25 January 2023
No Rack, but definitely an IT mistake
Sunday, 1 August 2021
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.
Thursday, 4 February 2021
The most insidious file on Windows....
The most insidious file on Windows....
Microsoft.DataWarehouse.Interfaces.resources.dll?
This particular file lives in my
D:\Program Files\WindowsApps\Microsoft.Office.Desktop.Excel_16050.11029.20108.0_x86__8wekyb3d8bbwe\Office16\ADDINS\PowerPivot Excel Add-in\sk
folder.... The key feature of that hideous path is that it's in my D drive... this is my second drive and you'd be right to ask why it has a windows installation on it?
This installation of windows has been taking up like 15GB or more of Space for over two years to it was time to nuke it. The problem? You can't just remove windows trusted installer files.
My way around this is to go into the properties, into advanced, set the owner user and god for that file to be me and remove the other windows junk user groups and such, and make sure everything is inherited down the line....
And I did this, removed windows, program files and windows and program data.... all except for this one file.
Which is totally insidious.
It won't disappear despite my being that very user/owner and even having used "runas" to launch explorer and cmd as myself for 100% certain.
The security settings can't be set....
Friday, 4 September 2020
Great Rack Mount Mistakes #7
Thursday, 23 July 2020
Drop Ships Dilemma
Friday, 5 June 2020
Worst Idea in Development Ever
Thursday, 4 June 2020
When the Manager Went Fishing
Friday, 15 May 2020
Goodbye Childhood Confidence
Sunday, 12 May 2019
Development Job : Interview Questions?
Saturday, 23 February 2019
Its all a question of metier
Sunday, 10 February 2019
The Lost Router
--------
Update, the wife came with to go through EVERY box in the garage with me... Guess what... No, no... She didn't come up smug (I knew you'd think she would)... The thing is still LOST... GONE LOST VANEEEEEEEESHED.... Gah.
I think I have to go look at the in-laws.







