Text drifts to the right as string gets longer

Solar2D General Questions/Discussion
#1

I have a score field which needs to stay left-aligned. Every time the score gets updated I do this:

scoreText.text = tostring ( score );  
scoreText:setReferencePoint ( display.TopLeftReferencePoint );  
scoreText.x = 40; scoreText.y = 0;

The problem is that every time a new digit is added to the score (for example going from 99 to 100 points), the text drifts further and further to the right, no longer correctly left-justifying like it’s supposed to. Is there a workaround for this? [import]uid: 52127 topic_id: 12379 reply_id: 312379[/import]

#2

That should work, unless you’re also doing something like applying scaling. [import]uid: 6787 topic_id: 12379 reply_id: 45117[/import]

#3

No, there is no scaling involved. I originally create the text like this:

local scoreText = display.newText("0", 0, 0, native.systemFont, 10);

After that, the code in my original post is the only thing affecting the text field. [import]uid: 52127 topic_id: 12379 reply_id: 45118[/import]

#4

Is it in a group? You wrote: scoreText.y = 0;
[import]uid: 6787 topic_id: 12379 reply_id: 45127[/import]

#5

Try to set the x position as well after you have the text to the string. I do not know why but it helped me in a project which was for like 80 builds ago though :slight_smile: [import]uid: 22737 topic_id: 12379 reply_id: 45180[/import]

#6

I had a similar problem that turned out to be the “fix” for Retina text making things move. Because that fix doubles the font size and then scales down the result, the location of the string didn’t end up being correct.

I was using the Crawl Space Library when that happened and the fix for the problem was just to set the X coordinate after creating the text string. Unfortunately, it looks like you’re already doing that.

Just for fun, instead of setting the text property, try ditching the display object and creating it again each time. Depending on the results that might give you a clue as to what’s going on and how to fix it.

Jay
[import]uid: 9440 topic_id: 12379 reply_id: 45182[/import]

#7

@Jay,

Interestingly, creating a new text field every time seems to place the text in the correct position.

It’s unfortunate that I have to do that, as it surely is more processor intensive to keep creating new text fields (my score gets updated a lot because points are awarded for “hang time” as an object is flying through the air. I hope this bug gets fixed. [import]uid: 52127 topic_id: 12379 reply_id: 45285[/import]

#8

Okay, then here’s one more thing to try. When you create your score text object, create it using the highest score a user can possibly get, such as:

[lua]local scoreText = display.newText(“100,000,000”, 0, 0, native.systemFont, 10)[/lua]

Right after that set the text property to “0” and go from there.

My hunch is that when you create the text display object it’s internally set at a width good for whatever text you specify – and then when you change the text property by making the text string longer, things are getting screwed up.

Just a guess, don’t know if it will work, but should be easy to try.

Jay
[import]uid: 9440 topic_id: 12379 reply_id: 45287[/import]

#9

Unfortunately the issue still exists even when you initialize the text with a large number. It seems as though the text field thinks it’s twice as wide as it actually is. [import]uid: 52127 topic_id: 12379 reply_id: 45296[/import]

#10

If you run this sample code:

[lua]display.setStatusBar(display.HiddenStatusBar)

local score = 0

local scoreText = display.newText(“0”, 0, 0, native.systemFont, 10);
scoreText:setReferencePoint ( display.TopRightReferencePoint );
scoreText.x = 60; scoreText.y = 0;

local function incScore(e)
if e.phase == “ended” then
score = score + 123
scoreText.text = tostring ( score );
scoreText:setReferencePoint ( display.TopRightReferencePoint );
scoreText.x = 60; scoreText.y = 0;
end
end

Runtime:addEventListener ( “touch”, incScore )[/lua]

…and click the screen the score stays fixed on the right and expands to the left as the score gets higher. There’s actually a tiny bit of shifting at some points, but back and forth, not drifting off to the right (or left).

What’s different about what I’m doing there are the code you have that’s causing problems?

Jay

PS - If you’re using any kind of “auto Retina text” code, say so. :slight_smile:

PPS - I added some “auto Retina text” code to the example above and got drifting text. [import]uid: 9440 topic_id: 12379 reply_id: 45378[/import]

#11

Well, I am using this:

http://blog.anscamobile.com/2011/07/tip-say-goodbye-to-blurry-text-for-good/comment-page-1/#comment-4470

Which is supposed to be a “quick fix” that doesn’t affect other things, but I’m thinking that maybe it wasn’t really tested out that much. [import]uid: 52127 topic_id: 12379 reply_id: 45456[/import]

#12

For static text that doesn’t change, the auto-Retina text thing works well – but it has problems when you change the size of the text that’s in the display object (size as in number of characters).

When I was having problems with this Adam Buchweitz from Crawl Space Games came to my rescue with this:

Change the text, then set the position again using the contentWidth property, 
divided in half because of the retina scaling. Here's a snippet from Float:

scoreField.x = screenX + screenWidth - scoreField.contentWidth \* .5 - 8

screenX+screenWidth is the right side of the screen, then subtract half 
the contentWidth, then 8 pixels. So that positions the box 8 pixels from 
the right side.

Hopefully that will help you. The code in CrawlSpaceLib isn’t exactly the same as in the code Jonathan posted on the blog, but they’re doing the same thing – doubling the font size and then scaling down by half.

Jay
[import]uid: 9440 topic_id: 12379 reply_id: 45504[/import]

#13

Thanks, that does actually help. I had tried something similar but had used scoreField.width instead of scoreField.contentWidth.

I still have an issue where the text appears shifted upward by about 5 pixels on the iPad (and slightly clipped at the top) as compared with the iPad simulator, where it looks fine. Ever seen that happen? I think it only happens with custom fonts, not system fonts. [import]uid: 52127 topic_id: 12379 reply_id: 45527[/import]