Updates

[GoogleCodeExporter]

Just some notes on what I updated.

I made a key input "API" that you may not like, and if you don't then feel 
free to modify it as you want. I would like to keep the key defines, but 
the KeyGroup1...7's may not be needed. As I said, feel free to modify 
it/take it out as you please.

Secondly check out font_notes.txt(best viewed in Notepad, not a web 
browser because the text won't wrap) for my solution to handling the text 
output. I would like feedback on this, and whether you feel this is the 
best route. If you do agree with it, I would like to here what names you 
would like to use for the extended characters. Thank you.

Original issue reported on code.google.com by Halif...@gmail.com on 12 Nov 2007 at 4:06

[GoogleCodeExporter]

Well, strings still need to be null terminated, so the hex value of $00 should 
not be
assigned to anything that needs to be printed.  So the character "0" shouldn't 
be
assigned the hex value of $00 otherwise, if you're writing your appSafePutS, you
can't put the character "0" in the string without terminating the routine.

The other thing I wanted to mention was do you mind if you write the converter 
in
Java?  For the most part class files or java source works better.  Or make it an
on-calc utility.  Thanks!

For the most part, I like the names.  Here's what the others should be named, 
based
only on what I think they were intended to do:
52 - [li]
53 - [il]  
54 - [ll]
58 - [half_up_left]
59 - [half_up_right] 
62 - [staff]
64 - [book]
65 - [armor]
66 - [gauntlet]
67 - [ring]
68 - [potion]
69 - [key]
70 - [poison]
71 - [divider]
72 - [bc_top_left]
73 - [bs_top]
74 - [bc_top_right]
75 - [bs_left]
76 - [bs_rihgt]
77 - [bc_down_left]
78 - [bs_down]
79 - [bc_down_right]
80-83 - [status#] <- # is 1-4; 1 is left, 4 is right most part
84-86 - [equip#]
87-89 - [item#]
90-93 - [command#]
94 - [b_icon_left]
95 - [b_icon_right]

Over all, you can name them however you see fit.  I hope that this helped you
understand what each symbol does/represents.  Actually, as a result of how this
character set was designed, you could probably construct entire menus from just 
one
long string if you do it right.  Just send me a final list of what you decided 
to
name everything.

Original comment by LiazonKa...@gmail.com on 12 Nov 2007 at 5:02

[GoogleCodeExporter]

Ok, yes, 0x00 cannot be assigned to anything. Also I don't think I am going to 
totally write my own appSafePutS because yours provides a good basis.

Also, sorry, I don't know Java, I don't have a compiler, and I don't plan on 
learning Java. :(

I will be writing it in C. Is there a "serious" problem with the use of C? (I 
can 
even use C++ if that is more preferable.)

Original comment by Halif...@gmail.com on 12 Nov 2007 at 9:49

[GoogleCodeExporter]

EDIT: One question. Is 0xFF going to be used for any text?

Original comment by Halif...@gmail.com on 12 Nov 2007 at 9:50

[GoogleCodeExporter]

ok, just make it easy to run :)

as for your second concern, I'm not sure if it will be used.  We don't have 
that many
characters at the moment.  In fact, we could probably fit the entire tileset and
custom font into one thing ^^ that's how few tiles we actually have.  So if you 
want
to do any cool optimization with 0xFF, go ahead :)

as for the key "API", I like it and I'll probably keep it.  I don't think we'll 
ever
need to check all the keys, but it's good to have in case we decide to put in 
some
easter eggs or something.

Original comment by LiazonKa...@gmail.com on 12 Nov 2007 at 11:23

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I updated the "font_notes.txt" file with the info you needed. Also, I need to 
note a
couple of things about the font's usage:

 - Spaces never appear after commas and other punctuation. There's enough trailing
space after each one to make this unnecessary.

 - Some characters are multi-byte, meaning they must be arranged together to form
menus, borders and other items longer than the standard 8 pixel width.

 - The LI, LL and IL characters are used to conserve space, when you're inputting
words like SILVER or ELIXER. This shortens the length of such words, 
respectively.

I hope that clears up any confusion.

Original comment by ghilmars...@gmail.com on 12 Nov 2007 at 11:45

[GoogleCodeExporter]

Ah, yes this does clear up things.

I have another question though, is there going to be scrolling text in this 
game? 
For example, when the text reaches the barrier it scrolls up, and then 
continues 
to "type"?

If so I am thinking of structing the data as such:

.db "Text, text, and",-1
.db "More text,",-1
.db "and more!",-2

Now of course the limitations to this are that 0xFF, and 0xFE cannot be used 
because 
they are being used for scrolling, and null termination respectively.

Also another note on the text compiler. Should I implement an "auto breaker" 
such 
that it breaks the text string up into the pieces when the right screen 
limitation 
has been reacher. e.g.

[test.txt]
This is a very long string that I want to compile, muhahaha!

[cmd.exe]
textcomp test.txt

produces(supposing the limitation on the number of characters per line is 16):

.db "This is a very l",-1
.db "ong string that ",-1
.db "I want to compil",-1
.db "e, muhahaha!",-2

Now of course, as I am sure you have thought of, this brings up a limitation 
where 
the user cannot specify where to break the lines. So any suggestions on how to 
overcome this, or whether I should just stick with no auto-breaking?

Original comment by Halif...@gmail.com on 13 Nov 2007 at 8:29

[GoogleCodeExporter]

Update: Currently the Text Compiler parser is done. Heh, pretty simple. It is 
committed to the SVN, source, exe, and everything else. To run the compiler:

textcomp test.txt

I even included a test.txt for you to use. It currently displays debugging 
information too.

textcomp ignores whitespace so you can type all the text you want into one 
file, and 
then compile it!

The generation can be done easily, but I would like to know if I should 
implement 
auto-break before I do the generation of the actual data. (Although technically 
it 
displays what it will generate in the command prompt window)

Original comment by Halif...@gmail.com on 13 Nov 2007 at 10:32

[GoogleCodeExporter]

Also, note, that the source is in a horrible state. It is meant as one-time 
code 
that no one was really supposed to be able to see. But I included it just in 
case 
one of you is working on Linux or something.

Original comment by Halif...@gmail.com on 13 Nov 2007 at 10:33

[GoogleCodeExporter]

No, the text does not scroll. It simply displays each two lines followed by the 
next
two lines instantly. You'll notice a little arrow super-imposed on the right 
side of
the dialogue window whenever the message is longer than the window. Pressing the
confirm button instantly goes to the next two lines in the dialogue. Should I 
produce
a screen sample to demonstrate this? It looks something like this:

+----------+
|"THIS IS A|
|LONGER    >
+----------+

+----------+
|DIALOGUE  |
|WINDOW."  |
+----------+

Original comment by ghilmars...@gmail.com on 14 Nov 2007 at 5:35

[GoogleCodeExporter]

No, no, I got it. Also, from what you have provided, it seems as though 
auto-break 
is a bad idea, so I am just going to make it user specified breaking through 
the '_' 
character.

Well, let me finish up this textcomp program.

Original comment by Halif...@gmail.com on 14 Nov 2007 at 9:15

[GoogleCodeExporter]

textcomp is finished, and you can look at the example test.txt I provided for 
how to 
write text, or the other two text files that I compiled which are available 
in /text_compiler/LL_compiled_text.

You can check where I left off in /LL_compiled_text/dialogue_batch.txt and try 
to 
complete it if you want...but I will probably get to it.

Original comment by Halif...@gmail.com on 14 Nov 2007 at 10:52

[GoogleCodeExporter]

Okay, there are a couple of problems here...

1.) We haven't really discussed how to handle the window frames. Are these 
going to
be part of the font, and designated to wrap around the dialogue for every text
window, or can we work it in some other way? (I originally planned for them to 
be
part of the font)

2.) You didn't see the notations I made in the dialogue file. For instance, 
where it
says "XXXXX GP," I added a note stating that X=whatever the GP cost is. (this 
depends
on the item, vendor, etc.) Instead, you formatted the text with all of that 
stuff
left in. We need to add some kind of variable strings to the dialogue to patch 
those
areas.

3.) I haven't explained the custom table I was using at the time I wrote the
dialogue. For instance, an underscore represents an ellipsis. (...) I'll need 
to redo
the dialogue according to the table reference you created, or we'll have to 
redo the
table reference. Either way.

4.) After I specified that space aren't inserted after punctuation, you added 
them
anyway. :P

You're rushing ahead a bit. Try to check with me before you start on areas like 
this,
so there isn't any confusion as to how things operate. Believe me, I've planned 
every
aspect of the game out already. There's no need to go off on your own and plan
different ways to implement things. Just check with me and I can explain all of 
this
no problem.

Original comment by ghilmars...@gmail.com on 15 Nov 2007 at 12:37

[GoogleCodeExporter]

I can't speak entirely for Halifax, but I can probably guess what we'll do.

1.)
at run time, we can probably write the code so that the font codes for the 
window
frames are either attached to the beginning and end of a line.  Or we could 
write it
so that when text is retrieved, it will be put in RAM, and then modified to 
have the
window things attached to those strings, then put to the screen.  For the most 
part
it's Halifax's call, but you happened to design it so it'd be convenient to put
everything as a giant string and print it all.  

btw, this won't work as well for your small font in LL2 because a byte holds 8
pixels, and in order for the 4x5 font to be placed one after another, we have 
to use
masks.  As a result, it's more convenient to use line drawing routines to draw 
the
window frame first, fill it up w/ gray inside, and then print strings.  This is
because the masked routines take awhile and there are so many characters to 
print out
if we used the frame as part of the font.  Just a heads up for LL2, so you 
don't have
to plan your window frame to be part of the font :)

2.)
Halifax probably didn't know.  So it'll probably have to be reformatted 
slightly. 
Fortunately, you and I could run his program if we needed to so if you want to 
make
the changes, you can do so.  That's why he wrote the program in the first 
place.  so
all of us could just run a text file through it and get formatted text for the 
source
code.

As for inserting the names of stuff into the string, that will probably have to 
be
handled by the menu system, which will probably be written later on.  Are all 
the
names of the weapons and stuff the same # of characters, or are they variable?  
It
doesn't matter, I think it'd be useful for us to know ahead of time.

3+4.)
i see, so you already had a system set up before.

Geez, you know with this level of planning, you could have simply learned the 
basics
of ASM and just coded this yourself after awhile ^^

Original comment by LiazonKa...@gmail.com on 15 Nov 2007 at 12:53

[GoogleCodeExporter]

Hmm. I guess I'll just ask Halifax how he wants to handle it, and then go from 
there.
If it's easier to implement it a certain way, I don't mind reformatting it --
whatever is convenient for you guys.

As for the planning, I basically planned every single detail. However, bear in 
mind I
did this according to how data is normally arranged per NES ASM. With NES 
games, the
dialogue is just another aspect of the graphics data, and is arranged on screen 
like
any other tile. This was the only method I understood at the time, based on
ROM-hacking experiences.

Original comment by ghilmars...@gmail.com on 15 Nov 2007 at 1:03

[GoogleCodeExporter]

Alright, sorry to say I don't have much time right now, but Liazon basically 
stated 
everything that I would have covered.

Overall I wrote up that test text just to give YOU guys a template to edit. I 
really 
don't intend on being the only one handling the text. I setup the tool to give 
you, 
grendel, a little bit more control over how you want things to be. So go ahead 
and 
modify the life out of those files, etc., no worries.

I really need to talk in person to you, and will try to within the weekend or 
something.

Original comment by Halif...@gmail.com on 15 Nov 2007 at 4:23

[GoogleCodeExporter]

Also, sorry for putting spaces after the commas. I am just used to doing that 
when 
typing...I am just trying to setup some stuff. I'm not doing this stuff on 
purpose.

Original comment by Halif...@gmail.com on 15 Nov 2007 at 5:00

[GoogleCodeExporter]

So, what I should do is reformat the original dialogue file using the table 
reference
you provided? (just checking before I get started on it)

By the way, I included my contact info (AIM / Yahoo) on my Omnimaga profile. Do 
you
use either of those services?

Original comment by ghilmars...@gmail.com on 15 Nov 2007 at 10:40

[GoogleCodeExporter]

Umm if by reformt you mean follow the format of the examples that are there, 
then yes

Yes, I use AIM, I will be on there today

Original comment by Halif...@gmail.com on 16 Nov 2007 at 9:32

[GoogleCodeExporter]

Okay, I've run into a small problem -- how can I specify the dialogue window 
position
for each text string? Sometimes, the window should be displayed on the top-most 
part
of the screen, and other times it needs to be displayed on the bottom-most part.

Original comment by ghilmars...@gmail.com on 24 Nov 2007 at 11:26

[GoogleCodeExporter]

This is going into Lost Legends I?

If the answer to that question above is yes, then I need to know how many 
positions 
you want to have. Just 2?

Original comment by Halif...@gmail.com on 25 Nov 2007 at 12:20

[GoogleCodeExporter]

Of course this is for LL1. :P

Yes, there are only two positions -- top-most and bottom-most points. The 
window size
always remains the same.

Original comment by ghilmars...@gmail.com on 25 Nov 2007 at 4:40