[quake2] console font size - anybody?

[Thomas J Fogal]

No worries (brendan, anyone else), I'll continue to participate.
Despite Nicolai being so rude, he has some good points and has forced
me to re-evaluate my knowledge for the better.

 <200501131448.29098.prefect_ at gmx.net>Nicolai Haehnle writes:

> On Wednesday 12 January 2005 17:57, Thomas J Fogal wrote:
> >  <200501121621.32294.prefect_ at gmx.net>Nicolai Haehnle writes:
> > > On Wednesday 12 January 2005 14:24, Brendan Burns wrote:

<snip: scaling makes things slow. Basically, I argued that scaling will
slow things down by forcing portions of the pipeline to reexecute.>

> You're wrong. (Unless you're using a software implementation of OpenGL,=20
> which might have a special case for non-scaling - but that's highly=20
> unlikely).

> It's true that the number of fragments that need to be processed increases=
> =20
> linearly with the area of a polygon. But when you scale the size of the=20
> quads that are used to render the console, you automatically *reduce* the=20
> number of quads. The total area of the console remains exactly the same,=20
> and therefore the number of fragments and pixel data bandwidth remains the=
> =20
> same.

I suspect that increasing the size of the quads necessary in rendering
the image does not necessarily reduce the number of quads, but I don't
really know anything about this. I'll take your word on it for now, but
if you could explain this in more depth (off list perhaps? this is not
really related to Q2 anymore), I'd appreciate it.

I would ask you to be more specific when labeling someone as "wrong".
I'm glad you did point it out, because I was not completely correct as
to the reason, but it is correct to say lighting + scaling is a bad
idea. From the OpenGL "Red Book"
(http://fly.cc.fer.hr/~unreal/theredbook/chapter03.html):

"glScale*() is the only one of the three modeling transformations that
changes the apparent size of an object: Scaling with values greater
than 1.0 stretches an object, and using values less than 1.0 shrinks
it. Scaling with a -1.0 value reflects an object across an axis. The
identity values for scaling are (1.0, 1.0, 1.0). In general, you should
limit your use of glScale*() to those cases where it is necessary.
Using glScale*() decreases the performance of lighting calculations,
because the normal vectors have to be renormalized after
transformation."

Also, in appendix H
(http://fly.cc.fer.hr/~unreal/theredbook/appendixh.html) under "OpenGL
Performance Tips":

"Provide unit-length normals if it's possible to do so, and avoid the
overhead of GL_NORMALIZE. Avoid using glScale*() when doing lighting
because it almost always requies that GL_NORMALIZE be enabled."

<snip>

> > I took a quick look but did not try hacking any code. This might be
> > doable by wrapping all 'DrawChar' and/or 're.DrawChar' calls in:
> >=20
> > glPushMatrix();
> >  glScalef(1.0,1.0,-x);
> >  re.DrawChar(...);
> > glPopMatrix();
> 
> Since we need to scale x and y, not z (remember, this is ortho-mode), the=20
> call has to be glScalef(factor, factor, 1.0); or similar.

Mea culpa. I did not realize that the text was likely drawn in
orthographic mode -- this should have been obvious.
This makes me think that overlapping text could be an issue.

> Also, changing the matrix for every character drawn is insane. Push and=20
> scale *before* all console rendering, then pop after all console rendering=
> =20
> is finished.

Well, of course. This was a quick hack idea intended for a single
person. It took me all of 5 minutes to find that re.DrawChar was mostly
called in one or two files, but doing things 'correctly' and locating
all the calls of all the functions that call re.DrawChar would be a
laborious effort.

> > in client/console.c. Or perhaps the mod might be appropriate in
> > M_DrawCharacter from client/menu.c.
> >=20
> > Lighting in particular is one thing that causes a major slowdown with
> > scaling. It would probably be a good idea to disable and reenable
> > lighting within that push/pop, above.
> 
> Sorry, but you really don't seem to have a clue what you're talking about.

It is with great restraint that I avoid responding to this.

> HUD and GUI-related things don't use lighting anyway.

True. I imagined as much when I thought about the original problem, but
I know -very- little about the quake engine and wanted to make sure I
commented on the offchance something might be affected.

> And even if they *did* use lighting, the slowdown argument would still be
> wrong.

I've already gone over this argument, above.

Unless something relates back to quake2, please keep this off-list.

-tom