On Fri, 1 Dec 2006 14:30:05 -0800
"Jesse McGrew" <[EMAIL PROTECTED]> wrote:
> On 12/1/06, Alban Bedel <[EMAIL PROTECTED]> wrote:
> > On Fri, 1 Dec 2006 02:51:34 -0800
> > "Jesse McGrew" <[EMAIL PROTECTED]> wrote:
> >
> > > On 11/27/06, Alban Bedel <[EMAIL PROTECTED]> wrote:
> > > > On Mon, 27 Nov 2006 21:31:18 +0000
> > > > Stuart J Urquhart <[EMAIL PROTECTED]> wrote:
> > > [...]
> > > > > Then there's the issue of the font. At the moment the regular verb
> > > > > text
> > > > > is used, so the conversation options take up more space than they
> > > > > should.
> > > >
> > > > I dunno yet how one can set the font used by the verbs, this need some
> > > > investigations.
> > >
> > > From the ScummVM source, it looks like in V6, each verb is always
> > > drawn with the charset that was selected when the verb was
> > > initialized. (V8 has an opcode to set a verb's charset manually.) So,
> > > call initCharset(conversation_charset) before setting up the
> > > conversation verbs, and switch back to the normal charset before
> > > printing anything.
> >
> > I found that too and i think i'm going to rename the function setCharset().
> > I worked on dialogs a bit too and i just commited an implementation.
> > Currently it can't handle dialogs with more than 5 choices (ie no scrolling)
> > but otherwise it work fine.
>
> Interesting. Looks better than the one I was working on. However, one
> thing I'd like to change is the way sentences are numbered... if
> they're all numbered by the order in which they were added, then you
> still have to add empty arrays for all the disabled dialog items,
Yes, i did this so that the number returned for each sentence stay
constant independently of how many sentence have been disabled.
> and
> you have to count through all the items to find out which number will
> be returned for a certain sentence.
Hmm ? I don't really get what you mean here.
> I'd associate a numeric ID with
> each item instead, so you can call dialogAdd(id, text), and then the
> number that gets returned is the ID you specified.
Why not. From the complexity of the "backend" it is probably not very
different, so it could be a better solution.
> Some more compiler support for strings could help here too. The code
> gets repetitive having to type this all the time:
>
> sentence = 0;
> sentence[0] = "...";
> dialogAdd(sentence);
>
> (This compiles, but crashes the VM: sentence = "...";)
>
> If the compiler allocated some of the array addresses for its own use,
> we could directly use strings (or lists?) in script calls, and they'd
> be passed via temporary arrays:
>
> dialogAdd("foo bar baz");
> // same as: TEMP1 = 0; TEMP1[0] = "foo bar baz"; dialogAdd(TEMP1);
I thought a bit about that too. However it probably won't be trivial.
Currently there is no checks done on the arguments passed to scripts.
There is 2 reasons, first there is only one internal type (int), second
if some arguments are "missing" the VM set them to 0 and this is
sometimes used to have optional arguments.
So the first step would be to implement arg type checking and add some
syntax to show optional arguments (like in C++). Type checking is
requiered if the compiler need to handle some types in a special way.
Then some extra code would be needed to handle such "hidden" variables
(ie. check that there is some free variable to use, generate the extra
code, etc).
On this front i will probably rather start by adding support for static
variables and allowing local variables to be declared at the start of
any block (instead of at the start of the script only). This is easier
and more useful imho. However if you like to start with the string
stuff, patch are welcome as usual :)
Albeu
_______________________________________________
ScummC-general mailing list
[email protected]
https://mail.gna.org/listinfo/scummc-general
