Differences between PrBoom+ and Eternity with regards to vanilla accuracy

Well, I tried my best to get the hang of the mouse in PrBoom+, but eventually gave up. I've tried various settings but none came even close to the one I use in Chocolate Doom. Therefore, I seriously consider switching to Eternity, since it uses the Chocolate Doom mouse acceleration system.

But, the comparison of source ports on Doom Wiki says that vanilla Doom accuracy is "very high" in Chocolate Doom and PrBoom+ but only "high" in Eternity. As far as I know, both PrBoom+ and Eternity stay faithful to vanilla with the exception of bugs. What exactly are the differences between them?

Don't pay much attention to that accuracy table, since itself isn't very accurate. Eternity can play back vanilla Doom demos, so mechanically it is perfectly accurate with the proper settings.

However, it does deviate from Doom with plenty of optional stuff, such as high-resolution, crosshairs, particles, terrain splashes, jumping, mouselook, etc.

Also the "Cardboard" renderer is more precise than Doom's, so you will see less graphical glitches.

PrBoom+ is given a higher accuracy rating (endorsed by me specifically) because it is capable of emulating certain undefined behaviors which Eternity simply has to consider being out-of-scope due to its differing goals.

A good example of an emulation present in PrBoom+ that is not currently planned for porting into Eternity is access to non-existent sidedefs when lines are improperly flagged as 2S. Demos recorded on broken maps with these types of offending linedefs may therefore desync.

These aren't really common, but there are some well-known examples.

Some other things differ in Eternity when playing the game outside of demos which are not optional, and even inside demos when the feature in question is not sync-critical.

For example when a switch is activated in Eternity, the switch sounds always play from a well-defined location and in a well-defined sequence. Neither was true in vanilla DOOM due to various glitches in the switch activation code. This is considered something so minor that it's not worth blowing the code up just to have a comp option for it.

So, I understand that the void glide in E2M6 would be impossible in Eternity, right? Even though I'm probably not skilled enough to pull off such tricks, there's still a feeling something is missing.

Feniks said:

So, I understand that the void glide in E2M6 would be impossible in Eternity, right? Even though I'm probably not skilled enough to pull off such tricks, there's still a feeling something is missing.

If it relies on illegal access emulation for 2S lines... I'm not sure if that's the issue with that map.

Feniks said:

So, I understand that the void glide in E2M6 would be impossible in Eternity, right? Even though I'm probably not skilled enough to pull off such tricks, there's still a feeling something is missing.

It doesn't require any skills. Just run towards the wall. :) Here is a demo of me doing it.

Memory overflows, such as (but not restricted to) those documented here, are the most significant area of difference.

Though there might be other things too, as Prboom+ has been tested extremely rigorously for compatibility (every demo at Compet-N and DSDA tested, for instance) with ensuring compatibility a top priority, whereas, as Quasar indicates, Eternity has different priorities, with demo compatibility desirable but not central to its ethos.

Generally speaking, Eternity can be used for recording and playback of vanilla demos with a very high probability of success. But occasionally there might be a problem, which I guess is one reason why Prboom+ tends to be preferred by the demos community. Another reason is the accuracy of Boom emulation.

Regarding the mouse in Prboom+, there are a number of parameters you can adjust, and chances are you can set it up the way you want. As well as sensitivity, there is acceleration, and some Windows settings you can adjust, notably "enhance pointer precision", which you'll probably want to make sure is turned off. Or maybe it's something more perception-based such as the uncapped framerate that (despite being purely cosmetic) is making it feel different from Choc. If so, this can also be turned off, as can pretty much every new feature.

Yeah really I'd encourage the demo community as a whole to continue using one recording platform. That way we have a baseline that everything else desiring demo compatibility can be measured against. For example there is a "bug" in prboom-plus that affects reference counts on mobj_t's, leaving them one higher than they should be, which only affects complevel 9. I implemented this to work the same way in Eternity, when fixing problems with BOOM 2.02 support, so that there will not be unnecessary discrepancies in BOOM 2.02 demo behavior.

The more ports we have being used for the actual recording, the less possible it'll be for them to sync everywhere. The -vanilla support in EE is more for testing. IF EE can record perfect vanilla demos that play back in the original and in Choco Doom, it just lets me know I haven't broken anything :>

Quasar said:

IF EE can record perfect vanilla demos that play back in the original and in Choco Doom, it just lets me know I haven't broken anything :>

Like EE, vanilla demo compatibility is an important feature in Odamex, but not the overriding goal of the port. However, testing demo play back sure is a great sanity check to make sure code changes don't alter Doom behavior!

Excuse me if I am wrong.
I remember that mouse accuracy and reactivity is much better when you set sdl_videodriver to directx because PrBoom+ will use direct-input and in-game mouse sensitivity will no more depend on desktop mouse settings;
same for choco-Doom.
However many people have problems with Win vista/7 and directX. I think you could try it.

In my case I do not use any acceleration in any port, so it is much easer for me to have the same feeling in all of them

EE is a very good port, and it does have a choco mouse acceleration settings. However I could never get a way to change acceleration factor and threshold like you can do in choco-Doom.

Yeah, a couple of things to keep in mind:

SDL ports (PrBoom+, Chocolate Doom, EE, etc.) on Windows will either use GDI or DirectX. This has a huge effect on mouse behavior; personally I prefer DirectX when using EE, and you can enable it with the -directx command-line switch.

EE recently (well, not that recently) got some new mouse features. You can now specify acceleration threshold and amount using the "custom" acceleration type. Those options should satisfy almost all users. If they don't satisfy you, post in this thread and I'll see what I can do.

EDIT:

I should also say that using -directx will also change the video driver. You will probably also want to use -8in32 along with it, to avoid a dumb SDL bug.

Is the Chocolate Doom mouse acceleration different behaviour than what is offered in Doom.exe?

I don't have a definitive answer for you. Looking at the linuxdoom source, here's what happens to mouse input:

	event.data2 = (X_event.xmotion.x - lastmousex) << 2;
	event.data3 = (lastmousey - X_event.xmotion.y) << 2;

It's likely that this is X-specific code. All it does is use relative mouse movement instead of absolute mouse position, and then multiplies the value by four. Chocolate Doom uses absolute mouse positions (warping back to 0,0 between measurements), and does no multiplying. EE uses relative mouse positions, and likewise does no multiplying. I can't tell you the effective difference between absolute & relative positions; it's an SDL thing and might affect different backends differently, that's all I know.

===

Separate from smooth mouse movement, both linuxdoom and Chocolate Doom do this to their mouse input:

	mousex = ev->data2*(mouseSensitivity+5)/10; 
	mousey = ev->data3*(mouseSensitivity+5)/10;

That's just handling a user's mouse sensitivity value, in a Doom-y way. EE will do this if you enable "vanilla_sensitivity".

===

Chocolate Doom also applies mouse acceleration, using the following code:

static int AccelerateMouse(int val)
{
    if (val < 0)
        return -AccelerateMouse(-val);

    if (val > mouse_threshold)
    {
        return (int)((val - mouse_threshold) * mouse_acceleration + mouse_threshold);
    }
    else
    {
        return val;
    }
}

Again that's pretty self-explanatory. If you don't want mouse accel, just set it to zero and it works as expected. EE will do this if you set "mouse_accel" to "2".

===

EE supports additional mouse behavior. Here is "raw" mouse sensitivity:

      // SoM: this mimics the doom2 behavior better. 
      if(mouseSensitivity_vanilla)
      {
          mousex += (ev->data2 * (mouseSensitivity_horiz + 5.0) / 10.0);
          mousey += (ev->data3 * (mouseSensitivity_vert + 5.0) / 10.0);
      }
      else
      {
          // [CG] 01/20/12: raw sensitivity
          mousex += (ev->data2 * mouseSensitivity_horiz / 10.0);
          mousey += (ev->data3 * mouseSensitivity_vert / 10.0);
      }

(Wow, was that really a whole year ago? That's crazy.)

Of course, EE supports separate sensitivity values for horizontal and vertical mouse movement, as you can see here.

Here are disabled and "linear" accelerations:

         // SoM 1-20-04 Ok, use xrel/yrel for mouse movement because most
         // people like it the most.
         if(mouseAccel_type == 0)
         {
            mouseevent.data2 += event.motion.xrel;
            mouseevent.data3 -= event.motion.yrel;
         }
         else if(mouseAccel_type == 1)
         {
            // Simple linear acceleration
            // Evaluates to 1.25 * x. So Why don't I just do that? .... shut up
            mouseevent.data2 += (event.motion.xrel +
                                 (float)(event.motion.xrel * 0.25f));
            mouseevent.data3 -= (event.motion.yrel +
                                 (float)(event.motion.yrel * 0.25f));
         }

(1-20 seems to be the date for mouse code changes, that's also crazy haha).

Here is EE's "custom" acceleration:

static double CustomAccelerateMouse(int val)
{
   if(val < 0)
      return -CustomAccelerateMouse(-val);

   if((mouseAccel_value != 1.0) && (val > mouseAccel_threshold))
      return val * mouseAccel_value;

   return val;
}

EE also supports "smooth turning" (an SMMU feature I assume), which basically averages your current mouse input with your mouse input from the previous TIC:

   // sf: smooth out the mouse movement
   // change to use tmousex, y   
   // divide by the number of new tics so each gets an equal share

   tmousex = mousex /* / newtics */;
   tmousey = mousey /* / newtics */;

   if(smooth_turning)
   {
      static double oldmousex=0.0, mousex2;
      static double oldmousey=0.0, mousey2;

      mousex2 = tmousex; mousey2 = tmousey;
      tmousex = (tmousex + oldmousex) / 2.0;        // average
      oldmousex = mousex2;
      tmousey = (tmousey + oldmousey) / 2.0;        // average
      oldmousey = mousey2;
   }

So the answer to your question is, "I think so". I can't say if your mouse will behave identically between doom2.exe and Chocolate Doom if you configure them with identical mouse values, but it looks like they support essentially the same features. Of course, in line with its mission, EE supports these behaviors and then some.

===

As a side note, when upgrading EE's mouse code, I made it a point to do as many mouse calculations as possible using doubles. Theoretically this should improve precision, especially when using high DPI or high rate mice. In practice, SDL is such garbage it was probably a waste of time.

Ladna said:

EDIT:

I should also say that using -directx will also change the video driver. You will probably also want to use -8in32 along with it, to avoid a dumb SDL bug.

Or use the OpenGL 2D-in-3D backend. Heavily recommended.