mouselook/freelook for vanilla Heretic, Hexen and Strife

[AnotherGrunt]

1 hour ago, xttl said:

 

No idea why that might be. :( (assuming mouse is fully working in other games and programs)

 

 

Hexen 1.1, DOSBox 0.74 and SVN and ravmouse works just fine.

[Nikku4211]

5 hours ago, xttl said:

No idea why that might be. :( (assuming mouse is fully working in other games and programs)

 

Mouse works in other games and programs, yeah. It works in Heretic when I'm using its normal mouse mode, just not with Ravmouse.

[Redneckerz]

On 8/28/2021 at 9:04 AM, Nikku4211 said:

I've tried Ravmouse on both DOSBox-X and DOSBox-ECE and the mouse didn't work at all.

 

I set the setup to keyboard only like what was asked, and the exe is in the same directory as the game.

Try default DOSBox. Including myself there are two where it works fine, so this is hovering towards a user issue rather than the program itself.

7 hours ago, xttl said:

This really needs to be a heretic.exe/hexen.exe modification anyway because there is no way for the external control driver to know if the view pitch has been reset (by teleportation, level exit, etc.) or if the game was paused or in menus when mouse was moved, both things which it really needs to know due to the way looking up/down via the external control API works. It seems a bit difficult to even solve this by reading game memory from the driver because it is a 16-bit real mode program and the game is running in protected mode using memory above 1MB.

Appreciate the updated version Xttl (And welcome back!). If you were to make this a full-on exe hack, consider using Heretic-Plus/Hexen-Plus as basis. Unlike Doom, Hexen/Heretic have not seen as much advanced executable hacks, so any improvement there is very welcome.

 

5 hours ago, AnotherGrunt said:

 

Hexen 1.1, DOSBox 0.74 and SVN and ravmouse works just fine.

Worked fine under standard DOSBox 0.74 on my Windows 7 machine.

[Nikku4211]

24 minutes ago, Redneckerz said:

Try default DOSBox. Including myself there are two where it works fine, so this is hovering towards a user issue rather than the program itself.

Tried it on DOSBox 0.74 standard and it doesn't work either.

[Redneckerz]

Just now, Nikku4211 said:

Tried it on DOSBox 0.74 standard and it doesn't work either.

Then more details are needed on your configuration and how you load RAVMouse.

[Nikku4211]

7 minutes ago, Redneckerz said:

Then more details are needed on your configuration and how you load RAVMouse.

 

Sometimes, when I run RavMouse in DOSBox-X, it freezes.

 

Other times it boots the game but doesn't work at all.

 

I have no idea what more details I am supposed to give, though.

[OpenRift]

10 hours ago, xttl said:

 

I updated the program at some point to support negative values for -vs, which is (perhaps counterintuitively, you might expect it to invert direction) interpreted as meaning that the vertical input value from the mouse driver is to be divided by that value (absolute value to be precise) rather than multiplied, but seems the version on archive.org is too old as is the version I've posted as an attachment here once before.

  

Here's a version with that feature (and 16-bit Open Watcom C source) included:

ravmouse2.zip

 

Note that the limited vertical look resolution afforded by the external control API starts to become more and more of an issue the lower you go in vertical sensitivity.

  

This really needs to be a heretic.exe/hexen.exe modification anyway because there is no way for the external control driver to know if the view pitch has been reset (by teleportation, level exit, etc.) or if the game was paused or in menus when mouse was moved, both things which it really needs to know due to the way looking up/down via the external control API works. It seems a bit difficult to even solve this by reading game memory from the driver because it is a 16-bit real mode program and the game is running in protected mode using memory above 1MB.

  

  

No idea why that might be. :( (assuming mouse is fully working in other games and programs)

  

Thanks, this does feel WAY better! I can see what you're talking about with the fineness of the vertical look, though the build engine was kind of the same way back then too (though maybe not as much), even with mouse fixes like BMOUSE or BUILDMFX.

[xttl]

5 hours ago, Nikku4211 said:

Tried it on DOSBox 0.74 standard and it doesn't work either.

 

I almost wonder if this could somehow be caused by DOSBox being able to run code too fast on your system. Personally, I've had no problems with ravmouse but I'm stuck with testing on relatively old CPUs only at the moment. Could you try limiting CPU cycles and see if it helps? (eg. "cycles 10000" on DOSBox command line before you start ravmouse, you could also try "core normal")

 

edit: also just in case you were doing that, don't try to use novert and ravmouse at the same time (though turning sideways and buttons should still work even if novert was loaded)

 

5 hours ago, Redneckerz said:

If you were to make this a full-on exe hack, consider using Heretic-Plus/Hexen-Plus as basis. Unlike Doom, Hexen/Heretic have not seen as much advanced executable hacks, so any improvement there is very welcome. 

 

No plans for this at the moment. Just saying the external control driver approach as it is has some annoying limitations. :(

(an exe hack which solves these limitations can still stay netgame/demo compatible btw.)

Edited August 30, 2021 by xttl

[Nikku4211]

8 hours ago, xttl said:

edit: also just in case you were doing that, don't try to use novert and ravmouse at the same time (though turning sideways and buttons should still work even if novert was loaded)

I did not have novert loaded at all.

 

8 hours ago, xttl said:

Could you try limiting CPU cycles and see if it helps? (eg. "cycles 10000" on DOSBox command line before you start ravmouse, you could also try "core normal")

I've tried both, and it didn't work. All it did was make the game run slow, the mouse didn't work.

[xttl]

¯\_(ツ)_/¯

 

No idea then. Maybe if/when someone implements the same idea as an exe hack it'll work.

[Redneckerz]

On 8/30/2021 at 4:53 AM, xttl said:

No plans for this at the moment. Just saying the external control driver approach as it is has some annoying limitations. :(

(an exe hack which solves these limitations can still stay netgame/demo compatible btw.)

No worries. Just glad you are back from your break (if it were one?) and hope you will continue your specialized DeHacked version and UDoomHack exe hack.

[xttl]

Well, now that I looked more at the game code I noticed two more problems besides the external driver's and game's pitch value getting out of sync:

 

- The game itself also tracks current view pitch in two different places which can and will get out of sync with each other: local static var oldAngle in G_BuildTiccmd (used by the code which handles input from external control driver) and players[x]->lookdir. Really, oldAngle should always be reset whenever players[consoleplayer]->lookdir is reset (or the code should stick to using lookdir only), but it isn't.

 

- useexterndriver is checked in P_ZMovement to disable automatic view centering whenever the player has just dropped down from a large height. This can break demo / netgame sync because information about if useexterndriver was enabled while recording isn't stored in a demo and neither is it a per-player variable which is synced between nodes in a netgame. (edit: seems P_PlayerThink checks it too to disable automatic view centering if flight powerup has just ran out)

[RetroAkaMe]

Download link not working :(