I was using al_draw_scaled to draw this string that has a 'á' NON ASCII Character, this char was not defined on my bitmap font.

I wanted to draw the other characters instead got this 'error'

Undefined behavior is undefined...

So, don't do that?

What function are you using? al_draw_scaled ??
Please can you post some more code?

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'

So use a bitmap font with those characters in it.

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 UTF16 then á will be encoded as \xe1\x00 and the "\x00" byte will terminate the string.

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

See Al grab font from bitmap :

https://liballeg.org/a5docs/trunk/font.html#al_grab_font_from_bitmap

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

There is my Font that i was using to draw my text, may the 'fallback' character has a code on ASCII to set up with al_grab_font_from_bitmap. Or maybe this is the problem of an unicode that has the null character \x00.

I wanted to show the name of the button of the joystick that a user want to use in my game to configure the game controls, but imagine for example in spanish the button name return "Botón 5" with ó on another encoding, that allegro cannot find the ó and print at least something like "Botn 5", to doesnt break that controls configuration is working!

I see it too. I will investigate.

You could write a program to read in a ttf file, and output a bitmap font. In theory it should be simple enough.

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: