text manipulation process

[+grafixbmp]

I was wanting to have text in a game actualy it may need just a bit. I was wondering if anyone has ever came up with a way to fetch the graphics you needed from sprites where there are 78 bytes which has all letters from A to Z all caps. each sprite is made up of 6 lines and has 2 letters in it. that way you can have code for text which pulls out the first letter you need in a word with the second letter you need and then save the 2 letter segment in ram and do this for a scanline then display it then go back and do it again for the next line.O

 

Or is it better to have your words already written down in memory and then just pull it up where it is at when you need it?

 

I figured this would take more memory than needed. I was thinking about when constructing a word, you could have the address in rom where 2 letters are and set a flag indicating if you need the first nibble or no flag if you need the second nibble. I wasn't sure if this would save any space or not. WHat have you guys done for text in games?

 

And BTW, where there would be text, no other thing would be happening on that part of the screen. I could even do the scroll thing. And I am using a 32k bankswitched space for rom.

Edited January 28, 2008 by grafixbmp

[Nukey Shay]

Have you looked at the text demos?

 

http://www.qotile.net/minidig/tricks.html

[TROGDOR]

Check out this blog entry. It does a 24 character display with a 26 byte RAM buffer and 512 bytes of ROM. The source code is included. (There is a bug in the code that's addressed in the blog comments.)

[Nukey Shay]

On the other hand...if the game in question as a limited number of different messages, they could be done the conventional way (saving most all of that Ram overhead). 32k is a lotta space.

[+grafixbmp]

Displaying text isn't the problem. I can do plenty of characters. The reason I was asking was that I will probably have lots of writing throughout the game and I was looking at storing 44 characters in 132 bytes. Then I can pull out the text and reorder it into words to display. I was thinking about just doing this with about 12 characters across mid screen and every single character is 6 scanlines deep. Every letter is stored in pairs so I will need to sort by first and last nibble for each letter. I only need 5 bits to store the order of each letter that is needed. I am using the following characters as of now.

 

ABCDEFGHIJKLMNOPQRSTUVWXYZ.,?!$:1234567890()

 

Spaces can be automatically generated between words so I guess 45 characters. I bet I could just use strait bytes to store the text and then use the left over 3 bits per byte for other things. I had also thought about when it came to using BG graphics, instead of crunching values from 6 bytes down to 5, just using the leftover 4 bits of each 20 bits for left and right sides of the background graphics to store the text characters (one character every 3rd byte in memory since the BG pixels just ignores)

 

I can just have code to go through the 12 characters across the screen for that segment 6 times to know what they are and then for each time, hit those letters in memory and pull them to ram and then jump 3 addresses ahead for each letter every scanline until the 6th one is done then regroup for one or two scanlines to read the next 12 characters following the previous ones.

 

For anywhere on the screen that text is being written, that is ALL that is being done. Nothing else but single color text.

 

Any thoughts?

 

PS I guess I should have a hyphen as well in case I need to split words. And BTW, since this is the Atari we are working with here, I see no reason to split words at syllables but where they physically need to be split.

 

 

 

edit: I had one other thought. If I used 6 bits instead of 5 for the order that letters come to create words. I could use the addition of the extra bit to indicate a space follows that particular letter and add it automatically without the need for an extra byte to store the space. I figured since spaces will be rather dominant, this can save bytes for writing the words.

Edited January 31, 2008 by grafixbmp

[+grafixbmp]

On the other hand...if the game in question as a limited number of different messages, they could be done the conventional way (saving most all of that Ram overhead). 32k is a lotta space.

 

I have crunched my numbers down to having roughly 8786 bytes for game code, music and text (not the physical written letters but the pointers to the physical letters) and regular graphic sprite data (main character, creatures, items etc.) I may wind up with more room as I go. Depends on how the layout/storyboard turns out.

 

As a bonus, here is the characters I want to use as they would look. I hope to call them up using 6 bits. the first 5 call the letter. I could even add a few special characters if needed. The 6th bit indicates if a space follows the letter so then the space is created automaticaly. I figured there could be about 2 or 3 blank scan lines for regrouping the next line of text and fetching the graphical data for it. I just did this a moment ago. I figured I could get away with using 6 scanlines for text instead of 7 like some others do. Saves rom space.

 

text_map.bmp

Edited February 1, 2008 by grafixbmp

[+grafixbmp]

I made a few errors in my calculations and refined the system a bit. I actually need to use 6 bits to call up the letters and I decided to use the last 2 bits for direction of the display process. With 6 bits, I have the potential to have 64 characters including the 45 I already have. the last 2 bits will be used for the following: 00 indicates no extra action. 01 indicates a space follows a letter. 10 indicates an end of text for that line and 11 indicates complete end of text for that display. I don't want to have to use flicker or blinds to get more per row. That coding will probably require the use of more ram than I want to use. I will be happy with 12 characters per row and since I plan to use 6 pix tall characters instead of the more common 7 pix tall characters, I can probably have more rows on screen than otherwise. Most text screens will have a small cut scene as well with full color bit mapped images. Granted, these images will be somewhat small, but it should be good enough for me. I Updated the text map image with a mockup of the cut scene layout and implied the 2 sizes of the images (one inside the other).

 

text_map.bmp