Polymost mdzoff maphack error for floor-aligned models

Forum: https://forums.duke4.net/index.php?showtopic=11182

Detailed test+example suite: vp026-BuildGameTest.7z

As initially described here, the mdzoff maphack token is processed contrarily by Polymost/Polymer. I've come to the conclusion that Polymer is right.

Devsplaining: If you use positive values for both pitch/mdzoff to move a normal or wall-aligned sprite/model, it will move forwards. A floor-aligned sprite is displayed like fallen over backwards. Moving the model forwards should now mean to lift it up from the ground (from the player's point of view). The md[x|y|z]off tokens were introduced for Polymost in r570-0788a646 / svn573. (To get comparable screenshots, four missing break commands need to be added - see r602-42f5eb95 / svn605.) Right from the start, Polymost needs one of pitch/mdzoff to be negative in order to lift up a floor-aligned model. Otherwise it gets stuck deeper into the ground. Since the pitch parameter is processed correctly (try big values like 256), mdzoff must be the one handled wrongly. The new code in engine.c has no hint why that is, because the actual handling takes place in the somewhat older mdsprite.c, where I found no hint either. Processing pitch/roll/md[x|y|z]off was added to Polymer at r1372-5580fa84 / svn1375. Moving forward/lifting up a floor-aligned sprite works as expected. The new code in polymer.c provides no help in figuring out why Polymost is wrong, unfortunately. The patch attached will, while loading the *mhk, invert the mdzoff value for floor-aligned sprites when Polymost is used. Changing the renderer while playing will therefore make the issue visible (again). Instead of trying to figure out why Polymost behaves differently, I have simply patched mhk.cpp instead. Changing the actual behaviour of Polymost would break stuff elsewhere with an expected probability of 100%.