Fix bug with all units' voxels flipped relative to Y axis

[narical]

Sometimes TileEngine::calculateLineVoxel() successfully creates the trajectory to voxel inside a unit, but returns V_EMPTY instead of V_UNIT. As it turned out, LOFTemps data is stored in memory in "right" direction, with positive X axis from left to right, but (1 << x) in code counts X axis in negative direction, from right to left. LOFTemp becomes effectively inverted from left to right, which moves unit slightly to the left. For terrain code, this effect negated by inverting X axis beforehand, just like that:

int x = 15 - voxel.x%16;
int y = voxel.y%16;

but the unit check does:

int x = voxel.x%16;
int y = voxel.y%16;

Also, in original X-Com it was 0x8000 >> x - just shifting X in positive direction, without double inverting it

Current 2x2 units loftemps loading logic is inverted too, so I've added workaround to not break anything (switching left/right parts).

Inverted units have new center at (7,8) - Volutar has deducted that empirically somehow and "fixed" in
757d674 so I reverted those too.

Images before and after a patch.

[MeridianOXC]

Thank you for the report.
We will look at this and review carefully.
It will probably take a few weeks, please be patient.

[Yankes]

As I see, part of problem is loftempsSet. I talked with Warboy about it and he said that reorder it to fix First Person Voxel View.
Probably best solution will need bit more changes to clean up whole situation.

[narical]

As I see, part of problem is loftempsSet. I talked with Warboy about it and he said that reorder it to fix First Person Voxel View. Probably best solution will need bit more changes to clean up whole situation.

"reorder" means "flip it too"? Now it's in right direction. 1 << X increments X from rigth to left, to counter that we flip terrain, and apply inverted X axis to inverted terrain. My proposal is to change units' in similar manner, don't touch (1<<x) code but keep solution uniform with older terrain code.

The right solution, in my opinion, should be:

• removing X axis invertion altogether both for units and terrain, turning 15 - voxel.x%16 to plain (and intuitive) voxel.x%16
• removing X axis invertion in bits checking, turning (1 << x) to (0x8000 >> x) as was in the original game
• don't touch loftempSet as bits are stored in right (and intuitive) way

[Yankes]

As I see, part of problem is loftempsSet. I talked with Warboy about it and he said that reorder it to fix First Person Voxel View. Probably best solution will need bit more changes to clean up whole situation.

"reorder" means "flip it too"? Now it's in right direction. 1 << X increments X from rigth to left, to counter that we flip terrain, and apply inverted X axis to inverted terrain. My proposal is to change units' in similar manner, don't touch (1<<x) code but keep solution uniform with older terrain code.

I ask SupSuper what version he prefer, he answer that your "hack" is preferred, this will have side effect that
how loftempsSet will work will broken as order with it take templates for body parts will be very unexpected for modder.

Probably for all this 6y everybody copy paste [ 92, 89, 90, 91 ] and call it a day, even its do not had any sense.

The right solution, in my opinion, should be:

* removing X axis invertion altogether both for units and terrain, turning `15 - voxel.x%16` to plain (and intuitive) `voxel.x%16`

* removing X axis invertion in bits checking, turning (1 << x) to (0x8000 >> x) as was in the original game

* don't touch loftempSet as bits are stored in right (and intuitive) way

[narical]

As for parts[] = {1,0,3,2} - I didn't come to a wiser solution, with just a single formula as it was before. But I was tired and sleepy, maybe you guys can do it in a smarter way

upd: and by "the right solution" I mean "pure, but maybe not affordable". That's why my PR is what it is )

[Yankes]

@narical Have you example of case where center (7,8) need to be corrected?

I locally flip only X axes and result look not shifted.

[narical]

@narical Have you example of case where center (7,8) need to be corrected? I locally flip only X axes and result look not shifted.

Shifting occurs in case of 1-tile units, due to flipping them along X axis. In that case, their center point (8,8) shifts to (7,8). For big 2x2 units, loftemps loading was initially made to make correct cylinder with respect to X inversion. So fixing inversion means getting big units "inverted", and moves all 1-tile units 1 voxels to the right where they intended to be.

[Yankes]

toggling between int x = 15 - voxel.x%16; and int x = voxel.x%16; move units voxels around (this one belongs to Secioid).

I think this commit is fine aside of constexpr that is not available before C++11.

[Yankes]

Aside C++02 incomparability change look fine

[narical]

I changed constexpr to const, commited to my branch, and pressed "resolve conversation" here

[MeridianOXC]

This PR was now merged into OXCE too.