plib-devel

[Plib-devel] [PATCH] fntBitmapFont::puts(): set negative coordinates correctly (Part II)

[Melchior F. <mf...@us...>]

I had responded immediately after my first message showed up on the
list, but then I used the wrong mail address. And the bloody sf.net
server didn't complain, so it took me a while to notice. Here again:

The patch from yesterday wasn't complete: it hadn't considered, that
the same bug would happen in puts() after "\n", and also in putch().
The attached patch fixes that, too.

But I'm not sure if I did it right. I set the RasterPos only with 2i,
assuming that the z-component would be zero in all cases. Is this true?
Or should I rather have used:  glRasterPos3f(0.0f, 0.0f, curpos[2])
in all three cases instead?

m.

Re: [Plib-devel] [PATCH] fntBitmapFont::puts(): set negative coordinates correctly (Part II)

[Bram S. <br...@sa...>]

Melchior FRANZ wrote:
> I had responded immediately after my first message showed up on the
> list, but then I used the wrong mail address. And the bloody sf.net
> server didn't complain, so it took me a while to notice. Here again:
> 
> The patch from yesterday wasn't complete: it hadn't considered, that
> the same bug would happen in puts() after "\n", and also in putch().
> The attached patch fixes that, too.
> 
> But I'm not sure if I did it right. I set the RasterPos only with 2i,
> assuming that the z-component would be zero in all cases. Is this true?
> Or should I rather have used:  glRasterPos3f(0.0f, 0.0f, curpos[2])
> in all three cases instead?

Uh... I think this depends wether z-tests are done when writing the
text?

If z-test is off, and z-buffer writes are off, my guess is that
the z coord does not matter.

In any case, I think that these issues warrant a more
complex fnt test in examples. Do you have a nice fnt tst
program for us we can use in examples/src/fnt ?
(one with negative coords of course)

    Bram

> 
> m.
> 
> 
> ------------------------------------------------------------------------
> 
> Index: fntBitmap.cxx
> ===================================================================
> RCS file: /cvsroot/plib/plib/src/fnt/fntBitmap.cxx,v
> retrieving revision 1.2
> diff -u -p -r1.2 fntBitmap.cxx
> --- fntBitmap.cxx	4 Jul 2005 14:58:54 -0000	1.2
> +++ fntBitmap.cxx	5 Jul 2005 06:00:35 -0000
> @@ -71,7 +71,8 @@ void fntBitmapFont::putch ( sgVec3 curpo
>      if (c == '\n') {
>  	curpos[1] -= height;
>      } else {
> -	glRasterPos3fv(curpos);
> +	glRasterPos2i(0, 0);
> +	glBitmap(0, 0, 0, 0, curpos[0], curpos[1], NULL);
>  	int i = (GLubyte) c - first;
>  	if (i >= 0 && i < count) {
>  	    glBitmap(data[i][0], height, xorig, yorig, (float) data[i][0], 0, data[i] + 1);
> @@ -90,7 +91,8 @@ void fntBitmapFont::puts ( sgVec3 curpos
>  	if (s[i] == '\n') {
>  	    curpos[0] = x0;
>  	    curpos[1] -= height;
> -	    glRasterPos3fv(curpos);
> +	    glRasterPos2i(0, 0);
> +	    glBitmap(0, 0, 0, 0, curpos[0], curpos[1], NULL);
>  	} else {
>  	    int j = (GLubyte) s[i] - first;
>  	    if (j >= 0 && j < count) {

[Plib-devel] Re: [PATCH] fntBitmapFont::puts(): set negative coordinates correctly (Part II)

[Melchior F. <mf...@us...>]

* Bram Stolk -- Tuesday 05 July 2005 12:56:
> In any case, I think that these issues warrant a more
> complex fnt test in examples. Do you have a nice fnt tst
> program for us we can use in examples/src/fnt ?
> (one with negative coords of course)

Umm ... FlightGear would be too big, no?  :-}
Unfortunately, this is my only test app so far.

m.

[Plib-devel] Re: [PATCH] fntBitmapFont::puts(): set negative coordinates correctly (Part II)

[Melchior F. <mf...@us...>]

* Bram Stolk -- Tuesday 05 July 2005 12:56:
> If z-test is off, and z-buffer writes are off, my guess is that
> the z coord does not matter.

I don't think that z is useful for fntBitmapFonts at all. Their main
advantage is the non-blurry, sharp look. They would probably become
illegible with any non-zero z. Also, positions of type float don't
seem to make much sense. I know that this is necessary for inheritance
from fntFont, but they should probably be explicitly converted to integers.

And then: fntBitmap don't consider the gap value, which makes setGap()
and getGap() useless. I'd need the gap, though, and added it where
necessary. But here again the question arises: should gaps be allowed
to be floats? I'd convert them to integers before applying. I'll
provide another patch if I know the opinion of the plib developers
on this int/float question.

m.

Re: [Plib-devel] Re: [PATCH] fntBitmapFont::puts(): set negative coordinates correctly (Part II)

[Bram S. <br...@sa...>]

Melchior FRANZ wrote:
> * Bram Stolk -- Tuesday 05 July 2005 12:56:
> 
>>If z-test is off, and z-buffer writes are off, my guess is that
>>the z coord does not matter.
> 
> 
> I don't think that z is useful for fntBitmapFonts at all. Their main
> advantage is the non-blurry, sharp look. They would probably become
> illegible with any non-zero z. Also, positions of type float don't
> seem to make much sense. I know that this is necessary for inheritance
> from fntFont, but they should probably be explicitly converted to integers.

huh... either I don't understand this, or this is incorrect.
I'm pretty sure that z-testing for glWritePixels and glBitmap is
available if the programmer does not disable it, and fragments are
written with current z-coord. I dont see why they would become
illegible with non zero z.

bitmap pixels are treated similarly to polygon fragments.

Although unusual, my guess is that text with depth, e.g. menus
in the fog :-) is perfectly feasible.

I've commited the 2i version, but the 3f is more correct I think.
So I think we just broke the 'fonts with depth' in plib :-(
I suggest going back to 3 components, thus:
glRasterPos3f(0,0,curpos[2])

Also, I extended the font test with the special case of negative
coords.

   Bram

> 
> And then: fntBitmap don't consider the gap value, which makes setGap()
> and getGap() useless. I'd need the gap, though, and added it where
> necessary. But here again the question arises: should gaps be allowed
> to be floats? I'd convert them to integers before applying. I'll
> provide another patch if I know the opinion of the plib developers
> on this int/float question.
> 
> m.
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel

[Plib-devel] depth of fonts

[Bram S. <br...@sa...>]

Bram Stolk wrote:

> So I think we just broke the 'fonts with depth' in plib :-(

...where it not for the fact that the start3f() is missing,
and we only have a start2f(), so it was never available in
the first place.

text with depth would need an extra member on fntRenderer class.
If this is desired, I'll add support for it, if not, we can leave
this as is, and have a working fnt system that works with
negative coords, but not with depths != 0.

Steve's pick I would say.

   Bram

Re: [Plib-devel] depth of fonts

[Bram S. <br...@sa...>]

Argh... sorry


It turns out that indeed I dont understand these matters.

start3f() is available, yet when z-coord is not null,
the text is not visible.

   Bram

Re: [Plib-devel] Re: [PATCH] fntBitmapFont::puts(): set negative coordinates correctly (Part II)

[Steve B. <sjb...@ai...>]

Melchior FRANZ wrote:
> * Bram Stolk -- Tuesday 05 July 2005 12:56:
> 
>>If z-test is off, and z-buffer writes are off, my guess is that
>>the z coord does not matter.
>
> I don't think that z is useful for fntBitmapFonts at all. Their main
> advantage is the non-blurry, sharp look. They would probably become
> illegible with any non-zero z.

No - that's not how glBitmaps work.

You give it *one* vertex position in x,y,z - which is then transformed
as if it was an ordinary vertex (and culled if it's off-screen).

When you render the bitmap, it's positioned at that vertex and rendered
at 1:1 pixel size and parallel to the edges of the screen no matter what.

So the size and resolution of the bitmap are independent of Z - perspective
only affects the position of the corner of the bitmap - not the size of
the bits when rendered onscreen.

The only time Z might matter would be if you still had perspective
enabled (which you don't in PUI) - then it's possible for the Z coord
to come out closer than Znear or further than Zfar - which would result
in the position command being set 'offscreen' and the bitmap not being
drawn.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

[Plib-devel] Re: [PATCH] fntBitmapFont::puts(): set negative coordinates correctly (Part II)

[Melchior F. <mf...@us...>]

* Steve Baker -- Wednesday 06 July 2005 03:48:
> When you render the bitmap, it's positioned at that vertex and rendered
> at 1:1 pixel size and parallel to the edges of the screen no matter what.
> 
> So the size and resolution of the bitmap are independent of Z - perspective
> only affects the position of the corner of the bitmap - not the size of
> the bits when rendered onscreen.

OK. That was my original assumption. So, bitmap fonts/characters are done
in integer operations only. glBitmap's "width" and "height" arguments are already
integers, but how is the position handled? Automatically converted to integers
by OpenGL? And the "gap" value (that still waits for implementation)? This
is a float now, but should internally really be an integer, too, right?
Otherwise we'd get a problem with getBBox, which does internally work with
integers only.

As I said in a previous message: I would have sent a patch for the gap
bug (i.e. the fact that plib pretends to offer gap functionality for
fntTexFont, but doesn't implement it). But I don't know how to deal with
this int/float thing. In the worst case I work around the bug and simply
apply the desirable amount of gap to the compiled bitmap font. I just
need to know.

m.