I would like to be able to display emoji characters in a text object but all I see is the 'tofu' box

I have also tried setting the font to one that I know supports the emoji in question


with the same result as the default as well as SetTextFont(s, 0 )

I can see that I am successfully setting the font.

I am using AppGameKit IDE 2022.04.01 (and I don't see anything expanded support in the later version description)

Any suggestions?

emoji characters for what I learned are giff images, so In my understanding to add them to your app you need to have a collection of emoji images and load them in your code.

So what you can do is load a font but instead of characters make each frame a animated giff frame.

I have done this myself to test it last year and I loaded my font into gimp and it took hours but I had a image font instead of characters .

But there is probably a easy way to do this and I am not sure.

no, emoji characters are Unicode text characters.

never played above 255 but this is no help:

what characters are the emojis anyway?

meanwhile, using a strictly "emote" font was only partially successful?


otherwise, im surprised that AppGameKit does anything > 255. but, i'd say build your own limited font image or keep looking for a ttf/otf with just common characters + emojis?

alternatively, find the characters in your text object to get their x,y and stamp an emoji sprite on top? (we can't set an individual character's font that i can see).

[s](attachments have yet to show...)[/s]

thanks but I don't want a kludge font ala wingdings as I want to be able to mix emojis in with other text. This is why Emojis were invented.

Emojis are Unicode characters, most Unicode characters use more than one byte., for example, the UTF-8 encoding for sun emoji is F0 9F 94 85. UTF-16 encoding is D83CDDF5. The decimal value is 127909

To understand this stuff start with some Asian characters. These also fails in AGK. It appears there is no multibyte support in AGK.

I'm sorry, emotions are giff images added as a package, my mistake. You are correct, Emojis are Unicode characters.

I was thinking about emotions not Emojis .

Maybe this google font

blink0k

That is exactly what I was saying in my first post lol. But with giff image's.

or


In any case, you need to use an additional font with emotions, because now you will have a composite text from different lines that have the desired font installed, since there is no access to change the font for individual characters in the agc. Or build your own font, otf or ttf

pretty sure dale wants native support that we dont have.

i'm almost up for the "work around" challenge but i might have something else on my plate soon, so gonna sit it out for now.

yes, looking for true support, not a font that places some collection of graphics at arbitrary code point positions (like Wingdings), so that they can be used along with other text characters.

yes, looking for true support, not a font that places some collection of graphics at arbitrary code point positions (like Wingdings), so that they can be used along with other text characters.

Did you try the font?

well the landing page for Emoto Emoji lets you try text and it cant display ASCII text, so it is useless to me.

I also did not download Font Awesome 5 Pro-Regular-400.otf because I already have fonts that contain the characters I want, both on Windows and Android.

What caught me eye though is the code:


which shows that 16 bit code points work. I wondered if using chr() might work better so I tried ch() and compared them to literal strings and they match. This means there is no problem getting the Unicode characters into strings in AppGameKit, and it does not choke on them at all, for example



What fails is when the text gets rendered, a rectangle is shown (known in the industry as tofu) which is typically what happens when the font in use does not have that glyph. This is however, happening even when I explicitly load a font that has that glyph.

This may simply be a rendering bug in AGK.

icon$=chr(val(char$,16))

Your always getting the same value as char is always 16

he was converting from a string of Hex character to base 10

otherwise, im surprised that AppGameKit does anything > 255.

Because UTF-8 only supports 255. Emojis aren't represented by a single utf8 byte, but by several. So unless AppGameKit supports something like UTF-8 mb4 then I don't see it working for you.

Because UTF-8 only supports 255.

Totally false statement.

Emojis aren't represented by a single utf8 byte, but by several.

True. As stated earlier: the UTF-8 encoding for sun emoji is F0 9F 94 85.

Agreed, AppGameKit does not seem to support full range of UTF-8 characters. It does not even handle Japanese characters.

UTF-8 only supports a single byte per character, so how would it handle above 255?

UTF-8 only supports a single byte per character, so how would it handle above 255?

UTF-8 does not just use one byte for all characters, it uses one byte for some characters (the first 128), for others it uses two, three, or four.

See https://en.wikipedia.org/wiki/UTF-8

I think based on what I read here there is some confusion between can support up to 4 bytes, versus exclusively uses all 4 bytes? IDK for certain but I do see references in various google results to mb 3/4 so perhaps UTF-8 on its own negates the rest? This is what I think Phaelax is eluding to? ie when talking about it to account for software that does not fully implement all 4 bytes versus a fully supported software that auto decodes it all. Essentially, in a case where UTF-8 is not implemented beyond 1 byte, it does not force a name change from UTF-8 therefore the term is not directly tied to exclusivity. If any of this is true you are both right, but what Phaelax states is more accurate where AppGameKit is concerned, which is not the exact reason as such but implies there has been no need so far to flesh out implementation to support mb 2, 3 & 4?

As for Japanese, I am more comfortable with DBPro, in which case we would load a font with an additional value for charset, example "Arial",128. But then you would have to go and find the special characters for the IDE text. "?_?[?N?x?[?V?b?N" is similar to what would be needed(translates to Dark Basic as something like Da - ku be - si ? ku as there are no direct words for translation but this is nearest), the output in the executable/player for DBP would indeed be katakana characters. This method does not appear to be an option for AGK. Then again I am not 100% familiar with AppGameKit, only partially. [s]Also the "special characters" I just detailed are not 100% correct[/s], there has been some change with font support in the forum so they no longer show as they should...the following link shows this difference and is being covered in DBP while discussing GG and DBP making it a difficult task to find with specific searches such as Japanese/katakana. In the DBP case there was a point in time as per the link where katakana was implemented but was far from obvious and required the font demo in order for a long winded process to be worked out(which no doubt could be simplified - however I only spent a few hours on it and never touched it again). Perhaps implementation beyond 1 byte is there and just not obvious how to achieve desired results, certainly not the same way as DBP but perhaps another way? For example I have simply just gone through the text command list but in AppGameKit and there is an option with AppGameKit for values above 128 in ascii. It involves providing a font image(settextdefualtextendedimage). I think you should look into that for Japanese at least. Put it this way, you know what options you have, you will have to live with them or force TGC into full implementation, in which case the forums might not be the best place for that. But here is the thing, if no decent response is ascertained from forum or discord requests then the smartest thing to do would be to contact TGC and ask them directly. You may even get an exact reason for lack of full implementation which if DBP is anything to go by it might be the IDE itself forcing the limitation - note in the link the expected coding did not work, special characters had to be sought instead. By using a font image as suggested you should be able to achieve desired results for text.

All that said I do feel at this point that UTF-8 can support up to 4 bytes but is not exclusive to it. If it was, then this thread would have no need to exist right? ie it would already have been implemented but in the expected way, I doubt it will ever be as simple as one might think! If additional ascii characters can only be dealt with by a font image provided by the user as the help file states, then it only seems logical that there is a different way to deal with any other UTF-8 characters within AGK...a point eluded to earlier.

It may be noted the use of ? throughout my post - this is because I am asking not telling.

Edit: I have put strike through on an earlier statement, it would appear that only in the input box the text does not show correctly prior to posting! In fact it is only the hidden spacing that is an issue.

Edit 2: the link I forgot! https://forum.thegamecreators.com/thread/213618?page=4#msg2558084