|
al_load_bitmap_font |
duncan perham
Member #15,403
November 2013
|
So im playing arround with this function. But the documentation is very limited. Ive kind of got something working, but nothing usable at the moment. Can someone please tell me how the bmp is meant to be layed out, I get it that is layed out in ASCII, 32(spc),(33)!,(34)",(35)# etc. But how is it layed out in the file and what are the sizes etc, at present I have it layed out as a 64x64 images, in a grid of 16x16. (1024X1024). which is 256 characters. but I guess im only trying to get 128. Any advice on how to lay it out and size restrictions would be nice. |
Kris Asick
Member #1,424
July 2001
|
You actually don't lay it out as a grid. Here's an example of an Allegro 4 font I've made (which technically will work in Allegro 5 though it may look odd for reasons I will go into in a moment): {"name":"610264","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/0\/7077f288e49e047797eae8cd7c1f65a1.png","w":640,"h":480,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/0\/7077f288e49e047797eae8cd7c1f65a1"} ...and here's how it works:
And... that's all there is to it! Just remember to have each glyph surrounded by the framing background colour and it should work fine! --- Kris Asick (Gemini) |
duncan perham
Member #15,403
November 2013
|
Thanks for that, thats cleared up a few questions, now to see if I can get it to work . |
Elias
Member #358
May 2000
|
Are you sure the background color is copied over into the font? As far as I know the actual texture uses complete transparency instead so there can be no bleed and it therefore does not matter at all which color you use. -- |
Kris Asick
Member #1,424
July 2001
|
Elias said: Are you sure the background color is copied over into the font? As far as I know the actual texture uses complete transparency instead so there can be no bleed and it therefore does not matter at all which color you use. It actually depends on how the video card reads texture data at the edges of a polygon when drawing it but yes, bleed can occur in this case because the individual glyphs of a bitmap font are not separate textures, rather they are pieces of the larger texture they came from, thus the boundary pixels used to define the font glyphs in the first place are still there. Bleed ONLY occurs with any texture filtering other than nearest neighbour, as all other methods blend between nearby texels, whereas nearest neighbour is incapable of exceeding the boundaries set when pulling from the source texture. --- Kris Asick (Gemini) |
Elias
Member #358
May 2000
|
Hm, according to the source code the original bitmap is not used though, so there should be nothing to bleed from... so this sounds like a bug. -- |
Kris Asick
Member #1,424
July 2001
|
Really? I know the font system doesn't create separate textures for each individual glyph as that would slow font rendering down tremendously, so... what does it do then? Does it copy the glyphs to a brand new blank texture to bypass the chance of any sort of bleed happening? The thing is, I always assumed A5's font system worked similar to the sub-bitmap system, and when you make sub-bitmaps of a larger bitmap with A5 and start doing scaling and rotating with texture filtering, you get bleed, so I assumed the same thing would happen with fonts and thus made my fonts accordingly. So... apologies if I'm wrong about the font system working the way I thought it did. --- Kris Asick (Gemini) |
Elias
Member #358
May 2000
|
It creates a copy of the bitmap you pass and calls al_convert_mask_to_alpha on that copy, with the color at position 0/0. -- |
Kris Asick
Member #1,424
July 2001
|
I didn't know al_convert_mask_to_alpha was a thing. Learn something new every day! Like today especially, I learned ALLLLLLLLL kinds of fun facts! ...99% of which are likely pure BS because APRIL FOOLS! --- Kris Asick (Gemini) |
|