DocProject/MainPageDoc.h

Go to the documentation of this file.

#ifndef COM_M4NKIND_MAINPAGEDOC_H
#define COM_M4NKIND_MAINPAGEDOC_H
/*!
    \file MainPageDoc.h
    \brief  This is just some documentation model to manage extra documentations,
        it is not used as a classic header.
*/
/*!
    \mainpage   
    <table align="center" width="100%" border="0" cellspacing="0" cellpadding="0"><tr>
    <td> \ref BaseContextDocGroup "BaseContext"
        \image html avshot1.jpg "Example of tool browsing classes and objects in a context." </td>
    <td> \ref BaseObject "BaseObject"
        \image html avshot3.jpg "An interface can be built automatically from an object shape." </td>
    <td> \ref BaseObjectInherited_VedaLibImage "VedaLibImage"
        \image html avshot2.jpg "Fingerprint image built with package VedaLibImage" </td>
    <td> \ref BaseObjectInherited_VedaLib3DEngine "VedaLib3DEngine"
        \image html avshot4.jpg "A preview of a 3D Object built with package VedaLib3DEngine" </td>
    <td> \ref VirtualMedia 
        \image html avshot5.jpg "Classes can manage sounds the same way as images or 3D!" </td>
    <td> \ref BaseContext::ExportAsCPPTableFile() "Context Export"
        \image html avshot6.jpg "Executables can be built from Libs and serialization for any platform!" </td>
    </tr></table>
    \section    Intro Welcome to the \mainprojectname project documentation !
                \mainprojectname is a set of libraries designed to conduct the development
                of applications. Basically, it is an experimental C++ framework,
                and can be seen as a C++ extension, which adds features that lacks to C++,
                like automatic serialization and other methods seen in java and C#, amongst
                other original features like context management or hardware abstraction. 
                It is thought for system independance, interface experimentations, 
                math experimentations, sound and graphical experimentations, 3D and more.
                It is open enough for portability to both modern and minimal systems, like embedded hardware,
                game consoles, and old hardware.\n
                 Extending this base Framework, a set of Libraries offers Math,Image, 3D and sound
                 functionnalities, that can be themselves extended:\n
                Use \mainprojectname 's base types for your class members
                and class registration, and your class will get the \mainprojectname features.

                \n
                \n <b>Before you go further, Note that this documentation is generated
                from the source comments; But Browsing by class inheritage is certainly
                not a good idea. We suggest you to read the paragraphs sorted by Theme Groups,
                as they are in the "Modules" page up there.</b>
    \section        ContextManagement   Context Management
                Context management is done by \ref BaseContextDocGroup "class BaseContext", and you can have 
                many context by applications. (Yes, that's what is called multicontext applications.) 
                Contextes are like factories; By example, to have
                a 3D modeler, you should code some 3D object classes, some texture classes,
                some camera classes, and register those classes to a context... And that's all.
                A user interface project will be able to create an application from the context,
                and manage automatically Object creation, Edition and deletion for all the classes,
                and also the serialization of the whole context state with file reading,
                writting... and merging. You can even merge 2 contextes that has
                not exactly the same classes registered: two different applications
                made with \mainprojectname on different subjects can be quickly melt to 
                share their objects.  You can use a first context with a first class set
                for your use, and a second context with a complete different class set,
                for another use, in the same application.
                An undo/redo stack is also automatically managed by each contextes,
                no need for additional code at any level.
                 But the most interesting feature must be
                the dynamic pointer management: an object within a context can point
                others objects with \ref PackObjectReference "a special pointer type". It makes possible the last following features:
                 - Destroying an object automatically unlink all pointers to it.
                 - Object dependance tracing: You can ask if an object
                   is dependant or not from another, even indirectly throught many pointers.
                 - It makes possible to extract the exact dependant object set for a given object
                    used as an entry point, to flush unused objects.
                 - It also makes possible what I will call delayed modification: If you modify
                   or destroy an object that is used by anothers (even during in a realtime rendering by example),
                   all the dependant objects will be locked in the time the modification ends.
                - To finish this list of features, the \mainprojectname context
                objects can be edited on one thread while their methods are used
                by other threads, using a lock mecanism.
                \n
    \section    VirtualMachinesec Virtual Machine
                \mainprojectname makes a point to bring
                independance everywhere: that is why the base package provides
                \ref VirtualMachineDocGroup "a pure virtual class" that defines a Machine.
                This class will keep 100% independant from other classes, and provides 
                methods for graphics, sounds, and more. You can choose
                to use the context features with or without the virtual machine, or
                use a virtual machine alone, with or without the context features.  
                The real machine-specific code is managed by each VedaMachine's specific 
                package, included in the releases.
                \n
    \section    SoundSection    Sound Management in VirtualMachine 
                the VirtualMachine class used by most \mainprojectname project
                provides \ref MachineSound "an original way to manage sounds". 
                In classic applications,
                Each time you want a sound, music or anything, you have two possibilities:
                    - You use a separate library that will play a given format.
                        InThat case,these libraries manage their own sound threads,
                        but often lack some features, or will
                        forbid the application portage because it will lack
                        on other platform. You will have problem if you want to 
                        throw multiple library inits. If you want to throw
                        some other sample of some sort, you will have to recode
                        another thread, etc...
                    - You code yourself a sound server.
                        In that case, you got to manage a system specific sound thread
                        yourself, which is quite problematic for portage.
                - \mainprojectname 's VirtualMachine got a better solution: 
                    It plays a sound thread with a float buffer, and you can
                    register mixing objects that will add their signals
                    to it. This way, you are far more free to throw
                    music, and experiment with sounds ! Furthermore, you can choose
                    to use context-managed class VirtualMedia, which
                    allows to use this system transparently, just by extending one method.
    \section    CodingRules Coding Rules
                \mainprojectname project targets at least a minimal machine that would
                have a floating point unit and more than 4Mb of memory, according to your application needs.
                 In order to assume these features, \ref BaseObjectInheritedDocByLib "The libraries that extends objects"
                from the \mainprojectname base lib should apply to these code rules:
                    - Re-entrant code. It means you <b>must not</b> use global variables,
                        and be careful with static members: Keep in mind we can have many contextes
                        at the same time. If you have to access a table as a resource, declare it
                        as <b>'static const'</b>.
                    - No assembler or machine-specific code should be used in the extended libraries
                        that inherit BaseObject, for portability purposes.
                    - You can use assembler or machine-specific optimisations
                        \ref VirtualMachineDocGroup "in Libraries that Extend the VirtualMachine".
                        They exist for this purpose.
                    - If you extend your own Library in order to share it, the totality of
                        the code it depends on should belong the \mainprojectname Workspace, in the shape of source.
                        It means you shouldn't include standard template library, or anything.
                        From now on, the only standard header used by some classes is <math.h>.
                        If you want special types,
                        use the Base package. You shouldn't use external libraries under
                        the form of link libraries, all this could break a portage. Of course,
                        you can just choose to not follow this rules for your own use.
                    - All Memory access should work in Big or Little Endians:
                        Be aware that differents processors doesn't write bytes in the same order.
                        ( Intel processors are Little Endian, PowerPC and motorola are Big Endian.)
                        If you code a simple way, this should'nt happen.
                    - Please, the more possible: align your tables in memory in a way float and int types
                        keep aligned on 4 bytes. Try to use less possible int-to-float casts.
                        (These optimisation laws doesn't accelerate much an intel, but are
                         critics for PowerPC and other processors.)
                    - You will not find any C++ operator overriding in \mainprojectname libraries,
                        It is a choice: Keeping an understandable code is a need.
                        We don't use templates for the same reason. We have short-code
                        necessities, and templates inflate the binaries at each use.
                    - We follow C++ for everything else: we use virtual methods, and
                        const operators a lot.
    \section        UnEditable  UnEditable Compilation Mode.
                 For some applications, we just need a context with
                objects that take a shape at inition, and then do not change.
                In that case, all the edition, serialization output, and events
                code should not be linked in the application. \mainprojectname 
                use a processor word, _ENGINE_EDITABLE_ that sort out
                all the code that could be useless in such application, and so
                ensure the minimal size for an executable.
                 if you want the full features, use word processor _ENGINE_EDITABLE_
                in your compilation project (usually, -D_ENGINE_EDITABLE_).
                <b>Note: this processor word trick may not be continued in further versions,
                as linkers should manage the culling of useless methods.</b>
    \section    licensessection licenses
                Each \mainprojectname libraries in the \mainprojectname workspace get a specific license when they're created.
                a 'COPYING' file defines these licenses in each directories under the workspace,
                and this license only applies to the files under this directory. You should read those files.
                VedaLib, the base package, containing the classes to extend, is released under
                the <b>GNU LESSER GENERAL PUBLIC LICENSE Version 2.1</b>( Copyright (C) 1991, 1999 Free Software Foundation, Inc)
                It means, you can link this library into free or non-free programs.
                This license encourages " the widest possible use of this library, so that it becomes
                a de-facto standard". So you may release the sources of it or not in your applications.\n
                VedaLibMath, VedaLibImage, VedaLib3DEngine, the example dir, plus VedaMachineOGL,
                VedaMachineLinux, VedaMachineOGLWinDxSound, and more,
                are also under the same license for the same reasons, but are only presenting
                possible standards, that may evolve: (It could be possible to have more than one
                Image standard in the same context, for example).\n\n
                Other Libraries and applications under the \mainprojectname Workspace directory
                may have a LGPL license <b>or not</b>. In the download section, we will provide
                with each new releases:
                    - a free LGPL version of the workspace, which will only feature the directories
                       that are under a GNU GENERAL PUBLIC LICENSE or a LESSER GNU GENERAL PUBLIC LICENSE,
                       with full sources for these directories.  
                    - a full opensource version of the workspace, including the LGPL packages with their sources,
                      plus other packages with other license types, GPL or any other opensource license.
                    - We provide free binary tools for various platforms (like UVeda) from
                         this sourceforge website.
                - The \mainprojectname Workspace library content is decided by the authors of VedaLib, the base package,
                    and more contributions may be included with it in the future.\nUpdated on 2007/04/06
*/
/*! \page InstallWorkSpacePage Installation, Workspace Architecture.
    <table><tr><td>
    <table align="left" border="0" ><tr>
    <td> \image html workspace.jpg </td>
    <td> <b>The Workspace Directory Architecture</b>\n\n
        A simple archive extraction is enough to install the whole package,
        for all systems.
        All sources for \mainprojectname 's base library and the
        \ref BaseObjectInheritedDocByLib "Libraries that extends their objects" 
        stand at the base of a Workspace directory under a VedaLibXXXX directory, where
        XXXX is the specific name of the package.\n
        Sources for the \ref VirtualMachineDocGroup "Libraries that extends VirtualMachine" are
        in the same directory, under a VedaMachineXXXX name, where XXXX explicits the
        target machine or API used to code it.\n
         Other Applications can perfectly choose to create a completly \mainprojectname-dependant
        project, in the same base directory, with any name.
        \n\n<b>Compilation Projects Are relatives to Machines.</b>\n\n
         Like a Machine directory exists for each compilable target machine,
         the same directory is used to manage each Compilation projects
         for this machine, and as base for binary outputs for these projects.
         It means, each linux .o, .lib or binaries, will be found under VedaMachineLinux
         in subdirectories, the linux target directory. This way, The Library directories are left untouch.\n
         To launch the compilation of projects for a given machine, you usually need
         to type "make" in your favorite machine directory !\n
    </td>
    <td></td>
    </tr></table>
    </td></tr></table>
    \n
    .
    \section iwas_gnu   "Makefile includes."
         As each platform will use a different compiler or cross compilers, and different makefiles,
         a makefile include, "Makefile.i" should be found in each Library source directory.
         This include explicits variables for the .o object list to create in this lib,
         for the lib name, and for the dependancies to other neighbour packages.
         Then this include file can be used by makefiles in the Machine Directories.
         This way,you just got to touch one file to manage each compilation project for each Machines.
    \section iwas_notes "Notes about project management."
        - The shape or project format of a project into a given machine is totally free!
         You can use the tool you want in the context of a machine, but this shall not
         affect the other Libs and Machines! And don't forget having a "cleaning" function
         is always useful!
        - There should be no need for Environment variables in \mainprojectname, all dependances
         to neighbour libraries can be done with relative paths. Once the Libraries are compiled,
         you may want to use them in an external project. We suggest you should copy your libs
         in your lib compiler directory, and refer each projects headers with the -I include directory option.
    
*/
/*! \page ExamplePage Code Examples
        \anchor Example_UsingASimpleSerilizedStruct
        You can use the \ref BaseSerializableClass "base types" very easily in order to 
        load, save or clone base types. Note this example will write a file on the disk!
        \code
#include "PackULong.h"
#include "PackString.h"
#include <stdio.h>
void main()
{
    // we got a simple unsigned long:
    PackULong   myUnsignedLongWriten,myUnsignedLongRead;

    myUnsignedLongWriten.Set(1337);
    myUnsignedLongWriten.WriteFile("my1337File");
    
    myUnsignedLongRead.ReadFile("my1337File");
    unsigned int value = myUnsignedLongRead.Get();
    // here it is !!!
    printf("%d !!!\n",value);
    // note MakeCloneOf() does the same, without saving a file:
    myUnsignedLongRead.MakeCloneOf(myUnsignedLongWriten);
    // the same goes for all types ! PackString manages strings:
    PackString  str1,str2;
    str1.Set("My sentence is long.");
    str1.AddString("... and It continues on and on !\n");
    str2.MakeCloneOf(str1);
    printf( str2.Get() );

}
        \endcode
        The following example Uses the automatic Serialization of the \mainprojectname \ref BaseSerializableClass "base types" In order
        to create and manage a struct, edit it a bit, then save and load it, using 
        the PackStruct class, which is a base type done for that !
        (note: this example doesn't use the context features.)
        \code
#include "PackStruct.h"
#include "PackLong.h"
#include "PackFloat.h"
#include "PackString.h"
#include <stdio.h>
void main()
{
    // serialization test
    // we just have a local test class.
    class myStruct : public PackStruct
    { public:
        // the constructor got to register the members to know what to serialize,
        // the same way as with the more complex BaseObject.
        myStruct() : PackStruct()
        {
            // second parameter 0 means no GUI name. Third is always default value:
            REGISTER_MEMBER_PACKSTRING(m_Name,0,"");
            REGISTER_MEMBER_PACKLONG(m_LongTestMember,0,0);
            REGISTER_MEMBER_PACKFLOAT(m_FloatTestMember,0,0.0f);
        };
        // declare the members of the class:
        PackString  m_Name;
        PackLong    m_LongTestMember;
        PackFloat   m_FloatTestMember;
    };
    myStruct    object1,object2;
    object1.m_Name.Set("Henry");
    object1.m_LongTestMember.Set(4);
    object1.m_FloatTestMember.Set(3.14f);

    object1.WriteFile("serializedtest");
    object2.ReadFile("serializedtest");
    printf("object2 values: name:%s long:%d float:%f\n",
        object2.m_Name.Get(),object2.m_LongTestMember.Get(),object2.m_FloatTestMember.Get());
}
        \endcode
        \n
        \anchor Example_MinimalMedia
        The next example extends a \ref VirtualMedia "Media Class" that rotates a square
        on the default screen and makes sounds, and we create one inside a context.\n
        Then we create a main that plays that media with a machine:
        (note that example doesn't use the context features.)\n
        \code
#include "BaseContext.h"
// the class to extend:
#include "VirtualMedia.h"
// we use some math functions for the sound:
#include <math.h>
// we use time.h for a timer in the main loop. Well, VirtualMachine should manage timers. exact.
#include <time.h>
// we need a machine to play the media:
// note DefaultMachine is a typedef to your platform implementation:
#include "DefaultMachine.h"
// first , we define our media class like in a header file.
// We will not register serializable members,
// but we will extend media methods:
class miniMedia : public VirtualMedia
{ public: 
    // constructor:
    miniMedia() : VirtualMedia() {};
    // define context class descriptor and destuctor: 
    BASEOBJECT_DEFINE_CLASS(miniMedia);
    // extend methods from VirtualMedia to make our media to draw and play things:
    virtual void ProcessMedia( double _frameDate,VirtualMachine::InternalViewPort *_pViewPort );
    virtual void ProcessSoundInterupt( VirtualMachine::SoundBufferToAddYourSignal &_SoundBufferToAddYourSignal );
    // extend creation and close methods from BaseObject, to make our own inits:
    virtual bool CreateInternal(void);
    virtual void CloseInternal(void);
    // now declare some specific members for our routines.
    // we could declare serializable members here, na deven dynamic pointers
    // to other context objects, but it is  not the point of the example.
    // (see examples 01 with PackStruct or any class code).
    // state for sound generation:
    float   m_sinusPostion1;
    float   m_sinusPostion2;
    // simple 3D object to be built at init, and then drawn:
    //! object created for preview.
    VirtualMachine::InternalObject3DBuffer  *m_p3DObject;
};
// ----- Here we have .cpp-like methods for miniMedia -----
// declare class descriptor, its makes possible self-build GUI and context serialization (we will not use in this example):
// "MINI" will be the tag serialized in the .avb binary contextes.
// miniMedia is the C++ name of our class we derivate from VirtualMedia
// "Media Example Class" is a name that can be displayed for this class in some GUI.
// "DefaultName" will be the base name for each new object created with this class.
// the last parameter is a short docuementation of what the class does.
BASEOBJECT_DECLARE_CLASS( "MINI", miniMedia, VirtualMedia,"Media Example Class","DefaultName","This is a class done to show how easy it is to make your own media." );
// CreateInternal must do all inits for a context object, and everything opened
// should be close in CloseInternal().
bool miniMedia::CreateInternal(void)
{
    // use superclass member to tell the media time length:
    m_MediaTimeLength = 60.0f; // 60 seconds.
    // reset state members
    m_sinusPostion1 = m_sinusPostion2 = 0.0f;
    // ask the machine the creation of a 3D object on pointer m_p3DObject,
    // with 4 vertexes, 2 triangles.
    GetMachine()->NewObject3DBuffer( &m_p3DObject, 4,2,0);
    if(m_p3DObject==0) return false; // pointer null means error !
    // give a square shape:
    VirtualMachine::InternalVertex *pVert = m_p3DObject->GetFirstVertex();
    pVert->m_x = -0.5f;
    pVert->m_y = -0.5f;
    pVert->m_z = 0.0f;
    pVert++;
    pVert->m_x = 0.5f;
    pVert->m_y = -0.5f;
    pVert->m_z = 0.0f;
    pVert++;    
    pVert->m_x = 0.5f;
    pVert->m_y = 0.5f;
    pVert->m_z = 0.0f;
    pVert++;    
    pVert->m_x = -0.5f;
    pVert->m_y = 0.5f;
    pVert->m_z = 0.0f;

    VirtualMachine::InternalTriangle *pTriangle = m_p3DObject->GetFirstTriangle();
    pTriangle->m_p0 = 1;
    pTriangle->m_p1 = 2;
    pTriangle->m_p2 = 0;
    pTriangle++;
    pTriangle->m_p0 = 0;
    pTriangle->m_p1 = 2;
    pTriangle->m_p2 = 3;
    m_p3DObject->SetNumberOfActiveTriangle(2);
    // as the square shape will not change, 
    // this line could optimize rendering:
    m_p3DObject->CompileAsStatic();
    // not: we use only colors for rendering.
    // we could also build a VirtualMachine::InternalTexture
    // to render the object.
    // The object is succesfully built !
    return true;
}
void miniMedia::CloseInternal(void)
{
    // delete the object in case it has been created.
    //note all machine delete calls do nothing if pointer is null.
    // so no need for a test:
    GetMachine()->DeleteObject3DBuffer( &m_p3DObject );

}
// we need our class descriptors, ussually with the methods in a .cpp file:
void miniMedia::ProcessMedia( double _frameDate,VirtualMachine::InternalViewPort *_pViewPort )
{
    // ProcessMedia() is useed to manage drawing, frame by frame.
    // _frameDate is given in seconds.
    // we got to draw on viewport _pViewPort, using the minimal 3D object created in the init.
    // we will rotate with the same members used for the sound generation in next method.
    // clear:
    _pViewPort->Clear(0.1f,0.1f,0.1f);
    // set transformation matrix:
    _pViewPort->Matrix_LoadID();
    _pViewPort->Matrix_Translate(0.0f,0.0f,-1.0f);
    // make the rotation do the same thing as the sound vibrato
    _pViewPort->Matrix_Rotate(sin(m_sinusPostion1*0.002f),0.0f,0.0f,-1.0f);
    // set focale length for viszion:
    _pViewPort->SetFOVLength(0.75f);
    // set the other vibrato term on the red component of the color object:
    float vibratoterm2 =0.5f+ sin(m_sinusPostion2*0.0018f) *0.5f;
    m_p3DObject->SetColor(vibratoterm2,0.25f,1.0f);
    // render our 3D object
    _pViewPort->RenderMesh( m_p3DObject );

}
void miniMedia::ProcessSoundInterupt( VirtualMachine::SoundBufferToAddYourSignal &_SoundBufferToAddYourSignal )
{
    // ProcessSoundInterupt() ask us to add a sound signal on a float buffer.
    // Here, we use some sinus functions to make a sound:
    const unsigned int  lengthToRender =_SoundBufferToAddYourSignal.m_LengthToRender ;
    // here is the buffer to add our signal:
    float           *pSoundBuffer = _SoundBufferToAddYourSignal.m_pSoundBuffer ;
    // here is the play frequency in float:
    const float freq = _SoundBufferToAddYourSignal.m_PlayFrequency ;
    float speed1 =  440.0f*4.0f/freq; // this will lead to a chord :-)
    float speed2 =  293.3*4.0f/freq;
    
    unsigned int ii;
    float fp1 = m_sinusPostion1;
    float fp2 = m_sinusPostion2;
    const float leftVolume=0.6f; // of course a factor multiply the volume.
    const float rightVolume=0.7f;
    // note this nice song suffer from float format precision artifacts !
    for(ii=0 ; ii<lengthToRender ; ii++)
    {
        float vv = sin( fp1 );
        *(pSoundBuffer++) += sin( fp1 ) *leftVolume ;   // add left signal
        *(pSoundBuffer++) += sin( fp2 ) *rightVolume; // add right signal
        fp1 +=(speed1 + sin(fp2*0.0018f)*0.004f); // set a vibrato !
        fp2 += speed2+ sin(fp1*0.002f)*0.004f;
    }
    // keep the states object to ensure continuity of the signal at next call:
    m_sinusPostion1 = fp1;
    m_sinusPostion2 = fp2;
}
// and then, our main will create and play this media:
int main(void)
{
    // we need a context and a machine: note: as we will linik the machine
    // to the context, we must assure the context is deleted first at the end,
    // and then the machine is deleted. these 2 brackets assures this:
    {
    DefaultMachine oMachine;
    {
    BaseContext     oContext;
    // init the machine, this should open a screen.
    oMachine.InitMachine();
    //register our class to the context:
    const BaseObject::ClassDescription *classList[]=
    {    
        & VirtualMedia::m_Description,  // we need to register all parent class after BaseObject.
            & miniMedia::m_Description, // class built over VirtualMedia. 
        0L // list end.
    };
    oContext.RegisterClassList(classList);
    // tell the context to work with the machine:
    oContext.SetMachine(&oMachine);
    
    // now do a simple edition on the context, just to create our object:
    miniMedia *pMiniMedia = (miniMedia *)oContext.NewObject( miniMedia::m_Description );
    if( pMiniMedia==0L ) return 1; // error ?

    // any context object should be inited with Create(),
    // and its method used if the creation succed.
    // note the object init is overriden with BaseObject::CreateInternal()
    // and BaseObject::CloseInternal().
    int result = pMiniMedia->Create();
    // a negative value means a construction error.
    // a 0 value mean construction is done, and positive values means
    // the object need more Create() calls, which can only happen with Create(false).
    // Create(false) can be used for delayed creation.
    // true means immediate creation and is a default parameter.
    if(result<0) return 1;
    // when using context object, you should first ensure that the object
    // is well created, before using its methods. Here, a miniMedia could
    // fail because the 3D object creation in CreateInternal() could fail,
    // because of short memory for example. So now we can use miniMedia.
                        
    // we do our own loop in the main, manage a timer,
    // and ask the media to draw frames whenever we can:
    // You could ask yourself why this is not automatized by the Media mechanism.
    // The answer is AzurVeda's Context framework must keep independant
    // from any shape of application. 
    clock_t startclock = clock();
    // we use the sound aspect of the media:
    pMiniMedia->SetSound(true);
    while( !oMachine.GetQuitMessage() )
    {   // get new date:
        double framedate = ((double)(clock()-startclock))/CLOCKS_PER_SEC ;
        // quit if media length ended.
        if(framedate>=pMiniMedia->GetTimeLength() ) break; 
        pMiniMedia->ProcessMediaOnDefaultViewport( framedate );
        // swap the main screen buffer.
        oMachine.GetDefaultViewPort()->SwapBuffer();
        oMachine.ProcessInterface();
    }
    // if we continue something after the loop, this should be done:
    pMiniMedia->SetSound(false);
    // close the 2 brackets, it delete the context, and then the machine, in this order:
        }
    }
    // OK
    return 0;
}
        \endcode
*/
/*! \page currentbuglistandevolution Current Bug List and evolutions.
        Bug List:
            - No bug ATM in public packages.
        - Evolutions that may come, and are discussed:.
        (Note some non-released AzurVeda projects are already working,
        but packages and licenses are on the work.) Also note that evolutions may
        mean simplification.
            - the objects graphical preview method BaseObject::ProcessPreview()
                may evolve in such a way that allows member focusing from the
                preview screen.
            - more and more context classes on various subjects.
            - some extensions done on BaseContext to allow other serialization formats.
*/
/*! \page Contribution Contribution
            We encourage anyone to contribute to this project,
            by extending context classes, machines or build tool that uses \mainprojectname.
            If an extending project is free of bug and makes sense in official
            releases, we will be happy to include it in the default package. Note the names
            of the authors appears in any files of the project. (or should)
            This site will constantly delivers informations about the evolution of the project.
*/
/*! \page authors Authors
        Here are a list of some people involved in this project:
            - Victorien Ferry (france)\n
               Hello, I'm a computer engineer who lives in toulouse
                At the moment. I've worked in the simulation industry for 5 years,
                dealing with 3D engines and interface architectures, amongst various themes.
                As an artist, I'm also known as krabob, one of the coder from
                the demo group Mankind (www.m4nkind.com), which does art with computers
                since 1995. I actually did most of the code of this project, beginning it
                in june 2005, and I also wrote most of the documentation.
                As a matter of fact, I'm actually searching a job :-).
                Contact me at victorien(REPLACE DOT)ferry(REPLACE AT)free(REPLACE DOT)fr.
            - Guillaume Portier\n
                This french computer engineer worked for game companies in japan.
                He started a similar project named makedemo in the early 2000,
                and gave some ideas about the architecture of VedaLib. He is also a coder
                of www.m4nkind.com under the nickname Exel.
                more informations about his work can be found here:
                http://exel.m4nkind.com/
            - Johann Nadalutti\n 
                Another french computer engineer, he used to work in the game industry,
                but now works on embedded software in toulouse, if I'm correct.
                He has also a similar project, and studied procedural programming.
                He is also a coder of www.m4nkind.com under the nickname Backlash.
            - Gwenaël Dano\n 
                Actually, one of the graphician of www.m4nkind.com, 
                he did the \mainprojectname logo.
*/
/*! \page MoreStrangeInformations More Strange Informations...
        Did you knew that...
            - \mainprojectname 's name was took from the veda indian book,
                    which gives a code for life, about various subjects, and teaches
                    that "everything is one". Well, actually, It was named
                    after gwen, our graphist told us a story about that:
                    One day, an english woman came to india to visit a Vedic Sage.
                    She asked him if he knew London.  The sage answered:\n
                    <b><i>"I am London!"</i></b>\n
                    So now you are aware of it, All you just need to do is being London !\n\n
            - \mainprojectname 's name may not be definitive... but... nothing is definitive!\n\n
            - \mainprojectname can be seen as the continuation of ''karate-fighter'',
                ( http://www.k-fighter.net ) , another language done for the amiga that has some
                common point with \mainprojectname. It has context management,
                many classes, two level of creation by objects and a bit
                of dynamic pointers, but that's all. \mainprojectname 's architecture
                has probably been thought silently by my unconscious left brain
                during the time "karate" was done. Well, it must be that, because I
                don't have other explaination!\n\n
*/

/*! \page page2 Greetings
        It is now high time to incriminate some people that asked nothing
        in this madness...
        Did you know that the following persons must be granted ?
            - thanks to (exel+Backlash)^mankind for all the nice ideas about the VM.
            - thanks to (bla+gwen+tex+backlash)^mkd for the bug reports last year :-) 
            - thanks to farbrausch and moppi for having demonstrated that
              a solid architecture was needed to go further.
            - thanks to Ken Perlin , because I'm a big fan !
            - thanks to SUN RA, for nothing... and in the same time... everything !
            - thanks to the guy in carbone that sold me that Dreamcast ;-)\n
              <i>(...to make it clear: he was not made from carbone, he was in the town of carbone.
               (to make it very clear: the town in question, carbone, is not made from carbone, it's the name of the town!.)
               now wait a minute... actually, as any lifeform on earth is made from carbone....arggghh)</i>
            - and by the way, hello Dreamcast scene !
            - von neuman ! Why not ?
            - Fruits. Including apples. (Even after the von neuman affair.)
            - Vegetables. Including bananas.
        - Did you know it , hu ? Well now you do.
*/


#endif

---

      /\/\        4         N         k         !         N         D
                      _______  _ __ ___  _____            ___ _ _  ____
     ___________  __//___   /________  |/    / ___________\_______/    \
    /   _   _   \/   _     /    _   /      _/_/____/    _       __     /
   /    /   /       /     /    /    \      \/     /    /    \   \     /
  \\___/___/___/    ¯    _____/_____/       ______\___/_____/\________\\
               \________/_ ___ __ l____\      /elD!  
                 http://www.m4nkind.com \____/