7 ms·
Complex text layouts progress report in Godot game engine
- tobyhinloopen 6y agoGodot allows you to write code in languages other than Go? I thought it was a Go-specific library
- laszlokorte 6y agoIt actually does not relate to Go at all. It's a game engine and allows you to write scripts in it's own scripting language (which kind of looks like python), C#, and a visual graph language.
- seniorivn 6y agohttps://godotengine.org/features https://godotengine.org/features It has nothing to do with the go language, just a coincidence >More choices than any other engine. GDScript Python-like scripting language, designed to make games with zero hassle. Learn why our community loves it. Full C# 8.0 support using Mono. Full C++ support without needing to recompile the engine using GDNative. Visual scripting using blocks and connections. Additional languages with community-provided support for Rust, Nim, D and other languages. Built-in editor with syntax highlighting, real-time parser and code completion. Integrated documentation. Browse and search the whole API offline, without leaving the editor.
- colejohnson66 6y agoThe name has nothing to do with Go the language; Just coincidence. It was taken from a play called Waiting for Godot.[0] Internally, everything is C++ (and your code can also be written in it), but the bundled scripting language is called GDScript (it’s a bit of a mixture of Python, Lua, and others with some extra unique syntax sugar). However, it does support bindings to other languages. The most common being C# (using Mono), but people have gotten Rust to work (among others). [0]: https://en.wikipedia.org/wiki/Waiting_for_Godot https://en.wikipedia.org/wiki/Waiting_for_Godot
- Wezl 6y agoI didn't know that about the name. Should we pronounce it /ˈɡɒdoʊ/ like wikipedia says the play's name is pronounced?
- colejohnson66 6y agoI’ve used to pronounce it “go dot,” but then I heard a few YouTubers say it like that (/ˈɡɒdoʊ/), and I’ve been saying it like that since.
- Deukhoofd 6y agoGot to say, this looks a lot better than Unity's UI text handling, even with TMPro.
- jan_Inkepa 6y agoUnity’s gotten better over time, but honestly janky-/blurry-looking text-rendering is still one of the giveaways that you’re playing a game made with Unity. I notice it the worst with computer card games or strategy games (where text rendering is tricky). Makes one miss flash... . Godot puts localisation/internationalisation really way more in the foreground than Unity (having built-in support for it, while Unity does not, as well as having the development software itself being localised into far more languages than Unity), so it makes sense that this culture would also lead to better text support. (disclaimer: I work with unity a lot - I’ve only done a one or two small projects in Godot, and would still recommend Unity above it generally)
- kroltan 6y agoIs there any solution or reason for the blurry text, even with TMPro? I'll be honest all my games have horrid text rendering because of that, and it's super frustrating, but I've never found a setting that fixes it (be it UI scaling shenanigans or in the TMP component itself)
- jan_Inkepa 6y agoI think there should be some randomo selection of settings that should make text-rendering tolerable with TMPro (crisp at most resolutions without using up your memory budget), but I haven’t touched it in a while, so can’t advise...
- deleted 6y ago[deleted]
- klodolph 6y agoIsn't there a scaling setting for the font asset itself that you can change? This can improve things but there's no perfect setting across platforms.
- peetle 6y agoThis look exciting, but I am obsessed with the lack of subpixel rendering for fonts in godot (imgui, nanovg, etc). The fonts just look crummy to me. As I understand it, subpixel rendering is a treacherous patent landscape. Is that the reason why it is consistently missing from these tools?
- steerablesafe 6y agoAs far as I know all Microsoft patents expired in this area. edit: seems like it wasn't too long ago. https://www.freetype.org/patents.html https://www.freetype.org/patents.html
- Jasper_ 6y agoIt's more because it's a fairly niche technique that requires either dual-source blending or constant blend colors, things that game rendering engineers don't think about often. It's also tricky to make work with transparency, which is the reason OS X ditched it. Basically, nobody in the video games space does it frequently. Maybe I should clean up and open-source my subpixel text renderer that uses dual-source blending....
- derac 6y agodo it man! point the godot devs to it as well :D
- mooman219 6y agoSubpixel text rendering also requires intimate knowledge of the display being rasterized for, and becomes a mess once you enter multiple displays with different pixel layouts. I was working on support in my font library https://github.com/mooman219/fontdue/ https://github.com/mooman219/fontdue/, but it quickly becomes not worth it. I'm interested to see your approach to the problem if your project is online!
- checker659 6y agoFYI, there's no subpixel rendering in macOS anymore (since 10.15).
- 6y ago
- londons_explore 6y agoWhy do game engines need their own text engines? Why not just use some system library to write into a texture and then use that in your game?
- morelikeborelax 6y agoBecause Godot is OS independent for development and consumption so there would be inconsistencies.
- Deukhoofd 6y agoBecause we do not want games to require fonts to be installed to properly render.
- klodolph 6y agoYou can do that! I've done it. I tapped into Uniscribe on Windows, Core Text on macOS, and PangoCairo on Linux. The problem is that this looks horrifically inconsistent between platforms. You also end up doing a ton of work to figure out how to accomplish a simple task like, "I want this text in this box, that word is italic, please add the line breaks, here is a font file." That's simple on one platform, but you end up having to duplicate everything you do across all the platforms you support, and typically you will find one platform that breaks your assumptions about how libraries should handle this task. Your code ends up being convoluted so it can hide the (major) differences between different APIs. It's actually so much work that you probably want your game engine to do it internally in a way that is consistent cross-platform. Fortunately, most of the guts have already been figured out for you by the amazing people that work on HarfBuzz. The basic formula is to take your Unicode string, take your font, and feed it to HarfBuzz to have HarfBuzz figure out the metrics and glyph offsets. You then use the metrics to do layout and line breaks. It is a lot of work, but it turns out to be less work than figuring out how to this working cross-platform using system libraries. This is also, generally speaking, how web browsers deal with their text. There are a couple other pieces that you need like text segmentation but these are tractable.
- flohofwoe 6y agoWhat system libraries would that be? Windows has DirectWrite, but AFAIK on other platform (or even web browsers), the situation is dire.
- deleted 6y ago[deleted]
- blensor 6y agoYess, finally! > This allows changing font size for individual draw calls, controls, or spans of text in the RichTextLabel control without creating new Font instances. It was so frustrating to have different font sizes in a RichTextLabel. Only downside is that we have to wait until Godot 4
- andrewmcwatters 6y agoIt feels like complete mismanagement to me that Godot focuses on work like this instead of things that directly impact gameplay. You can see it in other places like them creating their own programming language. Why can't I do multiplayer out-of-the-box? Why do I have to roll that myself? Why can't I start up a project and immediately work with gamerules/gamemode callbacks? I can checkout Grid[1] and immediately do those things, and it has two orders of magnitude less followers. Why do "game engine" developers insist on doing essentially just rendering with some bindings to things like Box2D and OpenAL? [1]: https://github.com/Planimeter/grid-sdk https://github.com/Planimeter/grid-sdk
- crocodiletears 6y agoA massive selling point for Godot, is its relative simplicity, general purpose design, and unopinionated approach to development inside of it. Unlike many open source engines that have failed, Godot (esp. Since 3.x) tends to provide you with minimal abstractions, and focus its development efforts on polishing core features which more complex features can be built on top of. It offers a smaller core feature set than an engine like Unreal, but polishes what's there so well that it can compete on a commercial level I personally believe much of its success is owed in large part to this kind of prioritization on fit and finish. Its networking api is minimal, and easy to use. It helps you negotiate your initial connection, and then gets out of your way, so you can spend your time thinking about the information coming through the pipe. A more opinionated system might be faster to get up and going, but would likely get in your way for more complex projects. Much of godot's functionality is implemented in modules, which the engine can be optionally compiled without, and are easily added in by other developers. On top of this, the engine has a plug-in ecosystem like Unity has, which allows functionality extension on a per-project basis. This means that more opinionated networking features can be trivially appended to the engine's core feature set by the community, and shared or sold as developers see fit. Imo, this is a win. Developers don't have to work around, bypass, or ship with a clunky networking model that seemed like a good idea at the time, and Godot devs don't have to maintain the potentially sprawling implementation of a feature that could very well get in somebody's way. Wrt gdscript, it's something that existed in the engine before it was open-sourced, is tightly integrated into the engine's systems, and is easy to bind new code and methods to. I don't think that the core vm has been touched too much since it was released, and it's fairly easy to ignore if you want to use C#, or C++ instead. Godot exists in a space between something like Unreal, and older frameworks like XNA. It's small enough that a single person can wrap their head around it, offers a baseline set of tools, with a modern renderer (4.0 will have a more modern renderer). It's beginner friendly, but it rarely gets in the way of experienced devs as a result.