Mouse support improvements: Difference between revisions
Jump to navigation
Jump to search
Hendricks266 (talk | contribs) No edit summary |
Hendricks266 (talk | contribs) No edit summary |
||
| Line 5: | Line 5: | ||
#EDuke32 binds ''next weapon'' and ''previous weapon'' to the mousewheel, as is standard. The original game requires the player to wait for the switching animation to complete for one weapon before the next can be requested. The port fixes this weapon switching behavior so it is possible to advance the mousewheel additional stops at any point during a weapon switching animation that is already in progress and have them count toward the user's selection. | #EDuke32 binds ''next weapon'' and ''previous weapon'' to the mousewheel, as is standard. The original game requires the player to wait for the switching animation to complete for one weapon before the next can be requested. The port fixes this weapon switching behavior so it is possible to advance the mousewheel additional stops at any point during a weapon switching animation that is already in progress and have them count toward the user's selection. | ||
#Our default modern control scheme does not bind any key to the Toggle [Vertical] Mouse Aiming function, to prevent confusion caused by this mostly useless option. By default vertical aiming is enabled as opposed to moving you forward and backward, and the option to hold the key to aim instead of being a toggle is disabled. That way everything Just Works out of the box. | #Our default modern control scheme does not bind any key to the Toggle [Vertical] Mouse Aiming function, to prevent confusion caused by this mostly useless option. By default vertical aiming is enabled as opposed to moving you forward and backward, and the option to hold the key to aim instead of being a toggle is disabled. That way everything Just Works out of the box. | ||
#The original games store aim position in integers that directly correspond to the [[ang]] and [[horiz]] values controlling the camera's yaw angle (2048 units for a full circle) and the tangent of its pitch angle (399 units for | #The original games store aim position in integers that directly correspond to the [[ang]] and [[horiz]] values controlling the camera's yaw angle (2048 units for a full circle) and the tangent of its pitch angle (399 units for a vertical viewing range mostly up to mostly down) respectively. This results in a noticeable stair-step effect in mouse aiming at higher resolutions. EDuke32 now uses fixed point arithmetic to represent these values, allowing for high precision aiming without this quantization error. | ||
#Since the original renderer achieved vertical mouselook by the "fake" method of Y-shearing, it was natural to control the shearing using the tangent of the vertical angle, which directly corresponds to the extent of shearing applied to the viewport. Since the mouse used these values directly, it resulted in less vertical rotation per unit of physical mouse movement the closer you were to the high or low extents of the aim range. EDuke32 now processes mouse input in the domain of vertical angle instead of angle tangent, eliminating this artifact and ensuring consistent spherical mouse aiming. | #Since the original renderer achieved vertical mouselook by the "fake" method of Y-shearing, it was natural to control the shearing using the tangent of the vertical angle, which directly corresponds to the extent of shearing applied to the viewport. Since the mouse used these values directly, it resulted in less vertical rotation per unit of physical mouse movement the closer you were to the high or low extents of the aim range. EDuke32 now processes mouse input in the domain of vertical angle instead of angle tangent, eliminating this artifact and ensuring consistent spherical mouse aiming. | ||
#Originally, input polling took place only at the 30 Hz game world timer and was interpolated for frames in between. This gave mouse aiming a laggy, floaty feeling. EDuke32 implements a new method which polls input at the framerate instead and performs no interpolation. This fixes the floatiness, and could result in less input lag than even modern shooters. | #Originally, input polling took place only at the 30 Hz game world timer and was interpolated for frames in between. This gave mouse aiming a laggy, floaty feeling. EDuke32 implements a new method which polls input at the framerate instead and performs no interpolation. This fixes the floatiness, and could result in less input lag than even modern shooters. | ||
[[Category:EDuke32 project information]] | [[Category:EDuke32 project information]] | ||
Revision as of 01:01, 16 August 2025
How is mouse support improved in EDuke32 over the original release of Duke Nukem 3D?
- The original input code contains a strange condition that prevents motion along more than one axis at a time. EDuke32 removes this limitation. (This is fixable even in DOS through use of an external input driver: SwissCM's bMouse.)
- This original input code also contains a bug where motion along one direction of each axis is completely dropped if movement is too slow. This is caused by right-shifting where a division operation should have been used. Even Duke Nukem 3D: 20th Anniversary World Tour has this bug. EDuke32 fixed it long ago.
- EDuke32 binds next weapon and previous weapon to the mousewheel, as is standard. The original game requires the player to wait for the switching animation to complete for one weapon before the next can be requested. The port fixes this weapon switching behavior so it is possible to advance the mousewheel additional stops at any point during a weapon switching animation that is already in progress and have them count toward the user's selection.
- Our default modern control scheme does not bind any key to the Toggle [Vertical] Mouse Aiming function, to prevent confusion caused by this mostly useless option. By default vertical aiming is enabled as opposed to moving you forward and backward, and the option to hold the key to aim instead of being a toggle is disabled. That way everything Just Works out of the box.
- The original games store aim position in integers that directly correspond to the ang and horiz values controlling the camera's yaw angle (2048 units for a full circle) and the tangent of its pitch angle (399 units for a vertical viewing range mostly up to mostly down) respectively. This results in a noticeable stair-step effect in mouse aiming at higher resolutions. EDuke32 now uses fixed point arithmetic to represent these values, allowing for high precision aiming without this quantization error.
- Since the original renderer achieved vertical mouselook by the "fake" method of Y-shearing, it was natural to control the shearing using the tangent of the vertical angle, which directly corresponds to the extent of shearing applied to the viewport. Since the mouse used these values directly, it resulted in less vertical rotation per unit of physical mouse movement the closer you were to the high or low extents of the aim range. EDuke32 now processes mouse input in the domain of vertical angle instead of angle tangent, eliminating this artifact and ensuring consistent spherical mouse aiming.
- Originally, input polling took place only at the 30 Hz game world timer and was interpolated for frames in between. This gave mouse aiming a laggy, floaty feeling. EDuke32 implements a new method which polls input at the framerate instead and performs no interpolation. This fixes the floatiness, and could result in less input lag than even modern shooters.