I’m currently doing a little fade effect using BitmapText but I’ve noticed there wasn’t any method to do so directly, could it be possible to have one?
I’ve quickly skimmed the code and it’s… huh… not what I expected. 
Let’s just say there’s a LOT going on in this iteration of BitmapText. 
I have it working fine btw, I think it would be easier with a setter for the alpha channel only.
It looks like that:
[java]textLines.setColor(new ColorRGBA(textLines.getColor().r, textLines.getColor().g, textLines.getColor().b, 1f - ((currentTime - visibleFor) * fadeTime)));[/java]
But could look like that instead:
[java]textLines.setColorAlpha(1f - ((currentTime - visibleFor) * fadeTime));[/java]
I know, it’s not much, but I wouldn’t have to create a new ColorRGBA every time. It could also be interesting to have, yes? Besides, it’s much easier to read.
It could be good for another reason because BitmapText can actually have multiple colors at once.
In your use-case, I’d actually argue for keeping the colors separate and just resetting them when you change their alpha. But I’m an MVC guy from way back so I shudder at trusting the data in a view. 
At any rate, there is no way currently to set alpha on all of the colors in a BitmapText and that would be useful… because as it stands now my chat box could never support embedded color codes because like you I wipe out the colors the next time the alpha changes.
BitmapText is a pretty convoluted class, though. Simple things take 20 times longer than expected… so it will be a while before I’m brave enough to add this. Even being able to set the color before the text (something I added) was a pain.
It actually works nice the way I set it. The colors are fading accordingly, but it’s just hard to follow when it’s all jumbled like that. I changed the method a bit so it’s easier to read, but still.
Note that I don’t use multiple colors in the same BitmapText, so I understand you point about being able to set the alpha value for different colors in the same bitmap.
Anyway, it’s not a demand, but it sure would be a nice feature to have.
I just added BitmapText.setAlpha(). I decided it would be nice to support embedded color tags in my Mythruna chat window and I’m also more generally working on my GUI library and being able to set the alpha properly on a label or text entry field is useful.
Edit: and by the way, I think it’s awesome that a search in the Google box for “BitmapText alpha madjack” found exactly this thread as the first result.
wasn’t it possible to get the Page material and get the color on it to chnage alpha?
I guess the embed color change the vertex color, right? not the material color
@nehon said:
wasn't it possible to get the Page material and get the color on it to chnage alpha?
I guess the embed color change the vertex color, right? not the material color
Right, we're talking about the vertex color. The color of the BitmapText is controlled by the vertex colors.
So wouldn’t it be faster to change it on the material?
I know this is not your target, but updating meshe’s buffers on a frame basis on android is a killer.
That’s why i changed nifty renderer to work on the material colors instead of the vertex color.
Unless you want to change the color of each letter, it should work.
@nehon said:
So wouldn't it be faster to change it on the material?
I know this is not your target, but updating meshe's buffers on a frame basis on android is a killer.
That's why i changed nifty renderer to work on the material colors instead of the vertex color.
Unless you want to change the color of each letter, it should work.
What are you talking about? One material is used for all BitmapText of a particular font... you'd have to set it per frame, per BitmapText.
Versus now where it's only set when the color changes.
Are you talking about cases where you are changing the color every frame?
Note: there is only so much we can do to make nifty’s square peg fit into JME’s round hole. I think the BitmapText.setAlpha() change might be served by this change, also… since the reason they aren’t cached per color is because of all of the alpha fading.
BitmapText supports per character coloring. I will be 200000% wholeheartedly against removing that capability just to support nifty on android.
Also note: this doesn’t affect the nifty-specific render() hack at all since if you don’t use it it doesn’t change anything and that nifty-specific render() hack already ignores color tags. (If it’s the same one I’m thinking of, it also broke regular BitmapText when first added until I added a work-around.)
Now that the original color is retrieved in that method, you could maybe just change its alpha instead… if it already exists. (Just make sure to put it back the way it was or it breaks other BitmapText using the same font.)
Madjack wants a fade effect. This involve changing the color on every frame over a short period.
this means that the bitmap text color buffer will be changed on each frame.
What i’m saying is that changing it on the material color would be faster even on desktop .
There is one material per text page, so unless you want to change the alpha of each letter independently, it should work.
@nehon said:
Madjack wants a fade effect. This involve changing the color on every frame over a short period.
this means that the bitmap text color buffer will be changed on each frame.
What i'm saying is that changing it on the material color would be faster even on desktop .
There is one material per text page, so unless you want to change the alpha of each letter independently, it should work.
He might be fading it once per frame or over several frames. Another user might be setting it once so their text blends. I set it every 10 frames or so (it's actually based on time and not frames)... either way, these things are no slower now than they were. It used to be you had to set the color to change the alpha.
Also, setting and reverting the alpha every frame (and where would we even hook that in, cause I'm curious) even for text that doesn't need it is a bit wasteful... though I suppose since we're now stuck with Unshaded it would be the only way.
And if we want to talk about rewriting BitmapText, I have about 100 ideas on that subject. :)
I think maybe the nifty renderer needs a completely different way of writing screen-specific text that doesn't co-opt scene graph objects to simulate immediate-mode style rendering.