Baking FreeType Into Gwork? about gwork HOT 12 CLOSED

It's funny you mention that now as I'm just considering this morning including the Ponder and Lua dependencies to make development and testing easier.

How big is the source in kb?

I don't really want to include binaries. So it would have to all build from source.

from gwork.

I guess the options for this are:

• Include binaries, but then you have to include them for all platforms, and then you also get the shared/static problem. 😱
• Include the source code. ☯️
• Include as a git submodule. Then just build using script. 👍
• Include as git subrepo. This is good if you want to work on the repo and export the changes. 👍

Lua and Freetype could be included as submodules. Ponder I think I'll include as subrepo as I'm still developing it and I'm fed up of writing configs and tests in instead of doing development.

from gwork.

I like the subrepo/submodule idea. It's better than including the source directly and much better than including the binaries.

I'll go ahead and get started on this when I have some time to dedicate :)

I figure I would integrate it into the base renderer? After pondering over the source code this seems like the most appropriate place to do it.

from gwork.

I think submodules will be best as there should be no need to edit the FT source.

Please make sure you do the work in a new branch, perhaps "feature/freetype". This makes the whole PR process so much easier!

What functionality will this work add? Common FreeType render to bitmap, and caching of glyphs? The STB header does most of this.

It might be best to do most of this in a ResourceLoader. I wouldn't do it in the base renderer as not all the renderers will use it. If there is common functionality there, perhaps create an intermediate FreeTypeRenderer, which derives from Base, and then the common client renders derive from this.

from gwork.

DirectX11, Irrlicht3D, OpenGL, SDL2, and Software have no native support for text rendering.

• Allegro5 has font support cross platform.
• DirectX11 does have native support, and uses it.
• SDL2 has the TTF library, so that does have font support (and it is good).
• OpenGL uses the STB library (which uses FT), and there is a debug font version.
• Does Irrlicht just need to link to FT?

What is the problem we're trying to solve here?

from gwork.

SFML uses FreeType already. 😉

from gwork.

I want to provide users with the ability to use TTF fonts directly from the library without having to integrate their own methods when the platform doesn't provide text rendering (like software renderer) or if the platform only provides text rendering from bitmap fonts (in which case they would end up doing their own integration of freetype at some point).

SFML and Allegro have TTF font support and so does SDL2 if you use their optional plugin.
I believe the rest only support bitmap fonts or no direct font rendering at all.

Nonetheless I just want to make sure you want this a part of your library before I write the code ;)

from gwork.

What will you provide that STB_truetype doesn't supply already? The renderers that use this header library effectively do what you say. Have a look at the software renderer.

I can't remember if it supports glyph caching so that could be something to add. Fontstash could be added for this.

from gwork.

Oh my I was completely unaware you included that! This is a non-issue now ;)

from gwork.

No probs. Thanks for the offer. I'm sure you find another feature to add/improve if you're keen. E.g. I'd like to make the skinning more data driven.

from gwork.

Personally like how you can define all the texture coordinates through internal functions. Maybe if those functions then saved their values to a .json or .xml file which could be externally edited, that would work quite well.

In the past I've manually bound GWEN to Lua. It was a huge undertaking and about a week long process but the end result was very good. A good portion of that time was spent researching the best route to take so it could be done a bit quicker a second time around.

from gwork.

Personally like how you can define all the texture coordinates through internal functions. Maybe if those functions then saved their values to a .json or .xml file which could be externally edited, that would work quite well.

The problem is that the code is hardcoded to a texture then. I think a skin should have the ability to be quite different.

Yep, I thought about doing something similar: dumping all the coordinates out at runtime into JSON.

In the past I've manually bound GWEN to Lua. It was a huge undertaking and about a week long process but the end result was very good. A good portion of that time was spent researching the best route to take so it could be done a bit quicker a second time around.

Wow, yes, that is a big job. I've always used auto binding for that kind of thing, like tolua. If you look in the "ponder" branch of Gwork I'm using Ponder to expose the API. Ponder allows Lua to use the data. It could also be set up to use JSON or XML to load skin and saved UIs.

from gwork.