You can "roll your own" by creating a multiline object that is based on a sprite, then use the getBounds() function (search the forums) to get the size of the text one word at a time and then when you wrap over the bounds of the box just add a new line and continue until all the text has been used.
You'll end up with a parent sprite that has several children each one a single line of text.
WhiteTree Games - Home, home on the web, where the bits and bytes they do play! #MakeABetterGame! "Never give up, Never NEVER give up!" - Winston Churchill
Well that's similar to what TextWrap is doing, except it's handling also text alignment, strict width, etc.
But @unlying is it really so bad? I 've just created an example to try it out with 100 lines, and it didn't seem so bad. I attached it to the post for you to check out.
I've also printed out how much time something takes in miliseconds, to understand what is the most slow in the process, and usually it is creating TextField objects.
If you can provide sample texts to load and discuss other features of TextWrap, that you don't need to use, maybe it would be possible to create something a little simpler and more optimal.
Re the speed - I wonder if when "render to texture" is enabled, it will be easier (and ultimately quicker) to render a page of text in one go and then just display that.
In my widget library I have some quite complex objects (buttons with stacked layers, icons, text labels etc) and as soon as render to texture is available, I'll be looking into that.
WhiteTree Games - Home, home on the web, where the bits and bytes they do play! #MakeABetterGame! "Never give up, Never NEVER give up!" - Winston Churchill
WhiteTree Games - Home, home on the web, where the bits and bytes they do play! #MakeABetterGame! "Never give up, Never NEVER give up!" - Winston Churchill
But @unlying is it really so bad? I 've just created an example to try it out with 100 lines, and it didn't seem so bad.
Yep. It is not good. But you are looking in wrong side. It is not about lines in txt file. It is about lines on screen. Try any 20Kb file and you will see difference. It takes MUCH time. Try this app https://play.google.com/store/apps/details?id=com.pickup.pickup I wonder who gives 5 marks for this app, because even I can't use it normally with these lags:) And these nasty squares... One of file used in this app attached.
actually I was first experimenting with 400kb file, which loaded in 12 seconds on my ipod. Interesting that 30kb unicode takes 6 seconds to load
So results with your text: Open File: 3.000244140625 ms Read Content: 4 ms Delete Children: 5.000244140625 ms Create test text: 5424.3100585938 ms Do the calculations: 5426.3103027344 ms Done with iteration: 6228.3559570313 ms Create TextWrap: 6228.3559570313 ms
As you see it takes more than 5 seconds to create test TextField, to measure it's dimensions, so it would be possible to calculate approximate chunks of text for each line (restricted by some width)
If in your case, restriction by width is not needed, and you only need to deal with new line symbols, it could be done without testing TextField dimensions in couple of seconds.
But I suppose both alignment and restriction by width is needed.
Only thing that I could come up with is to provide not only width, but also maximal count of letters per line. This way TextWrap does not have to create large TextField just to test and calculate letter chunks needed and now it loads on my device in about a second.
But you would have to experiment with different letter count values to find your suitable one.
@ar2rsawseen, thanks. I appreciate your help. But may be i'm doing something wrong, because new version of your textwrap doesn't load all content. Only part of it. I tried two files and both of them stops on line 10. Not on start but on 10-20 letter(depends from file). And it is not a problem with variable, because if i print it, i get all text. May be you understand what i'm doing wrong?
Ok, now that explains why it worked so fast. Because I wasn't loading the whole file
Fixed and it runs not as fast as I hoped, but still somewhat 2 times faster than initial one.
What I would recommend you to do, is to try not to load everything in one time. Firstly store every new text as separate string (using json or lua, or simply splitting string by new line) And then there are couple of options:
You can create some sort of list (TableView perhaps), where you click on a list item and go to one specific text to read it.
You can create pagination and load about 10 or 20 texts per page.
Or you can create a sophisticated scrollerView, which would load new texts while you scroll down (for example pre load 10 next texts, that are not yet visible on display and then with each scrolled one, load new a new one, so you'll always have a new text to show, and new ones are preloaded as you scroll through window). Similar what twitter and facebook does with their posts
@ar2rsawseen, thanks much. It works much better. But funny thing. If in early version it was 1 square for a string from file then we have double squares now. This is screen from attached application with font 10.
Ok first problem was because I've dealt with new line symbols \n, but squares were because or carriage returns from windows system ( symbol: \r ) And now I firstly remove all carriage returns and then split by new lines. And it all works great on my windows system.
Ok I think I've found the bug. I don't know why it does not show on my Gideros player.
So results with your text: Open File: 3.000244140625 ms Read Content: 4 ms Delete Children: 5.000244140625 ms Create test text: 5424.3100585938 ms Do the calculations: 5426.3103027344 ms Done with iteration: 6228.3559570313 ms Create TextWrap: 6228.3559570313 ms
Well there were multiple print() statements using function from LuaSocket just to get milliseconds in the LargeText project I posted somewhere above. Then it all appears in console below inside Gideros Studio
After reading your posts, I want to see if it's possible to achieve fast and smooth results with big text files. I've followed the path of @ar2rsawseen but decided to add/remove lines dynamically.
I'm attaching my current status. On my Samsung S 2, it loads bebad.txt in about 1/4 seconds and I can smoothly scroll the text. I'm planning to finish it soon and the API will be very similar to @ar2rsawseen's.
@atilim: the 'TextWrap2' is not displaying the text for me .. no error conditions show tho .. just no text actually displays. The text exists tho, it shows in a print statement properly
Comments
You'll end up with a parent sprite that has several children each one a single line of text.
#MakeABetterGame! "Never give up, Never NEVER give up!" - Winston Churchill
But @unlying is it really so bad?
I 've just created an example to try it out with 100 lines, and it didn't seem so bad. I attached it to the post for you to check out.
I've also printed out how much time something takes in miliseconds, to understand what is the most slow in the process, and usually it is creating TextField objects.
If you can provide sample texts to load and discuss other features of TextWrap, that you don't need to use, maybe it would be possible to create something a little simpler and more optimal.
In my widget library I have some quite complex objects (buttons with stacked layers, icons, text labels etc) and as soon as render to texture is available, I'll be looking into that.
#MakeABetterGame! "Never give up, Never NEVER give up!" - Winston Churchill
Likes: chipster123, atilim
Website: http://www.castlegateinteractive.com
https://play.google.com/store/apps/developer?id=Castlegate+Interactive
Likes: atilim, chipster123
#MakeABetterGame! "Never give up, Never NEVER give up!" - Winston Churchill
Try this app https://play.google.com/store/apps/details?id=com.pickup.pickup
I wonder who gives 5 marks for this app, because even I can't use it normally with these lags:) And these nasty squares...
One of file used in this app attached.
Interesting that 30kb unicode takes 6 seconds to load
So results with your text:
Open File: 3.000244140625 ms
Read Content: 4 ms
Delete Children: 5.000244140625 ms
Create test text: 5424.3100585938 ms
Do the calculations: 5426.3103027344 ms
Done with iteration: 6228.3559570313 ms
Create TextWrap: 6228.3559570313 ms
As you see it takes more than 5 seconds to create test TextField, to measure it's dimensions, so it would be possible to calculate approximate chunks of text for each line (restricted by some width)
If in your case, restriction by width is not needed, and you only need to deal with new line symbols, it could be done without testing TextField dimensions in couple of seconds.
But I suppose both alignment and restriction by width is needed.
But you would have to experiment with different letter count values to find your suitable one.
Hope that helps you in any way
May be you understand what i'm doing wrong?
Fixed and it runs not as fast as I hoped, but still somewhat 2 times faster than initial one.
What I would recommend you to do, is to try not to load everything in one time. Firstly store every new text as separate string (using json or lua, or simply splitting string by new line)
And then there are couple of options:
You can create some sort of list (TableView perhaps), where you click on a list item and go to one specific text to read it.
You can create pagination and load about 10 or 20 texts per page.
Or you can create a sophisticated scrollerView, which would load new texts while you scroll down (for example pre load 10 next texts, that are not yet visible on display and then with each scrolled one, load new a new one, so you'll always have a new text to show, and new ones are preloaded as you scroll through window). Similar what twitter and facebook does with their posts
Likes: unlying
This is screen from attached application with font 10.
Ok first problem was because I've dealt with new line symbols \n, but squares were because or carriage returns from windows system ( symbol: \r )
And now I firstly remove all carriage returns and then split by new lines. And it all works great on my windows system.
Ok I think I've found the bug. I don't know why it does not show on my Gideros player.
Here please try this project:
Likes: unlying
Don't you see squares if font is 10, not 20?
Thats why I can't fix it.
you can try and experiment with it in TextWrap.lua on 80-81 line try decreasing lastSpace or increasing last value, for example,
Likes: atilim, unlying
Likes: ar2rsawseen
Likes: ar2rsawseen
After reading your posts, I want to see if it's possible to achieve fast and smooth results with big text files. I've followed the path of @ar2rsawseen but decided to add/remove lines dynamically.
I'm attaching my current status. On my Samsung S 2, it loads bebad.txt in about 1/4 seconds and I can smoothly scroll the text. I'm planning to finish it soon and the API will be very similar to @ar2rsawseen's.
cheers
Likes: unlying, ar2rsawseen, heart2heart
Cause now I'm speechless. ^:)^
Likes: chipster123
Likes: chipster123
My apps: http://www.yummyyellow.com
The latest rendition of the TextWrap.lua is giving me an error:
includes/TextWrap.lua:138: attempt to perform arithmetic on field 'lineSpacing' (a table value)
any thoughts?
Thx