There are some problems in CS engine & OpenGL renderer which doesn't allow to draw mirrors correctly.
1. Probably one problem is common for all zfill/floating portals and described in bug #1398043 I've posted recently (see Flarge_Mirror.jpg attached to bug tracker).
It is caused by strange code in gl_render3d.cpp. That code is in Draw2DPolygon function:
void csGLGraphics3D::Draw2DPolygon (csVector2* poly, int num_poly,
const csPlane3& normal)
{
SwapIfNeeded();
// Get the plane normal of the polygon. Using this we can calculate
// '1/z' at every screen space point.
float M, N, O;
float Dc = normal.D ();
if (ABS (Dc) < 0.01f)
{
M = N = 0;
O = 1;
}
else
{
float inv_Dc = 1.0f / Dc;
M = -normal.A () * inv_Dc * inv_aspect;
N = -normal.B () * inv_Dc * inv_aspect;
O = -normal.C () * inv_Dc;
}
// Basically a GL ortho matrix
const float P0 = 2.0f / (float)viewwidth;
const float P5 = 2.0f / (float)viewheight;
const float P10 = -2.0f / 11.0f;
const float P11 = -9.0f / 11.0f;
int v;
glBegin (GL_TRIANGLE_FAN);
csVector2* vt = poly;
for (v = 0 ; v < num_poly ; v++)
{
float sx = vt->x - asp_center_x;
float sy = vt->y - asp_center_y;
float one_over_sz = M * sx + N * sy + O;
float sz = 1.0f / one_over_sz;
// This is what we would do if we'd use glOrtho():
//glVertex4f (vt->x * sz, vt->y * sz, -1.0f, sz);
// The vector that results from a GL ortho transform
csVector4 bar ((vt->x * sz) * P0 - sz,
(vt->y * sz) * P5 - sz,
-P10 + sz * P11,
sz);
/* Now it can happen that a vertex of a polygon gets clipped when it's
* very close to the near plane. In practice that causes sonme of the
* portal magic (stencil area setup, Z fill) to go wrong when the camera
* is close to the portal. We "fix" this by checking whether the vertex
* would get clipped and ... */
const float bar_w = bar.w, minus_bar_w = -bar_w;
if ((bar.x < minus_bar_w) || (bar.x > bar_w)
|| (bar.y < minus_bar_w) || (bar.y > bar_w)
|| (bar.z < minus_bar_w) || (bar.z > bar_w))
{
/*If yes, "fix" the vertex sent to GL by replacing the Z value with one
that won't cause clipping.*/
const float hackedZ = 1.0f - EPSILON;
glVertex3f (bar.x/bar_w, bar.y/bar_w, hackedZ);
}
else
{
// If not, proceed as usual.
glVertex4f (bar.x, bar.y, bar.z, bar.w);
}
vt++;
}
glEnd ();
}
Strange code begins with "Now it can happen..." comment. Yes, we need some work around the case when camera "glass" crosses a portal polygon. But the vertices of portal polygon may have any z-coordinate and I don't understand why their x/y coordinates influence on "hackedZ" path.
If we use
if ((bar.z < minus_bar_w) || (bar.z > bar_w)) ...
instead of
if ((bar.x < minus_bar_w) || (bar.x > bar_w)
|| (bar.y < minus_bar_w) || (bar.y > bar_w)
|| (bar.z < minus_bar_w) || (bar.z > bar_w))
the function works OK with "portal magic" but the "overlay" bug #1398043 doesn't appear anymore. Maybe I'm wrong?
2. Other portal problem: portals are not visible in mirrors (it can be seen in flarge level also, but it 's not striking)

It seems, this happens because of vertex order of portal polygon is reversed in each mirror. When we use static statecache->SetCullFace (GL_FRONT) call it works Ok, while no other portals reflected. But if we have other portals the problem appears.
The temporary solution (second shot) is to disable GL culling while filling stencil, but this causes other bug - backfaced mirrors sometimes appears/flickers.

To solve the problem nicely we need to have for each portal in clipportal_stack some "mirror_flag" and calculate result culling in SetupClipPortals. But renderer knows nothing of portals' mirror property at the moment.