3 ms·

Assuming that is true, it is an oversight. There is no actual technical limitation. I am confident if Godot sees usage as a GUI/app framework, they will take c

Assuming that is true, it is an oversight. There is no actual technical limitation. I am confident if Godot sees usage as a GUI/app framework, they will take care of that.

chii 6y ago
it's too late for the engine to "take care of it" when the problem presents itself - because there are existing tooling and frameworks that already fixes this problem (such as native widgets, or electron). so godot will only see usage as a GUI framework for the use cases that won't see emoji or non-english IME.
- jfkebwjsbx 6y ago
  Handling Unicode and input is not anything that breaks any design. Mentioning Electron to solve Unicode is like thinking about a bulldozer when you need to unclog your toilet.
jariel 6y ago
Surprisingly, they won't. Text input and manipulation is so incredibly ugly and hard, that basically nobody cares it enough to to it really well. Unicode to start is complicated. Then you have things like bidirectional text. Line breaking is complicated. There are no accepted practices for a lot of use cases. Hyperlinks. Embedded content like images. Copying/inserting html and other formats. Styling content. Rendering 100 000 lines of styled content without screwing up user input. Line-heights. Tabs. Font definitions that are ambiguous an inconsistent (a lot of font tables today still don't provide enough space for accents on capital letters, think Swedish - so you have broken looking text or have to 'fake it'). Screwed up Kerning tables. No established standard for real pixelation and rendering - zoom in and you'll see font's can be rendered a variety of ways. Emojis, fat finger cursor navigation on mobile devcies, input managers. It's hard to describe how messy it gets because none of it is academic, it's not some scary-hard algorithm - it's just an incredibly ugly pile of cross-cutting code with a zillion little bits and pieces of corner cases. And a big one for gaming engines: they don't render text 'natively'. You basically have to create textures. Every big of text, it's own texture. How big is the texture for 100 000 lines of code? Big. This is actually one are where Qt falls flat. In the 'new and improved' Qt, they do everything in the GPU, if you try to load 100 000 lines of something the app will use up 1G of memory and puke. So then you have to magically code your way around it. All for what? Why would you want to render text in a gaming engine in the first place ... Then you discover that 'apps' and 'games' are really different things, and they use different tech for good reason. It only gets ugly when they really have cross paths.
- jfkebwjsbx 6y ago
  Nobody is saying Godot should implement their own text engine. There are several available ones they can use, or just pick whatever the platform offers. > Why would you want to render text in a gaming engine in the first place ... Just about every game needs text, including Unicode text. Every proper engine handles it.
  - jariel 6y ago
    " just pick whatever the platform offers." The platform does not offer anything. "Just about every game needs text, including Unicode text. Every proper engine handles it" No, what they do is paste a few characters on screen, handling a more common subset of Unicode. They don't come close to handling most of the things I described above. Not even Qt handles text well - Qt allows you to do some fun 3D things with text, but not you can't open 100K lines of formatted code like VSCode. Webkit is just as bad - MS had to invent 'Monaco' a huge layer on top to be able to manage text properly and it's kind of a hack. Simply put nobody does it well out of the box.
    - jfkebwjsbx 6y ago
      > The platform does not offer anything. All major platforms offer advanced text rendering support. How do you think Windows or macOS render their UI? > what they do is paste a few characters on screen, handling a more common subset of Unicode. Some games do that, in particular old ones or indies. Most games do actual text rendering properly. > you can't open 100K lines of formatted code You definitely can, but not naively. VS Code doesn't render all the text at once either and neither does any serious text editor.
      - jariel 6y ago
        "All major platforms offer advanced text rendering support." No, they don't realy. I think you're missing a few pieces in your understanding of what the platform does in these contexts The platform does not support text rendering for Qt and such platforms. They are rendered 'from scratch'. Some platforms offer some built in components, but even they are quite limited. No platform offers the ability, out of the box, to do for example, a 'coded editor' with properly highlighted syntax. Not even close. "Most games do actual text rendering properly." They are 'rendering text properly' for the extremely limited subset of text that they put on the screen. Have you ever used even a basic 'text editor' in a game? No? Because they don't even do that. " you can't open 100K lines of formatted code" "You definitely can, but not naively." 'Natively' means nothing on the context of 'browser'. If you mean to say 'the browser doesn't do it out of the box' - then ok, yes, we agree. And why not, because it's extremely hard? There are 0 comprehensive text APIs that are built upon gaming or even 3D engines today. Most of the barely handle basic text formatting. They put a few lines of text on the screen in a limited number of languages, and that's it. There are very, very few platforms that offer comprehensive text rendering, including Qt, GTK, and native platform components - they're basic. Providing comprehensive text API is not only something that has to be layered on top of those things - they also have to 'hack' those platforms to work around inherent bugs and limitations.

Assuming that is true, it is an oversight. There is no actual technical limitation. I am confident if Godot sees usage as a GUI/app framework, they will take care of that.

chii 6y ago

it's too late for the engine to "take care of it" when the problem presents itself - because there are existing tooling and frameworks that already fixes this problem (such as native widgets, or electron). so godot will only see usage as a GUI framework for the use cases that won't see emoji or non-english IME.

jfkebwjsbx 6y ago
Handling Unicode and input is not anything that breaks any design. Mentioning Electron to solve Unicode is like thinking about a bulldozer when you need to unclog your toilet.

jariel 6y ago

Surprisingly, they won't. Text input and manipulation is so incredibly ugly and hard, that basically nobody cares it enough to to it really well. Unicode to start is complicated. Then you have things like bidirectional text. Line breaking is complicated. There are no accepted practices for a lot of use cases. Hyperlinks. Embedded content like images. Copying/inserting html and other formats. Styling content. Rendering 100 000 lines of styled content without screwing up user input. Line-heights. Tabs. Font definitions that are ambiguous an inconsistent (a lot of font tables today still don't provide enough space for accents on capital letters, think Swedish - so you have broken looking text or have to 'fake it'). Screwed up Kerning tables. No established standard for real pixelation and rendering - zoom in and you'll see font's can be rendered a variety of ways. Emojis, fat finger cursor navigation on mobile devcies, input managers. It's hard to describe how messy it gets because none of it is academic, it's not some scary-hard algorithm - it's just an incredibly ugly pile of cross-cutting code with a zillion little bits and pieces of corner cases. And a big one for gaming engines: they don't render text 'natively'. You basically have to create textures. Every big of text, it's own texture. How big is the texture for 100 000 lines of code? Big. This is actually one are where Qt falls flat. In the 'new and improved' Qt, they do everything in the GPU, if you try to load 100 000 lines of something the app will use up 1G of memory and puke. So then you have to magically code your way around it. All for what? Why would you want to render text in a gaming engine in the first place ... Then you discover that 'apps' and 'games' are really different things, and they use different tech for good reason. It only gets ugly when they really have cross paths.

jfkebwjsbx 6y ago
Nobody is saying Godot should implement their own text engine. There are several available ones they can use, or just pick whatever the platform offers. > Why would you want to render text in a gaming engine in the first place ... Just about every game needs text, including Unicode text. Every proper engine handles it.
- jariel 6y ago
  " just pick whatever the platform offers." The platform does not offer anything. "Just about every game needs text, including Unicode text. Every proper engine handles it" No, what they do is paste a few characters on screen, handling a more common subset of Unicode. They don't come close to handling most of the things I described above. Not even Qt handles text well - Qt allows you to do some fun 3D things with text, but not you can't open 100K lines of formatted code like VSCode. Webkit is just as bad - MS had to invent 'Monaco' a huge layer on top to be able to manage text properly and it's kind of a hack. Simply put nobody does it well out of the box.
  - jfkebwjsbx 6y ago
    > The platform does not offer anything. All major platforms offer advanced text rendering support. How do you think Windows or macOS render their UI? > what they do is paste a few characters on screen, handling a more common subset of Unicode. Some games do that, in particular old ones or indies. Most games do actual text rendering properly. > you can't open 100K lines of formatted code You definitely can, but not naively. VS Code doesn't render all the text at once either and neither does any serious text editor.
    - jariel 6y ago
      "All major platforms offer advanced text rendering support." No, they don't realy. I think you're missing a few pieces in your understanding of what the platform does in these contexts The platform does not support text rendering for Qt and such platforms. They are rendered 'from scratch'. Some platforms offer some built in components, but even they are quite limited. No platform offers the ability, out of the box, to do for example, a 'coded editor' with properly highlighted syntax. Not even close. "Most games do actual text rendering properly." They are 'rendering text properly' for the extremely limited subset of text that they put on the screen. Have you ever used even a basic 'text editor' in a game? No? Because they don't even do that. " you can't open 100K lines of formatted code" "You definitely can, but not naively." 'Natively' means nothing on the context of 'browser'. If you mean to say 'the browser doesn't do it out of the box' - then ok, yes, we agree. And why not, because it's extremely hard? There are 0 comprehensive text APIs that are built upon gaming or even 3D engines today. Most of the barely handle basic text formatting. They put a few lines of text on the screen in a limited number of languages, and that's it. There are very, very few platforms that offer comprehensive text rendering, including Qt, GTK, and native platform components - they're basic. Providing comprehensive text API is not only something that has to be layered on top of those things - they also have to 'hack' those platforms to work around inherent bugs and limitations.