Re: [AD] Old problems that still persist on Allegro 4.2 beta 3

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Fri, 2005-05-27 at 08:13 +0200, Evert Glebbeek wrote:
> > Hm, harder than I thought. The attached patch allowed me to do it,
> > otherwise grabber and dat would choke on the same files for which 4.0.3
> > grabber and dat work fine. Oh, and it's quite late, so in fact, I'm not
> > very sure about the patch..
> 
> Some quick thoughts, I'll have a closer look later today.
> 
> -   num = end - begin+1;
> +   num = end - begin;

> This looks wrong. A font that has a range of 32-32 has one character in it,
> a space. Beside which, the mono font code should also have a similar line
> to that one that would also need to be fixed if this is an error (but It
> think your patch is wrong here).

It seems, end is one past the last. Without the change, it always would
crash on the very last character. If I'm right, it sure is confusing, so
the proper way to fix it would be to fix it in all other places.
The .txt files with ranges use inclusive numbers, but the loading code
then adds one, in fonttxt.c:

end = strtol(end_str, 0, 0) + 1;

So do bitmap fonts, in fontbmp.c:

end = bitmap_font_count(bmp) + begin

I assume, it didn't really cause problems with bitmap fonts, since they
usually only contain one range, so unless you try to print exactly the
last character, it didn't matter.

> 
> +      /* load_bitmap_font makes the font start with character 32, so f2 is
> a
> +       * wrong font, we can't use functions like extract_font_range on it.
> +       * Instead, we transpose all characters so they have the correct
> range
> +       * again.
> +       */
> 
> I don't understand. Please explain.
> Also, the font loading code is not really different from the 4.0.3 font
> loading code, except that it's now in the library rather than the grabber.
> As far as I remember, fonts have always started at character 32. I
> certainly don't think you want to transpose it (turning upper case
> characters into lower case ones) before merging (in fact, you should *not*
> want to do that unless there's a bug in how merge_fonts() is implemented).
> 
> Could you explain a bit more what your patch is supposed to solve? To me,
> it looks more like it would introduce problems rather than fix any. :)

.txt fonts look e.g. like this:

font.bmp 32 127
font2.bmp 128 255

The version currently in CVS will now correctly load font.bmp, since it
has 96 characters in it, and they automatically start with 32, so the
range gets 32..127.

When it gets to the second line though, it sees the font has 128
characters, and maps them (wrongly) to the range 32..159. Then, it tries
to extract the range 128..255 out of the font with a range 32..159 - and
misses most of the characters.

So my work-around, after loading the font, I transpose it by
first_character - 32, so that means, it has the right range.

-- 
Elias Pschernig





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/