The rerelease moved all pmove logic to the game (and cgame), so there shouldn't be a need for a pmove function in the engine itself. Of course, Q2repro contains the "game3 proxy" for non-rerelease game libraries.
However, there are still two pmove implementations: the "vanilla" one, used when providing pmove functionality for the game, and one working on the rerelease structs, for the compatibility cgame.
Wouldn't it be better to only have a single implementation used in all cases, and specifically, the "vanilla" one for maximum compatibility?
This is what this PR does: change the compatibility cgame to use the same pmove that's provided for "vanilla" games, by performing a "good enough" conversion between structs. The rerelease struct pmove becomes redundant and can be removed.
The rerelease moved all pmove logic to the game (and cgame), so there shouldn't be a need for a pmove function in the engine itself. Of course, Q2repro contains the "game3 proxy" for non-rerelease game libraries.
However, there are still two pmove implementations: the "vanilla" one, used when providing pmove functionality for the game, and one working on the rerelease structs, for the compatibility cgame. Wouldn't it be better to only have a single implementation used in all cases, and specifically, the "vanilla" one for maximum compatibility?
This is what this PR does: change the compatibility cgame to use the same pmove that's provided for "vanilla" games, by performing a "good enough" conversion between structs. The rerelease struct pmove becomes redundant and can be removed.