intercepts overflow because of crosshair implementations?

[fabian]

Hi there,

I have a concern regarding the more "sophisticated" crosshair implementations found in some source ports, e.g. PrBoom+, Eternity and also Crispy Doom. The implementations found in these source ports allow for additional actions applied to the crosshair when it is aiming at a target, e.g. change its color or lock its position on the target position.

In order to know if the player is currently aiming at a target, these implementations call P_AimLineAttack() and check for the "linetarget" variable. However, P_AimLineAttack() necessarily checks for all intercepts the current aim line may cross and should thus be vulnerable to the intercepts overflow bug.

Is this right and does this mean that these crosshair implementation could theoretically trigger the intercepts overflow bug and thus cause demo desyncs?

- Fabian

[Gez]

Are PrBoom+ and Eternity actually vulnerable to the intercept overflow bug?

[Grazza]

If you enable emulation of it, yes (at least in the case of Prb+; I don't know about Eternity).

The general advice is not to have Intercepts overflow emulation enabled unless you are doing so for a very specific reason. That will take care of this issue. Note: spechits and reject overflow emulation can and should be left enabled with no problems; it is just intercepts that has bad effects.

[Gez]

I haven't looked at the PrB+ code but if its intercept overflow bug is fixed except for a conditional emulation codepath, then I suppose the intercepts done for crosshair purposes can unconditionally take the bug-less path.

[fraggle]

Heh, this takes me back. I remember back when I was writing SMMU, I had a bug where the crosshair code would make monsters wake up because of the P_AimLineAttack() call. Not really related to the intercepts overflow stuff but still...

[fabian]

fraggle said:

Heh, this takes me back. I remember back when I was writing SMMU, I had a bug where the crosshair code would make monsters wake up because of the P_AimLineAttack() call. Not really related to the intercepts overflow stuff but still...

As a similar anecdote, an early implementation of my crosshair code triggered shootable linedefs. Oh, what a mess...

I have now hacked a little guard into my code that prevents the intercepts array from overrunning due to the crosshair code.

Thanks for your comments!