Hendricks266

Graf, if you're going to make arguments, you really need to quit Building them out of misinformation. EDuke32 has fixed everything you are complaining about. Let me give you a full rundown of the ways in which we have improved mouse support over the years. 1. As noted, the original input code contains a strange condition that prevents motion along more than one axis at a time. This is fixable even in DOS through use of an external input driver: SwissCM's bMouse. EDuke32 provides an option to keep this behavior, off by default of course, due to the stubbornness of parts of the Duke multiplayer community. In any case, with default settings it is fixed, so it is a win-win. 2. 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 World Tour has this bug. We fixed it in EDuke32 long ago. 3. EDuke32 binds previous/next weapon to the mousewheel, as is standard. We fixed weapon switching behavior so it is possible to request a weapon at any point during a weapon switching animation that is already in progress. Otherwise use of the mousewheel for these functions would be inhibited by having to wait for the switching animation to progress for each click of the wheel. 4. 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. 5. The original games store aim position in integers that directly correspond to the ang and horiz values controlling the camera's yaw angle and the tangent of its pitch angle. This results in a noticeable stair-step effect in mouse aiming at higher resolutions. We have converted these values to fixed point arithmetic, allowing for high precision aiming without this quantization error. 6. 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. 7. 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. We are currently beta testing 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. In conclusion, leave Build to the pros.

Very cool!

Technically, converting them all to VOC would work immediately, but that would be a format downgrade. In this case, your flyby.wav is 16-bit and 32000 Hz, while your flyby.voc is 8-bit and 31573 Hz. EDIT: It seems EDuke32 currently has a bug that treats all FLAC sound effects as infinitely looping tracks. Sorry about that... I'll fix it when I add the voc-->flac replacement code.

This is awesome, thanks! :D I encoded all the WAVs in your pack as FLAC (and fixed the capitalization on one file) so that EDuke32 can open them properly. http://hendricks266.duke4.net/stuff/pk_duke3d_sfx_20140627.zip At present, we don't have any code to look for "flyby.flac" before "flyby.voc", for example, like we do for the MIDI music, so using this in-game would take either a def file or a CON file, neither of which has an efficient method of loading as a mutator without creating an ugly batch file to use command line parameters. Watch the SVN log and our synthesis build system in the coming days for streamlined loading support for this pack and packs like it. EDIT: If you want to use it now, I wrote a def-generating bash script to make the appropriate defs. First, download the zip I linked above and put it in a subfolder of your EDuke32 folder named autoload. Then, download this def file and put it in your EDuke32 folder. Next, you have two options. You can rename "pk_duke3d_sfx_20140627.def" to "duke3d.def" if you are using no other music, HRP, or other types of packs. Or, run EDuke32 with the following command line parameters (either manually or from a batch file): eduke32.exe -mh pk_duke3d_sfx_20140627.def