Supermodel Forum

One for Harry,
you still alive Harry ? Thought this one might interest you since you wrote most of the fog code. Some people had noticed in the attract mode for scud in the first level, fog shows up where it doesn't on the real hardware.

ie here


and the real hardware


It's like that for the entire section

Anyway in the viewport there are some values we aren't passing out

Code: Select all

    0x1c:   xxxxxxxx xxxxxxxx -------- -------- "lj"
            -------- -------- xxxxxxxx xxxxxxxx "li"

These values are almost always zero, except for this section of scud. As soon as the fog shows where it shouldn't suddenly these values spring to life.

In the SDK I think it's this

Code: Select all

      void        SetLOSPosition   ( float los_position_i
                                   , float los_position_j ) ;

In the decompiled lib comes out as

Code: Select all

void __thiscall PRO_Viewport::SetLOSPosition(PRO_Viewport *this, float los_position_i, float los_position_j)
{
  int v3; // eax@1

  *((float *)this + 53) = los_position_i;
  *((float *)this + 54) = los_position_j;
  *((_DWORD *)this + 13) = (*((_DWORD *)g_API_Data + 343))++;
  v3 = *((_DWORD *)this + 14) | 1;
  *((_DWORD *)this + 14) = v3;
  *((_DWORD *)this + 14) = v3 | 0x80;
  PRO_Pingpong_Data_Block::NotifyUpdate(this);
}

And

Code: Select all

void __thiscall PRO_Viewport::updateLOSPosition(PRO_Viewport *this)
{
  if ( *((_DWORD *)this + 4) == 1 )
  {
    *(_DWORD *)(*((_DWORD *)this + 7) + 112) = *(_DWORD *)(*((_DWORD *)this + 7) + 112) & 0xFFFF | ((signed __int16)(signed __int64)(*((float *)this + 53) * *((float *)this + 47) * 8.0) << 16);
    *(_DWORD *)(*((_DWORD *)this + 7) + 112) = *(_DWORD *)(*((_DWORD *)this + 7) + 112) & 0xFFFF0000 | (unsigned __int16)(signed __int64)(*((float *)this + 48) * *((float *)this + 54) * 8.0);
  }
}

The updateLosPosition tells us the values are multiplied by 8
(float *)this + 47) * 8.0) << 16
and
(float *)this + 54) * 8.0

So we can read out this los position ?? with this code

Code: Select all

      float li = (vpnode[0x1c] & 0xFFFF) / 8.0f;
      float lj = (vpnode[0x1c] >> 16) / 8.0f;

Any idea what the hell a los position is? I guess it's related to lighting or the lens flair somehow.

That one puzzled me for some time. LOS is Line-Of-Sight and some scarce infos are here. Here's a snippet:

LINE OF SIGHT RANGING:

The system can be directed to report the depth (Z) to any point as
defined by its pixel location. This feature can accurately detect
when a portion of a polygon has been declared translucent by virtue
of its texturing, and instead report the range to the closest opaque
polygon beyond. This method relies on locating the LOS within the
field of view of a display channel. Range is reported with 22-bit
floating point accuracy (six bits exponent, 16 bits mantissa).

I think has to do with stencil/depth buffering and polygon hiding or sorting. There is a dedicated test in the hidden menu of Scud, there're values at the bottom that should supposedly change as the green plane goes away from camera and intersects the red sphere, but currently are stuck maybe by missing emulation.

But aside from this I wasn't able to go further.

That sounds like it's it.

The devguide has this

Line of Sight (LOS) . . . Viewray from the viewpoint through a pixel on the screen.

So the x/y paramaters must be a position in the viewport. Not sure how the coordinates work though. How do the coordinates work for the head light? I know they are capped at 2048
But what would the coordinates by for 0,0 and 496x384 ?

Headlight coordinates work like that because they are supposed to go way off screen if necessary (and limited to -8192/+8191, if I recall). Check the intro of ECA, not the first rolling one, but the second more "dramatic", after the fist highscore display.

This is an example (lower/left corner):

Ian, a little quiz for you: where did the red houses on the background go?

Model3:

Supermodel:

I'm currently investigating, without success.

Not sure
2 things to try, disable fog?
Try disabling culling too. Just stub the relevant method and return inside, so it will draw everything

Edit:
Was having a brain fail. I read those as the other way around, showing up on the model3 and not appearing on supermodel.

Remember the actual hardware is doing some automatic LOD selection. Quite often the lower LODs are sometimes just a single flat poly representing the fence or whatever. So I think there's 2 possible things that could be happening. Lowered LOD removes the house entirely?? Possible maybe. Or the simpler LOD has a different Z value, and thus different fog values.

Example
LOD 0 (highest detail)


LOD 3 (lowest detail)


Maybe try force rendering the lowest level of detail? And see what happens. I would love to implement proper LOD selection but so far haven't been able to figure out how it works.

Thanks for the hint, I'll see if I can do something by this w.e.

I was thinking one could choose, through some GPU configuration register, the fog density algorithm. For example from linear to, say, exponential.

Well I figured out what the LOS numbers are.

Code: Select all

      float li = (vpnode[0x1c] & 0xFFFF) / 16.0f;      // los position
      float lj = (vpnode[0x1c] >> 16) / 16.0f;

Actually values are / 16
It's simply the viewport x/y position.

Can test like this

Code: Select all

   glDisableVertexAttribArray(0);
   glDisableVertexAttribArray(1);
   glDisableVertexAttribArray(2);
   glDisableVertexAttribArray(3);
   glDisableVertexAttribArray(4);
   glDisableVertexAttribArray(5);

   {
      glDisable(GL_TEXTURE_2D);
      glDisable(GL_LIGHTING);
      glPointSize(10);

      glMatrixMode(GL_PROJECTION);
      glLoadIdentity();
      glMatrixMode(GL_MODELVIEW);
      glLoadIdentity();
      glViewport(0, 0, 496, 384);
      glOrtho(0, 496, 0, 384, -1, 1);
      glColor3f(1, 0, 0);
      glBegin(GL_POINTS);
      glVertex2f(testI, 384-testJ);
      glEnd();

   }

Now to work out how this effects rendering ..

Looking at those screenshots, by association, for a moment I thought about the missing Lost Word red pointer...

Na i drew it so I could see what it was doing
From the description you found, and looking at where it draws.

At a guess I think it probably reads the depth value at that x/y location, then works out whether to turn on fogging. Fogging definitely happens on the original hardware with those x/y values set, but seems dependent on angle. It also only seems to work if fog is set to white or (1,1,1).

Either there is a 1 frame lag between reading values and working out the depth value, or the hardware does a pre depth pass of all the geometry.