The good first: it turns out that although Microsoft says Windows 10 Home Edition doesn't support Hyper-Visor, there are still ways to install it. They just hide the Hyper-V tools unless you buy Professional Edition. Luckily (please don't read this and take revenge on me Microsoft), the Android virtual machines Visual Studio imports from Android Studio can utilize Hyper-V hardware acceleration even without those dashboard tools. Running an Android VM with hyper-v acceleration boosted my framerate from ~22 to ~52 and gave me a much better sense of how an actual Android device would perform with the Mono runtime with this app.

the bad: I've been chasing this bug for weeks. This is frustrating because the windows of time I have to do this chasing with are so limited. Maybe if I had just had 1 solid week or even a couple of days to focus on this it would be done already. It's been educational. I'll just say that a complex feature like collision detection is going to reveal all your hidden downstream problems, and I had quite a lot of them. Syntax errors will get caught by the compiler, those are easy to figure out. Logic errors though.. that's your problem. Most of them should (and were in this case) caught during test driven development by vigorous unit testing. In unit testing for example, I assumed a correctly instantiated Actor where the Game Logic character class and the Graphics sprite class had the same pixel height and width. It turned out that in the actual app because the Sprite is created last I'd forgotten to go back and update the GLCharacter, so at runtime it turned out I was checking whether a 0x0 pixel rectangle was colliding with other rectangles. Sometimes this still caught, sometimes it didn't. Until I put in a breakpoint and went through a complete iteration of the collision_resolver I didn't understand why.

Next I had my doubts about the algorithms. I discovered that for example, the LINQ query here which checks for obstacles in the +X direction of travel sometimes failed to detect anything. With the uninitialized rectangle it missed everything. But initialized, it was colliding with the floor - even with only Y_Overlap as the enabler.

var contextQuery = from obstacle in obstacles_
                   where obstacle.IsRightOf(actor) && obstacle.Y_Overlap(actor)
                   orderby actor.Horizontal_Distance_Right(obstacle) ascending
                   select obstacle;

if(contextQuery.Any())
{
    var nearest = contextQeury.First();
    
    if(actor.Intersects(nearest))
    {
        actor.ObstructedRight = true;
        actor.Stop_X_Axis_Motion();
    }
}  

Inserting another breakpoint into the loop of the query above, I discovered that the Game Logic character was out of position and was actually overlapping the floor. Huh? Weirder still - the sprite was now hovering ~64 pixels above where it should be. I had (still have) a coordinate translation problem. Even stranger - no matter what I did I could not manually correct it. I was beginning to despair until I followed the call stack all the way to the top and found the culprit: the SizeAllocated event - indicating that the screen has either been re-sized or rotated. Way up in the app logic this made calls to GamePageViewModel, which called the GameScreen's.GetScreenInfo() function, and tries to move all the on-screen sprites to where they should be. THAT placement is what was over-writing my manual fixes further down in the Game Logic layer. And to compound it, it was moving them into the wrong place.

I was happy to find that high level over-write, and happier to eliminate it. The GameScreen after all, should handle that logic internally. The reason I wasn't doing it internally is that once a Sprite is added to GameScreen it no longer tracks the game logic coordinates of whatever entity that sprite belongs to. Those are updated by the entities themselves at runtime. All GameScreen wants to know is what to draw and where to draw it. Without the Game Logic coordinates I don't think I can re-arrange Skia coordinates. So my plan going forward is:

1 - write a function where the GameScreen can translate any given SkiaSharp graphics coordinate back into a Game Logic coordinate based on the current context. This is tricky because the game logic coordinates of the screen are going to scroll to follow player1 while the skia coordinates of the screen remain constant.

2 - convert from game logic coordinates back into new skia coordinates, as we do when first adding the sprite.

This should leave every sprite where it should be and hopefully put this display issue to bed. I've opened a new Git branch just to address this fix, then I'll get back to the collision branch when it's done.