FlxText and FlxBitmapText need a common interface

[JoeCreates]

At the moment, it is not possible to write a class with text elements where it is possible to change between FlxText and FlxBitmapText due to the lack of a common base class or interface.

Having something like an IFlxText would allow us to write classes with text elements interchangeable between the two, and could replace places in flixel where presently FlxText has been used but a bitmap text might be desired, for example on sliders.

[MSGhero]

Do you see this breaking anything? I'm interested in checking this out, but I'm on my phone atm.

[Tiago-Ling]

I for one think that text should always be rendered through hardware, and fallback to blitting (if ever) only if needed. This should all be done internally.

With 4.0 and new version of OpenFL (5.0 now) there should be no need for software rendered objects as "first class citizens" of the framework.

An interface now would only bloat the code even more. Let's wait for 4.0 before proposing big changes like this one. Anyway, just my two cents. :)

On May 11, 2017 10:28 PM, "Nick" notifications@github.com wrote:

Do you see this breaking anything? I'm interested in checking this out, but I'm on my phone atm.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/HaxeFlixel/flixel/issues/2066#issuecomment-300959513, or mute the thread https://github.com/notifications/unsubscribe-auth/ABis3qgIfh0CLtZs0gIvevmkopZ5UIUXks5r47WmgaJpZM4NYuLw .

[MSGhero]

I don't think the intent is for performance but rather to use existing bitmap fonts that look cool.

But I see your point. If some object has text, should that text object be vector or bitmap? (Maybe could be flxdefined to use either or?)

[JoeCreates]

@Tiago-Ling I'm not sure I understand. The distinction between FlxText and FlxBitmapText has nothing to do with hardware/software rendering. FlxBitmapText uses hardware rendering. The difference is that the source of FlxText is a vector and the source for FlxBitmapText is a raster. FlxBitmapText items can use many colors in the font, and are well suited for more complex pixel art fonts such as these.

@MSGhero Well, a short term improvement could be to simply create an IFlxText interface with the stuff that is already common between FlxText and FlxBitmapText and simply make these extend the interface. This wouldn't break anything but would allow for classes to have and operate on text fields regardless of which type of text they are.

Changing existing FlxText fields to IFlxTexts however would be potentially breaking, as any use of FlxText that is not also common with FlxBitmapText would no longer work. There is also potentially more commonality to be found between FlxText and FlxBitmapText if we allowed for other fields to be changed in these classes, for example text wrapping (FlxBitmapText#wrapByWord vs FlxText#wordWrap) and line spacing, padding and such, which are currently a bit different but could perhaps be unified. This would definitively be breaking, though.

[Tiago-Ling]

@JoeCreates Yeah, sorry about the confusion - you're right, it's not hardware vs software. What i wanted to write was that FlxBitmapText and FlxText could be only one class instead of creating an interface to maintain both. One class could accept both sources (i.e. ttf / other font formats like FlxText does and other bitmap font formats like Angel Code, as FlxBitmapText does). This would make it easier to maintain and implement new features i think.

[Beeblerox]

I like this idea! What interface do you want them to share?

[larsiusprime]

Hey there!

Let me weigh in with a specific use case. On console targets, the software rasterization step that FlxText currently uses often leads to a significant amount of time and can lead to load times or framerate dip in games with loooots of UI text (ie, Defender's Quest). So, it would be an easy optimization to do to swap out FlxText for FlxBitmapText in some situations. However, because they're so different it's not easy to abstract that or fall back.

So I would personally prefer FlxBitmapText to look as much like FlxText as possible, so one could more seamlessly fall back from FlxText to FlxBitmapText.

FlxBitmapText I imagine will always have some limitations -- I guess it's assumed to be monospaced, it is harder (though not impossible) to do bitmap fonts for unicode text (especially asian character sets), etc., but a common interface would be super helpful.

On Mon, May 15, 2017 at 3:07 AM, Zaphod notifications@github.com wrote:

I like this idea! What interface do you want them to share?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/HaxeFlixel/flixel/issues/2066#issuecomment-301405455, or mute the thread https://github.com/notifications/unsubscribe-auth/AAtG-Oic9HTL7aSaATfsxPg7KbfxI7aGks5r6AewgaJpZM4NYuLw .

-- www.fortressofdoors.com -- Games, Art, Design

[MSGhero]

Listing all the common public members (ignoring get/set differences):

font, text, wordwrap, alignment, borderstyle/color/size/quality, autosize, shadowoffset, setborderstyle()

And ones that aren't common:

FlxText has: size, embedded, systemfont, bold, italic, textfield, most public functions

BitmapText has: linespacing, letterspacing, autouppercase, wrapbyword, padding, textwidth/height, lineheight, numspacesintab, textcolor, usetextcolor, background, backgroundcolor, multiline, numlines, most public functions

Quite a few of what bitmap text has could be added to FlxText and fall through to the inner textfield, giving them more common members. So then @larsiusprime should bitmap text look more like FlxText or vice-versa?

[larsiusprime]

I mean, it seems weird to force things like bold, italic, systemfont, etc, on bitmap fonts as that's an alien concept to that implementation.

I think one might need a BasicText sort of interface that just contains what they have in common, so you can have variables that could be one or the other? And then maybe a fancier class that implements that interface, but internally can be set to be either a bitmap text or a "real" text?

On Tue, May 16, 2017 at 2:38 PM, Nick notifications@github.com wrote:

Listing all the common public members (ignoring get/set differences):

font, text, wordwrap, alignment, borderstyle/color/size/quality, autosize, shadowoffset, setborderstyle()

And ones that aren't common:

FlxText has: size, embedded, systemfont, bold, italic, textfield, most public functions

BitmapText has: linespacing, letterspacing, autouppercase, wrapbyword, padding, textwidth/height, lineheight, numspacesintab, textcolor, usetextcolor, background, backgroundcolor, multiline, numlines, most public functions

Quite a few of what bitmap text has could be added to FlxText and fall through to the inner textfield, giving them more common members. So then @larsiusprime https://github.com/larsiusprime should bitmap text look more like FlxText or vice-versa?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/HaxeFlixel/flixel/issues/2066#issuecomment-301892601, or mute the thread https://github.com/notifications/unsubscribe-auth/AAtG-DlJZ0v-Tz-ZwJUwBEGS1iS3X2tOks5r6ftHgaJpZM4NYuLw .

-- www.fortressofdoors.com -- Games, Art, Design

[NQNStudios]

I'd like to bump this one. I'd be willing to fork and contribute if the maintainers would accept it.