Undefined behavior is undefined...

So, don't do that?

I'm using the function al_draw_text to draw the text _V_text with my font _V_font that was my bitmap font.

The problem is that i wanted to draw the text that the following joystick functions return me, and this values (for example in spanish) return me non-ascii characters like 'Botón 1'

I tracked through the code a bit and it seems that Allegro uses only the ANSI variants of the APIs (I am assuming you're using Windows?) so it probably is returning the names with characters from whatever code page you are using. (presumably 1252 Ansi Latin 1)
So, as Edgar says, if you want ó to appear you need a glyph for it in your bitmap font, but
you also seem to be saying that it doesn't print out any subsequent characters once it's hit an invalid character (looking at the megaman screenshot). If so, this might be a bug; Allegro should print a 'fallback' character whenever it doesn't have a glyph but then carry on with the rest of the string.
Can you post your font bitmap ?

If the encoding is UTF-16 then all ascii characters will be encoded as <something>\x00 and the \x00 byte will terminate the string.

Alright but has anyone go a bitmap suitable for feeding to al_grab_font_from_bitmap?

I see it too. I will investigate.

What happens is:
1. Get the control name via al_get_joystick_button_name or whatever
2. (assuming you're on windows) Allegro uses the Windows ANSI API (not the unicode one) and returns a string using the active code page (assuming it's windows-1252)
3. This string may contain characters in the range 128-255 - for example ó which is 0xD3
4. Calling al_draw_text (other text functions end up in the same place anyway)
5. Calls al_ref_cstr on the text to create a UTF-8 string
6. Calls al_draw_ustr on the UTF-8 string
7. Calls font->vtable->render which is color_render in font.c
8. Uses al_ustr_get_next to step through the string and renders each glyph.

Unfortunately al_ref_cstr does not 'create a UTF-8 string', it just references the data in a C string as if it were UTF-8. So, when al_ustr_get_next comes to the 0xD3, it sees this as an invalid UTF-8 code, returning '-2', and this in turn causes color_render to stop. Hence no more characters are printed.

To solve this, you would need to use the Win32 API to convert the windows-1252 strings to genuine UTF-8, or Allegro would have to be modified, either:

• Use unicode APIs for the joystick

• Cause color_render to skip invalid UTF-8 sequences (printing the 404 character)

In any case the docs for al_draw_text and friends should be a bit more specific on the input - they take UTF-8 and not just any C-string.

If anyone has any more thoughts please post them - might be worth filing an issue on github for this.

Example program:

Output: