Emoji in codea 4

I like using emojis as placeholder graphics :butterfly::sweat_smile:
It seems codea 4 is currently missing emoji support.

quick test:

-- Modern
function setup() 
    print("console emoji test:🐛")

function draw() 
    background(40, 40, 50)
    text("text emoji test:🐛",WIDTH/2,HEIGHT/2)  

I see a rectangle shape instead of an emoji in the console and in the program itself.

Tried the above code and no emoji’s show for me either.

Yeah the Codea 4 text rendering is not using the iOS native renderer which handles emoji. We will be doing a version of text() and the console that supports this

@Amber - I know it’s not built into Codea but you can access emoji graphics. I wrote a couple of projects to make use of it. Will post one later, I just need to check it out on V4 on my pad.

Edit: @amber, sorry pulled out two ways of firing up emojis in V3 but neither worked. Looks like they both used the V3 routines to display. I’ll have to wait for the V4 update for those projects too.

one way to get it working in c4 right now might be using the objc runtime? i haven’t tried it just an idea

but an other way if waiting is too long would be to implement a bitmap font and add emoji support through a keymap with actual images and codes for the emoji

In response to this I spent today adding support for native text rendering. It still needs some work to handle all the text formatting options correctly but the basics are all there:

    text("漢🤩字", WIDTH/2, HEIGHT/2)

Using attributed strings we could potentially support some of the rich text tags that the regular text rendering has but for native text


That looks really neat @John. Will it be rolled out with the next V4 upgrade?


TEXT_NATIVE is a new constant that I have introduced that can be used as an option in the style.textStyle() command to switch the renderer over to native-style text, which is rendered by the operating system, rather than by Codea. This gives you access to all the iOS native text rendering features (Emojis, Arabic and Asian symbols, and anything else it supports)

1 Like

Is there a reason to keep the original Codea text rendering?

Sure. It uses a different type of text rendering technique (a font atlas of signed distance field glyphs) which gives you the following benefits:

  • faster (no extra render-to-texture step)
  • less memory (native requires a texture large enough for each instance of text to be rendered)
  • cross platform
  • potential support for custom shaders
  • rich text tags and glyph callbacks allowing for each glyph to be cutomised for things like animated dialogue text (we may add this to native down the road as well)

Given all these differences I think its worth keeping around, although maybe native should be the default option

1 Like

Sounds like Codea 4 will be a game changer.

1 Like

@dave1707 @sim @John - found an issue here but not sure you can do much about it. It’s for V3 latest beta so posted here as it’s part of the V4 beta. An error was reported as a missing bracket but the brackets were correct, what was missing was the ‘*’ multiply character. Image attached.

It’s probably because the parser doesn’t know if a * or a - or + or any other possible operator is missing, what it does know is digits followed by letters doesn’t make sens in lua grammar.

1 Like

@moechofe - yes exactly. Are brackets operators?

My problem partially stems from the red error line indicator often points to the wrong line. So, not finding a bracket issue on the line I looked in the preceding lines. Eventually I returned examining the line for the variable tw and bingo - noted the error.

That’s why I noted that it would be difficult to parse.

Parenthesis are not operator but allow to group expression. The parser try to find the end for this expression, that’s why it asking about a ). It actually don’t care about what is coming next.