EDIT: April 18, 2012

Here's what I've been working on this past week or so, the almost perfected version of my text displaying code that I hope to use in future games, like Pokemon. This program, like Doors, will work on 2.43 OFW as well as newer Mathprint versions!

This small section of code performs several functions which I believe are important for BASIC projects involving a great deal of text. It uses several BASIC libraries currently supported by the last official version of DoorsCS7. The code below is a sample program demonstrating how it might be implemented in a game. It operates in four steps.

1) The string to be displayed is stored into Str1 from the archived appvar TEXTDUMP using LOOKUPINDEX. TEXTDIND is the respective index file it uses to recall those lines quickly. This text dump only has ten lines, but it should work almost equally fast in text dumps with lines that are numbered in the hundreds, or maybe a thousand.

2) The program then searches the string for any Greek letters, which are currently serving as placeholders for various strings stored in TEXTTEMP. It is demonstrated in line two, where the alpha symbol is replaced with the proper name PLAYER.

3) The program then quickly scours the document for the locations of all SPACES in the string and stores the first letter of every word to a string. This is the longest step, but the wait is almost unnoticeable for strings of even a decent length. Line 5 demonstrates an extremely long string, but the wait was only a second or so on a TI84+SE (586 characters, nearly 100 words).

4) In the last step, the program displays every word individually, lending an impression that say, an in-game character is talking. It correctly demonstrates word-wrapping, and even tends to complete a sentence separately before moving on to the next one. After both rows are filled, the programs waits for a keypress before resuming. After the message has been displayed, it returns the screen to exactly the way it was. Provided the appvars are all present in the archive, the only input required was the number corresponding to the line in the text dump.

I am sure there are a load of ways people could use this, and the code I've written is out there and you should feel perfectly fine using it or changing it to suit your needs. Altering the text width or the number of rows, for example, should require relatively few changes to the programming. It is by no means a requirement, but it'd make me happy to see a little credit attributed to me, this is my first contribution in some time.

The text dump requires no linebreak characters whatsoever to function. In this version, however, the routine would hang up if it encountered a word too long to display on one line (i.e. 90 pixels or about ~23 letters). There are a few small bugs, but nothing too broken. The only thing I really noticed is that the program cannot tell if a period denotes the end of a sentence if it appears before a space or if it is simply an abbreviated term. I'd probably get lazy and try to fix it by making St. Louis -> St.Louis, etc.

The textdump contains ten examples, including two in another language, try them out! I'd advise not inputting any other number besides those ten integers in this particular program, I will not be responsible for the possible resultant ram clear and instead I will laugh at you.

SourceCoder can do nothing for it, but I still think that with the new additions it could stand some improvement, so any helpful criticisms would be welcomed! A downloaded is included with the program and the appvars I used to demonstrate it. Doors is a separate application by KermMartian and needs to be downloaded here:
http://www.cemetech.net/projects/item.php?id=32

DOWNLOAD PRGM_X.ZIP HERE!




==========OLD=POST===========================


Code:


This program uses a Doors lib command called StringWidth:
http://dcs.cemetech.net/index.php?title=BasicLibs:StringWidth

Arguments: sum(0,"STRING"
Outputs: The width in pixels of "STRING" is returned in Ans from this routine, and can be used as Ans or stored in a variable.

The above, named prgmW, uses only 182 bytes on the calculator. I'm wondering if it is possible to do better? It takes the string in Str1 and outputs a list of starting positions to be used with sub( on the graphscreen. I worked very hard to optimize this because it is only one piece out off many to manage pasting text to the screen, so it needs to be fast. Anybody think they can do it better?

http://dcs.cemetech.net/index.php?title=BasicLibs:StringWidth

You can use that to get the string width, which will be faster than almost any TI-Basic one (Since it's in ASM). I think that will probably be the biggest speed gain, since I'm pretty certain that you've done all that one can do for optimizing, without going to ASM libs.

That has already been included buddy. Thank you.

Could you have the old and updated versions in your first post? That way if someone is looking for a pure-basic one, it will be easier to find. Also, because it makes the topic much, much easier to read to people who weren't there at the beginning (Since it seems like I was suggesting something that was already in the program, now). I'm also curious about how much faster or how fewer bytes are in the program with that addition.

I'm not seeing a lot of optimization to do there; actually, I'm not seeing any at all. That makes me sad, because I was looking forward to coming into this topic and working miracles. While we're looking at wrapping text, though, is it safe to assume that GUIRWrappedText wouldn't quite fit your needs?

PushGUIStack -> GUIRWrappedText

It might have been helpful but I wanted the routine to have correct wrapping on input that does not have the two-byte sequence $D6,$01 because some strings will be variable on length depending on attack used, pokemon out, names, etc.

Aye, it does text-wrapping on its own without the forced newlines; the forced newlines are just if you also want your own newlines other than where the algorithm decides they should go.

You should make a new wrapped text routine that works with words

Aye, that would be one solution. I had so far chosen not to do so since the LCD is already narrow enough to begin with. I agree that for many programs such a tool might be valuable.

Edit: the fourth line from the end is missing a one

Here is some chicken scratch for prgmX, which I haven't put great care into optimizing yet

It immediately follows prgmW, and needs Str1 and L1 to function. Sorry for the photo, I'll edit my posts appropriately when I get home. What do you think you guys can do for it?

Uses the Doors implementation of routines from PicArc and xLib[/img]

Refer to topic post.

DOWNLOAD PRGM_X.ZIP HERE!

Some optimizations:

1) B=0→B becomes not(B→B

2) This code:

Code:
becomes
Code:

Very good, thanks bro! I had the second suggestion in mind already, I just forgot to put it in while rushing to put it up

Here's another one. This code:
Code:
becomes:
Code:

No, I can't use Repeat. That would break the program because the loop needs to continue as long as C≥0. Repeat would break the loop the first time C≥0 and if you remove 1→C then we won't know what C is prior to the program anyway.