| Re: [AD] Old problems that still persist on Allegro 4.2 beta 3 |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> 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.
It is confusing, but looking at the source again, it looks you are right.
That means it has to be fixed in all places where it is referenced.
Depending on wether or not this bug was present in the old grabber code as
well, it may not be too much work to fix.
> .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.
Hmm... I would have expected the line in the .txt file to mean `extract
characters 128-255 from font2.bmp and add them to the font'. Obviously, it
doesn't (and with hindsight, that also makes sense, otherwise you need to
add a lot of dummy characters to a font with range 0x1000...)
> So my work-around, after loading the font, I transpose it by
> first_character - 32, so that means, it has the right range.
Right.
Evert