Alternatives to String Object?

Quote from Qualms

Hi! I've disliked the default String Object for a long time: you can't customise it much and you can't even disable antialiasing in most exporters. I've always avoided it when possible.

For pixel style games, I've always gotten by with the Text Blitter extension. However, even that is quite limited (monospace and windows only.)

I know there are examples where people make their own blitting objects but this seems very time consuming and resource-heavy, especially if you're making a game with a lot of dynamic text on-screen.

Basically I just want to know what's the most popular method to use right now. Surely there has to be something better than the default String Object?

Hey!

You may find my blitting engine useful. It uses a handful of objects to provide a pretty flexible blitting system. It should be compatible across all platforms, but I haven't tested on mobile TBH. The MFA is pretty well documented throughout. It supports fixed width and variable width fonts with only minor changes (notes in the MFA show you exactly what to change).

Please login to see this link.

Quote from Qualms

Oh wow, the example provided is indeed very powerful, perfect even. It's a lot to unpack, looks intimidating, but I'll give it a good read.

Is it possible to insert this widget into existing applications? Or is it very dependent on those global values?

Hey yes you can!

So there 1 global value in use for blitting there, and only because the options menu allows for adjusting the speed of the text. Other than that it is self contained and should work simply by copying all the objects!

textspeed = This is for the "Text Speed" setting in the options menu. So the user can choose the speed of the text, and it is reflected in the blitting engine. Even if you don't use subapps, it would be a decent idea to have a global variable for this (if you want the user to be able to adjust text speed) so it remains consistent between frames. Otherwise, just set the Text Blitter Object's Blit Speed and LoopDelay values to whatever suits your tastes. This example has 3 speeds, and the value of textspeed alters the Text Blitter object's Blit Speed and LoopDelay variables which combine to control the speed of the text appearing on screen. Referenced on lines 83, 84, 85 of the Text Blitter object's behaviour.

IIRC the 2 variables on the Text Blitter object for speed perform the following functions:

blit speed = the # of characters blitted at once

loopdelay = the delay between blitting however many characters you specify in "blit speed".

PLaying with these values can get you some interesting results. For example blit speed of 10 will blit 10 characters at a time. 150 will blit 150 simultaneously! Good if you just want your whole paragraph displayed right away. Blit Speed of 1 and Loop delay of 40 will slowly place 1 character at a time. Blit speed of 5 and loop delay of 40 will slowly place 5 characters at a time. IIRC 40 is VERY slow, you usually want to stick below 10, even 10 is painful if I remember

Similarly for the input blitter object, there is 1 global value and 2 global strings in use. :

inputlength - set to control the # of characters the user is allowed to input, to pass to the input window sub app. Referenced in line 25 Input Blitter object behaviour

inputFrameText - used to pass some pre-determined text from the game frame to the input sub app frame, ie, "What is your name?" etc. Set in frame (do a search all for this to see how I used it in the example)

InputFrameOutput - used to pass whatever the user entered in the input sub app frame, back to the game frame! Set by taking w/e the user inputted (search for this as well to see how I used it in the example)

Obviously the method of engaging and passing the input around could be done however you want, the example just shows one way to utilize it!

I hope that makes sense. Mostly the global variables are there for passing info/settings of the blitting engine between sub apps and/or different frames, as needed by other parts of the example which use subapps to achieve the goals (namely the pause/settings/input menu). If you aren't using subapps, you could probably put those as variables on the Text Blitter / Input Blitter objects themselves, and make them global objects. Or modify the references in the code to point to new global variables!

Tonight, I will add this explanation into the MFA because it seems I neglected to add an explanation of the text speeds! edit: NM - on second glance, I did explain these variables in there

I use Active System Box for texts in my pixel art games. It gives you a lot of control.

I wish ASBs were as fast or at least close to the performance of normal strings, but they are way slower in my testings (maybe because they are constructed of multiple objects, kinda like a nineslice), which can be noticeable in a project where a lot of text can be displayed at once.

Also, you can't use Effects on them, which can be very limiting, which is actually my main gripe with it, but other than that it's much better than strings yeah, it has more options, and you can actually change the size of the bounding box at runtime, which alone gives it much greater advantage over strings.

I'm honestly thinking of making a text bitter engine that works with normal string objects. (not just active characters) so I get advantages of things like line padding, sub string coloring, size, font...etc ofc that's not as easy as it may sound as you wouldn't really create a string for each character (that would kill performance and generally very inefficient) so a much advanced text formatting system is needed here, and to make sure it works on all runtimes is even harder.