Inky-Inky
commented
3 years ago Maybe a simpler (and more generic) way would simply be exposing atan2 as a new builtin function available in HexenC, just the way cos, sin and sqrt are exposed in slots #61, #62 and #84? Thus vectoangles could be recoded all in HexenC, and atan2 would be available in HexenC in case some other complex angles calculations might be needed in the future.
An interesting feature of the camera_remote entity is its native ability to track a moving target (a train). It does so by constantly recalculating the angle between itself and the target and sending the new updated angle to the client through a
WriteByte (MSG_ONE, SVC_SETANGLESINTER);instruction. That is done in the camera_track function in camera.hc.The angle recalculation is performed by the built-in vectoangles function, aka PF_vectoangles in the engine code (in Pr_cmds.c). Below in that function's code:
The yaw and pitch variables are declared as float at the top of the function and returned as float as well with G_FLOAT at the end of it, so why on earth are their values cast to int???
The consequence of it is that the angles returned by vectoangles to camera_track cut off any intermediary non integer value and this results in a jolting camera move. No possible smooth cutscene! :°°-(
So the feature request: would it be possible to copy/paste PF_vectoangles as PF_vectoangles2 (thus provide a new built-in function) with exactly the same code except no more cast to int?
Caveat: Of course this feature request would make no sense if the
WriteByte (MSG_ONE, SVC_SETANGLESINTER);orWriteByte (MSG_ONE, SVC_SETVIEWANGLES);instructions cannot deal with non integer values... unless maybe pushing the fixing that far too, if ever it's possible.