console font size

[mv007]

Hi,

Is there _any_ way to change the console font size in icculus quake2?

I would like to use a higher resolution, like 1280x1024 - instead of my
usual 800x600.

BUT:
The console text gets so tiny that it is really hard to read - not good for
my eyes.

While quakeworld (quakeforge) has some -conwidth -conheight command line
options and while nocheat has a command "gl_scale) to easily solve that
problem. Quake2max also has a command "con_font_size".

In all these cases, you can easily change the console text size without
changing the high resolution.

Unfortunately, I couldn't find anything to achieve something like that in
icculus quake2? I would, however, like to use icculus quake2 as my main
client due to its excellent graphics (when maxpak is used), compared to the
more standard like looking nocheat.

Am I out of luck, or did I miss a nice command?

Thanks for your help
Manfred

[mv007]

Hi,

Sorry for asking this question again.
Unfortunately, there were no replies so far. Does anybody know something
about my question, perhaps those who _make_ icculus quake2...
Or am I really restricted to a low resolution? (or to using another client,
like nocheat!?)

****

Is there _any_ way to change the console font size in icculus quake2?

I would like to use a higher resolution, like 1280x1024 - instead of my
usual 800x600.

BUT:
The console text gets so tiny that it is really hard to read - not good for
my eyes.

While quakeworld (quakeforge) has some -conwidth -conheight command line
options and while nocheat has a command "gl_scale) to easily solve that
problem. Quake2max also has a command "con_font_size".

In all these cases, you can easily change the console text size without
changing the high resolution.

Unfortunately, I couldn't find anything to achieve something like that in
icculus quake2? I would, however, like to use icculus quake2 as my main
client due to its excellent graphics (when maxpak is used), compared to the
more standard like looking nocheat.

Am I out of luck, or did I miss a nice command?

Thanks for your help
Manfred

[Brendan Burns]

Manfred,
(just so you don't get no responses again...) I don't actually know
the answer to
this question, but I can look into it when I get a chance. (or you
could look
into it if you wanted to...) My suspicion is that they are using a
bitmapped
font which means that changing the scale will be somewhat challenging
(you'll need to scale all of the images...) but I'm not sure.

thanks
--brendan

Post by mv007
Hi,
Sorry for asking this question again.
Unfortunately, there were no replies so far. Does anybody know
something
about my question, perhaps those who _make_ icculus quake2...
Or am I really restricted to a low resolution? (or to using another client,
like nocheat!?)
****
Is there _any_ way to change the console font size in icculus quake2?
I would like to use a higher resolution, like 1280x1024 - instead of my
usual 800x600.
The console text gets so tiny that it is really hard to read - not good for
my eyes.
While quakeworld (quakeforge) has some -conwidth -conheight command line
options and while nocheat has a command "gl_scale) to easily solve that
problem. Quake2max also has a command "con_font_size".
In all these cases, you can easily change the console text size without
changing the high resolution.
Unfortunately, I couldn't find anything to achieve something like that in
icculus quake2? I would, however, like to use icculus quake2 as my main
client due to its excellent graphics (when maxpak is used), compared to the
more standard like looking nocheat.
Am I out of luck, or did I miss a nice command?
Thanks for your help
Manfred
--
+++ Sparen Sie mit GMX DSL +++ http://www.gmx.net/de/go/dsl
AKTION f?r Wechsler: DSL-Tarife ab 3,99 EUR/Monat + Startguthaben

[Nicolai Haehnle]

Post by Brendan Burns
Manfred,
(just so you don't get no responses again...) I don't actually know
the answer to
this question, but I can look into it when I get a chance. (or you
could look
into it if you wanted to...) My suspicion is that they are using a
bitmapped
font which means that changing the scale will be somewhat challenging
(you'll need to scale all of the images...) but I'm not sure.

With OpenGL, scaling the bitmaps should be trivial. It'll look ugly for odd
scale factors, but the console font isn't exactly beautiful anyway.

cu,
Nicolai

Post by Brendan Burns
thanks
--brendan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://icculus.org/pipermail/quake2/attachments/20050112/571a9b73/attachment.pgp>

[Thomas J Fogal]

Post by Nicolai Haehnle

Post by Brendan Burns
Manfred,
(just so you don't get no responses again...) I don't actually know=20
the answer to
this question, but I can look into it when I get a chance. (or you=20
could look
into it if you wanted to...) My suspicion is that they are using a=20
bitmapped
font which means that changing the scale will be somewhat challenging
(you'll need to scale all of the images...) but I'm not sure.

With OpenGL, scaling the bitmaps should be trivial. It'll look ugly for odd
scale factors, but the console font isn't exactly beautiful anyway.

nod, keep in mind that scaling is slow though.

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:

glPushMatrix();
glScalef(1.0,1.0,-x);
re.DrawChar(...);
glPopMatrix();

in client/console.c. Or perhaps the mod might be appropriate in
M_DrawCharacter from client/menu.c.

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.

Hope someone else has more time for this than me.

-tom

[Manfred Vogelgesang]

Post by Brendan Burns

Post by Nicolai Haehnle

Post by Brendan Burns
Manfred,
(just so you don't get no responses again...) I don't actually

know=20

Post by Nicolai Haehnle

Post by Brendan Burns
the answer to
this question, but I can look into it when I get a chance. (or you=20
could look
into it if you wanted to...) My suspicion is that they are using a=20
bitmapped
font which means that changing the scale will be somewhat challenging
(you'll need to scale all of the images...) but I'm not sure.

With OpenGL, scaling the bitmaps should be trivial. It'll look ugly for

odd

Post by Nicolai Haehnle
scale factors, but the console font isn't exactly beautiful anyway.

nod, keep in mind that scaling is slow though.
I took a quick look but did not try hacking any code. This might be
glPushMatrix();
glScalef(1.0,1.0,-x);
re.DrawChar(...);
glPopMatrix();
in client/console.c. Or perhaps the mod might be appropriate in
M_DrawCharacter from client/menu.c.
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.
Hope someone else has more time for this than me.
-tom

Thanks to you and all that replied or are going to answer. :)

I hope, nobody misunderstood my question:
I just mean scaling the text of the console messages, not necessarily the
hud, like the weapons, ammo display etc.

You think, this slows things down?

Well, with gl_scale set from 1 (default) to 2 in "nocheat" I don't notice
ANY such slowdown. Actually, I can use very high resolutions and still have
an easily readable console (all those messages by other players); of course,
there should be no scaling whatsoever of the game itself!

You are right in so far as some scaling factors cause ugly fonts:
factors like 1.5 or 1.7 or 1.92 etc.

But the integers 1, 2, 3... work fine - and again, no (noticeable) slowdown
at all.

Perhaps someone still has an idea or (god forbid, haha) even writes a quick
patch - if he has time and interest and IF there is really nothing in the
current code to resize the console/players text messages.


Thanks for your help
Manfred

[Nick Warne]

Post by Manfred Vogelgesang
Perhaps someone still has an idea or (god forbid, haha) even writes a quick
patch - if he has time and interest and IF there is really nothing in the
current code to resize the console/players text messages.

I have replaced the conchar.pcx file (found in *.pak files) before for better
colours - perhaps you could replace it with one with bigger font size - but
not sure what the code expects the format of the size to be.

Nick

[Nicolai Haehnle]

Post by Thomas J Fogal

Post by Nicolai Haehnle

Post by Brendan Burns
Manfred,
(just so you don't get no responses again...) I don't actually know=20
the answer to
this question, but I can look into it when I get a chance. (or you=20
could look
into it if you wanted to...) My suspicion is that they are using a=20
bitmapped
font which means that changing the scale will be somewhat challenging
(you'll need to scale all of the images...) but I'm not sure.

With OpenGL, scaling the bitmaps should be trivial. It'll look ugly for odd
scale factors, but the console font isn't exactly beautiful anyway.

nod, keep in mind that scaling is slow though.

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

It's true that the number of fragments that need to be processed increases
linearly with the area of a polygon. But when you scale the size of the
quads that are used to render the console, you automatically *reduce* the
number of quads. The total area of the console remains exactly the same,
and therefore the number of fragments and pixel data bandwidth remains the
same.
In fact, you're even reducing the number of vertex transformations (because
there are fewer quads to render), so if anything, it should be *faster*!

Post by Thomas J Fogal
I took a quick look but did not try hacking any code. This might be
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
call has to be glScalef(factor, factor, 1.0); or similar.
Also, changing the matrix for every character drawn is insane. Push and
scale *before* all console rendering, then pop after all console rendering
is finished.

Post by Thomas J Fogal
in client/console.c. Or perhaps the mod might be appropriate in
M_DrawCharacter from client/menu.c.
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.
HUD and GUI-related things don't use lighting anyway. And even if they
*did* use lighting, the slowdown argument would still be wrong.

cu,
Nicolai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://icculus.org/pipermail/quake2/attachments/20050113/37337854/attachment.pgp>

[Thomas J Fogal]

<snip>

Post by Manfred Vogelgesang

Post by Thomas J Fogal

Post by Nicolai Haehnle
With OpenGL, scaling the bitmaps should be trivial. It'll look ugly for

odd

Post by Nicolai Haehnle
scale factors, but the console font isn't exactly beautiful anyway.

nod, keep in mind that scaling is slow though.
I took a quick look but did not try hacking any code. This might be
glPushMatrix();
glScalef(1.0,1.0,-x);
re.DrawChar(...);
glPopMatrix();
in client/console.c. Or perhaps the mod might be appropriate in
M_DrawCharacter from client/menu.c.
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.

<snip>

Post by Manfred Vogelgesang
I just mean scaling the text of the console messages, not necessarily the
hud, like the weapons, ammo display etc.

nod. I hoped (maybe guessed is a better word) that DrawChar was only
used for console text messages, but it may be used for the in-game hud
too. I'm guessing/banking on the in-game hud being a series of images,
though.

Post by Manfred Vogelgesang
You think, this slows things down?
Well, with gl_scale set from 1 (default) to 2 in "nocheat" I don't notice
ANY such slowdown. Actually, I can use very high resolutions and still have
an easily readable console (all those messages by other players); of course,
there should be no scaling whatsoever of the game itself!

yes and no. technically, most cards will have a harder time rendering
scaled geometries, because of the way most rendering pipelines are
structured. That being said, its also probable you won't notice either
way. Quake2 is relatively 'light' in terms of graphics, so a modern
card can easily afford to run through its pipeline more than twice
within a single monitor refresh.

Post by Manfred Vogelgesang
factors like 1.5 or 1.7 or 1.92 etc.
But the integers 1, 2, 3... work fine - and again, no (noticeable) slowdown
at all.

I've no firsthand evidence of this but it makes sense. Q2 fonts are
bitmapped, IIRC, and thus if you scale them to obscene proportions they
will look blocky/aliased.

Post by Manfred Vogelgesang
Perhaps someone still has an idea or (god forbid, haha) even writes a quick
patch - if he has time and interest and IF there is really nothing in the
current code to resize the console/players text messages.

I'll try and see what my push/pop idea results in.

-tom

[brendanburns]

In the spirit of moderating reasonable debate and interaction, I would
encourage people not to use phrases like:
"You don't seem to have a clue what you're talking about"
that insult other participants on the list.

Its perfectly fine (and correct) to point out errors in what people say if you
think they exist. But insulting people a) doesn't encourage them to
participate in the future b) just isn't very professional.

I would encourage everyone to think about this when they're
writing to this list.

Thanks!
--brendan

[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.
<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>

Post by Thomas J Fogal
I took a quick look but did not try hacking any code. This might be
=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.

Post by Thomas J Fogal
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

[Nicolai Haehnle]

Post by 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.

Maybe I shouldn't be so honest in the future. Anyway, I did revise my
opinion based on your last mail, and I do apologize.

Post by Thomas J Fogal
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.

Maybe I should have explicitly mentioned that I was talking about rendering
text. It's true that scaling a mesh does not change the number of
primitives in the mesh. But as you have basically said yourself (see the
overlapping characters thought): When you increase the size, in pixels, of
characters on the screen, while keeping the resolution the same, there are
fewer characters visible on the screen at the same time. That is all.

Post by Thomas J Fogal
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"

[snip lots of quotes]

That's true, but I'd be *very* surprised if Quake 2 used OpenGL lighting
except perhaps for mesh models. Therefore my labeling it as "wrong",
because the scaling itself comes for free as far as vertex pipeline
performance is concerned.

cu,
Nicolai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://icculus.org/pipermail/quake2/attachments/20050114/0d116a68/attachment.pgp>

[Thomas J Fogal]

<snip>

Post by Thomas J Fogal

Post by Manfred Vogelgesang
Perhaps someone still has an idea or (god forbid, haha) even writes a quick
patch - if he has time and interest and IF there is really nothing in the
current code to resize the console/players text messages.

I'll try and see what my push/pop idea results in.

Just an update, this didn't work out for me at all :(

The text stopped appearing after I made the modification. There are
more complicated things going on, re.DrawChar appears to also be passed
the location of the text to be drawn. I would think since we're
changing the size of text, things needs to be spaced more and thus this
becomes more complicated. Logically I'd expect to see overlapping text
instead of no text, though... *shrug*. I'm lost.

Sorry but this has progressed beyond my 'interesting 15 minute hack'
limit allocated for it :P. If anyone else wants to have a stab, since
text stopped appearing for me after changing code around re.DrawChar in
client/console.c, that seems like a pretty good indication that I was
changing the right code... just in the wrong way =).

Good luck,

-tom

[Karen Pouelle]

Post by mv007
Hi,
Is there _any_ way to change the console font size in icculus quake2?

...

Post by mv007
While quakeworld (quakeforge) has some -conwidth -conheight command line
options and while nocheat has a command "gl_scale) to easily solve that
problem. Quake2max also has a command "con_font_size".

Version 0.25 (or somewhere around there) of Quake2MaX was ported for Icculus,
that was before the console scaling with the con_font_size. Many things have
been added to Quake2MaX since, so my suggestion to diff the 0.25 source
against later versions might be quite a task, but the code to add that
feature is in there... Comparing Quake2MaX changelogs might help you find
it and then all you'd have to do would be to splice it in to Icculus' 1.16
version.





























______________________________________________________________________
Post your free ad now! http://personals.yahoo.ca

[M. V.]

Post by Karen Pouelle

Post by mv007
Hi,
Is there _any_ way to change the console font size in icculus quake2?

...

Post by mv007
While quakeworld (quakeforge) has some -conwidth -conheight command line
options and while nocheat has a command "gl_scale) to easily solve that
problem. Quake2max also has a command "con_font_size".

Version 0.25 (or somewhere around there) of Quake2MaX was ported for Icculus,
that was before the console scaling with the con_font_size. Many things have
been added to Quake2MaX since, so my suggestion to diff the 0.25 source
against later versions might be quite a task, but the code to add that
feature is in there... Comparing Quake2MaX changelogs might help you find
it and then all you'd have to do would be to splice it in to Icculus' 1.16
version.

Hi,

unfortunately I am unable to even find the 0.25 source (or some of those
older versions), and even if I found it, someone else would have to be
willing to do the work (I lack knowledge and time to do something like
that).

Regarding the current quake2max source: There isn't even a changelog in
there and searching through the entire source archive I only get very
few results for "gl_scale" OR "gl_scal*" OR something like that (it's
only in glext.h).

The 0.16 version of icculus quake2 is unusable to me, by the way - the
mouse is totally crazy when using glx, and even with sdlgl it works
worse than before (with 0.15).


Manfred

[Nick Warne]

Post by M. V.
The 0.16 version of icculus quake2 is unusable to me, by the way - the
mouse is totally crazy when using glx, and even with sdlgl it works
worse than before (with 0.15).

Strange - 0.16 sdl works great for me, as did 0.14 (0.15 went wonky with the
sound, but that might be my builds).

I use xorg on Slack 10 (kde 3.3.2 with GEForce 4 MMX 440), and here are my
mouse settings from xorg.conf:


# Core Pointer's InputDevice section

Section "InputDevice"

# Identifier and driver

Identifier "Mouse1"
Driver "mouse"
Option "Protocol" "IMPS/2"
Option "Device" "/dev/mouse"
Option "Buttons" "5"
Option "ZAxisMapping" "4 5"

Option "Emulate3Buttons"

EndSection

For me, it works perfect - better than windows!

Nick