PTC 2.0 Porting Kit - Console options
-------------------------------------


Because the PTC api is a very simple core specification, the
implementer of PTC on a new platform often finds that there is
not enough bandwidth in the api for the ptc user to describe
platform specific options to the console.

If you have already read "extend.txt" then you would think that
one way around this would be to just add a custom function
like follows:

    void Console::flags(int flags);

The problem with this, is that typically ALL platforms have a
need for some extra level of control over the console. If this
is so, then shouldnt this be part of the CORE api?

I've thought about this for a while, and i have decided YES.
So i've added the following function to the Console class:

    bool Console::option(const char string[]);

The exact format of the string is platform specific, and if
an option string is passed to a platform that does not recognize
it, then the function will return "false", if the string is
recognised then "true" will be returned.

Here is some examples to give you an idea of how the options
function would work in a console implementation:

    // create console
    Console console;

    // set some console options
    console.option("use directx");
    console.option("fullscreen only");
    console.option("use multithreaded wndproc");

    // set an option and check if it worked
    if (!console.option("does this option exist?")) throw Error("nup");

    // create format
    Format format(32,0x00FF0000,0x0000FF00,0x000000FF);

    // open the console
    console.open("Options example",format);

The example above is a mockup, but is pretty close to how i would
implement an options system for a Win32 PTC implementation.

Please note that the options exist on a per-console basis only. If
an option is set for one console object, it isnt set for any others,
also if you set an option on one console... then create another you
will need to set the options again for the new console.

Note that i've made the option strings pretty much plain english
in the example above, although i think this is the nicest way to
do it, the implementer is free to set any option strings they
like, in any format they want. Just as long as all the options
are documented in the distribution! :)