Raycast

[faha223]

rewrote the raycast selection logic to work correctly with entities, diagonal walls, and raised platforms as well as to work in 3D with floors and ceilings. The calculation for getting the rayDirection in the GameWorldPanel seems to be broken in Modern UI mode if you look up or down, but it's pretty close. The selection works pretty much flawlessly in classic mode.

There are some functions in MathUtils that make some functions in the Collisions PR redundant, but we can combine them later.

[faha223]

Travis CI broke for Linux and OS X because of the use of FLT_MAX and DBL_MAX in a few places where I should have used std::numeric_limits::max()

[afritz1]

Just going through and doing some iterative changes. Will try to get more done tomorrow.

[afritz1]

Sorry for the confusion, but I realized we probably want to move the ray generation from handleClickInWorld() to a renderer function similar to getFlatTexel(), like

static Double3 SoftwareRenderer::screenPointToRay(double xPercent, double yPercent, const Camera &camera, const Options &options);

I want handleClickInWorld() to ideally not worry any about renderer values like TALL_PIXEL_RATIO. It would call game.getRenderer().screenPointToRay(...). We can revert the classic/modern branch that I suggested, so maybe passing const Options& to the screen point function might not be necessary.

[afritz1]

Making progress here and there. Some things I wanted to note (not exhaustive):

• Can't select candle on raised platform in final level of Imperial palace (F2 coordinate 42, 25)
• Can't select hanging chains if they're too high in Imperial palace
• Probably don't need distance limit on ray cast. Only if it goes outside the grid or hits an opaque face of a voxel (although if the ray goes outside the grid then you can't select the upper half of trees in outdoor dungeons like the Elden Grove).
• Entities touching the same voxel should be sorted by Z distance to the camera

I'll get to some more rigorous testing of this in a while.

If you want to better test the exact sprite selection areas, add this at line 6731 in the software renderer (the else case of the texel.a > 0.0 condition):

else
{
    frame.colorBuffer[index] = 0x00FF0000;
    frame.depthBuffer[index] = depth;
}

[afritz1]

It's not perfect but it's good enough for testing, and I want to move onto other tasks. I'll make another issue for improving it in the future.