Re: Scripting

[Steve Baker <sjbaker1@airmail.net>]

Gregor Mueckl wrote:

> > Mine is OpenSourced - but you'll have to extract it from the guts of
> > TuxAQFH.  I should probably make a separate package out of it sometime.
> 
> Well... I'll have a look at this one. I would have preferred an
> object-oriented language, but the overhead involved probably doesn't pay
> out with better code structure within the scripts.

Yes - I regard scripts as ways to connect together large-ish building
blocks - so whilst OOP would have been nice, I didn't sweat it. 


> > I believe that portability is important.  I don't want an x86 monopoly
> > any more than I want a Microsoft monopoly.  I often run my code on other
> > CPU's though - so whilst 90% of people may not care, I'm one of the other
> > 10% and when I'm the one writing the code - I get to choose!
> >
> 
> True. The x86 hardware is just bloated. I don't have the need to execute
> binary code that has been created ten to fiveteen years ago. But every
> single cutting-edge Intel-compatible PC can run these binaries natively,
> although modern software no longer needed it, would the boot process be
> in protected mode already.

I don't pick non-x86 CPU's by special choice - and certainly not on the
basis of performance.

Some of the stuff I work on is for Linux PDA's and some for a future
hand-held game machine that'll run Linux (and do reasonable 3D).  If
you want a low power consumption CPU, you're basically not looking at
Pentiums.
 
>> I've done several projects on MIPS CPU's.
> 
> The platform one uses mostly depends on taste - and money :).

...or the requirements of the clients who are paying the bill!

> >>Wouldn't it be better to revert to an event handler system then? If the
> >>scripts are that simple (I'm refering to your emamples below now) it
> >>could be far better to do it this way than letting your scripts loop
> >>within a virtual thread and thereby wasting time *every* frame instead
> >>of wasting time only when really needed.
> >>
> >
> > They don't have to run every frame - they have a 'Wait until...' bytecode
> > that puts them on a list of processes that are stalled waiting to run.
> >
> 
> So you actually poll for events. As far as the engine is concerned it's
> similar to event handlers in implementation, but it removes the need for
> saving states within the script.

Yes. Exactly.

> Neat trick, but you'll have to take
> care that the script returns often and regularly enough, which is a
> minor concern actually (even OSes have depended on this and it has
> worked out somehow :).

Well, the alternative 'event-driven' approach has the exact same
restriction.

> Yes, that's probably the way to do it. I'm already wondering about
> implementing the parser for such a language. Unfortunately, I've
> failed at similar things before:(.

If you aren't confident about writing a good parser, I *STRONGLY*
advise
you to learn YACC and LEX (or BISON and FLEX in a GNU world).

These things can write parsers for you in about as much time as it takes
to write down the grammar for the language you want to parse.

It's easy.
 
----------------------------- Steve Baker -------------------------------
Mail : <sjbaker1@airmail.net>   WorkMail: <sjbaker@link.com>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net