Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
fabian

This is Woof! 8.1.0 (Nov 26, 2021) [Updated WinMBF]

Recommended Posts

5 hours ago, game said:

[STRINGS]

GOTREDCARD = Picked up a zoo key

PD_REDK = You need a zoo key to enter

This works fine for me in Woof:

doom02.png.65e672a82c8adcf21b4cef7b39ca05b0.png

Share this post


Link to post

I'm not sure if this is intentional or not since the original code does the same thing in some occassions, but I'll mention it anyways:

 

Basically, the following is not totally true (snippet from P_MovePsprites)

// [FG] center the weapon sprite horizontally and push up vertically
else if (center_weapon == 1)
{
  psp->sx2 = FRACUNIT;
  psp->sy2 = WEAPONTOP;
}

By making sx2 equal to FRACUNIT, a one-pixel offset is applied to the sprite, so it is not truly centered. This is not the only instance of such slight offset in the Psprites code (as I said, it happens on some of the original Doom code too), and based on some testing and discussion on the subject, it's present across most if not all non-ZDoom-based ports. However, since this is a setting that deviates from vanilla behavior, it might be a special case. I can't tell if it was kept for compatibility regardless or if it did go unnoticed, I hope I can get some light from people who know.

Edited by Alaux

Share this post


Link to post

Well, this is the calculation of the weapon sprite bob from p_pspr.c:A_WeaponReady(). It is identical in both Vanilla and MBF:

// bob the weapon based on movement speed
  {
    int angle = (128*leveltime) & FINEMASK;
    psp->sx = FRACUNIT + FixedMul(player->bob, finecosine[angle]);
    angle &= FINEANGLES/2-1;
    psp->sy = WEAPONTOP + FixedMul(player->bob, finesine[angle]);
  }

As you can see, the sx value is based around FRACUNIT. If you disable bobbing by setting player->bob to zero, what remains is FRACUNIT and not zero.

Share this post


Link to post
5 hours ago, fabian said:

As you can see, the sx value is based around FRACUNIT. If you disable bobbing by setting player->bob to zero, what remains is FRACUNIT and not zero.

I'm aware, this is one of "the other instances", likely the one causing that minor inaccuracy across the rest of ports. At this point it seems like it was intentionally kept as is, although I believe it could be rather easily fixed since only sy seems to matter for demo compatibility; my fork seems to be running alright without it, at least.

Share this post


Link to post

It's not a "fix" though to change where things are rendered, nor is the existing implementation inaccurate.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×