Tagged: documentation Toggle Comment Threads | Keyboard Shortcuts

  • frankiezafe 14:31 on 2017-04-07 Permalink | Reply
    Tags: documentation, , wiki,   

    Documentation about the XML format used to describe projects in the engine is available in the wiki. Please note that it might change in the upcoming month…

    Link in he wiki: https://bitbucket.org/polymorphteam/pe.2.0/wiki/xml-specifications

  • frankiezafe 19:18 on 2017-04-04 Permalink | Reply
    Tags: , documentation,   

    Today, certainly one of the less sexy thing i’ve ever posted…

    How to create a unique key out of two pointers in C++?

    After some investigation and a poor attempt to use boost uint128_t, i found my way using a char array.

    Here is the code:

    SomeClass* a = new SomeClass();
    SomeClass* b = new SomeClass();
    unique = new unsigned char[ 16 ]; // room for 64bits pointers
    uintptr_t ta = reinterpret_cast<uintptr_t>(a);
    uintptr_t tb = reinterpret_cast<uintptr_t>(b);
    for ( int i = 0; i < 8; ++i ) {
        unique[ i + 8 ] = ta;
        unique[ i ] = tb;
        ta = ta >> 8;
        tb = tb >> 8;
    cout << "chars: ";
    for ( int i = 0; i < 16; ++i ) {
        cout << uint16_t( unique[i] ) << " | ";
    cout << endl;
    uintptr_t newa = 
            unique[15] << 56 | 
            unique[14] << 48 | 
            unique[13] << 40 |
            unique[12] << 32 |
            unique[11] << 24 |
            unique[10] << 16 |
            unique[9] << 8 |
    uintptr_t newb = 
            unique[7] << 56 | 
            unique[6] << 48 | 
            unique[5] << 40 |
            unique[4] << 32 |
            unique[3] << 24 |
            unique[2] << 16 |
            unique[1] << 8 |
    cout << reinterpret_cast<uintptr_t>(a) << " <> " << newa << endl;
    cout << reinterpret_cast<uintptr_t>(b) << " <> " << newb << endl;
    cout << reinterpret_cast<RoadDot*>(newa) << " <> " << a << endl;
    cout << reinterpret_cast<RoadDot*>(newb) << " <> " << b << endl;

    And… done! The pointers are casted into the very useful uintptr_t as a unsigned int, stored in the array in 8 bits chunks. On 64 bits systems, pointers use 64bits… Therefore, the char array needs to have 16 slots ( 128 / 8 = 16 ).

    At the end of the code, the pointers are recreated from the characters and compared to the original values. In my terminal, here is what i saw:

    chars: 96 | 168 | 98 | 1 | 0 | 0 | 0 | 0 | 224 | 130 | 98 | 1 | 0 | 0 | 0 | 0 | 
    23233248 <> 23233248
    23242848 <> 23242848
    0x16282e0 <> 0x16282e0
    0x162a860 <> 0x162a860

    I’ll optimise this a bit, mainly by creating the char array based on the size of the uintptr_t * 2.

  • frankiezafe 13:38 on 2017-02-17 Permalink | Reply
    Tags: , documentation, ,   

    new class in package: PMaterial.

    This class is an helper that simplify the access to the multiple layers of Ogre’s materials.
    There are 3 levels in a material:

    • technique
    • pass
    • texture units

    The usual Ogre way to access to modify a pass diffuse is looking like this:

    Ogre::MaterialPtr ptr =  Ogre::MaterialManager::getSingleton( ).load( "mat", "group" );
    ptr.getTechnique(0)->getPass(0)->setDiffuse( 1,0,0 );

    Using PMaterial, it looks like this:

    polymorph::PMaterial ptr;
    ptr.load( "mat", "group" );
    ptr.diffuse( 1,0,0 );

    Selection of technique and pass is optional. The image above shows the fog configuration:

    pmat.fogMode( Ogre::FOG_EXP );
    pmat.fogDensity( 0.1 );
    pmat.fogDistance( 10, 30 );
    pmat.fogColor( 0.4, 0.4, 0.4 );

    All methods are not yet there, do not worry, they will come soon.

  • frankiezafe 13:24 on 2017-01-09 Permalink | Reply
    Tags: documentation, , repository   


    Big revision of the repository structure this morning.

    • assets: contains blender project & python scripts, ogre 2.0 materials, puredata & processing patches;
    • custom: Ogre classes overload or common configuration files, to deplou in SDK folder;
    • empty.0.1: an empty project to start with;
    • package: the polymorph engine, containing source code;
    • samples: a folder containing examples to be used as tutorials;
    • scripts: bash scripts to install polymorph and its examples.

    A lot of doc to be written!

  • frankiezafe 18:14 on 2017-01-04 Permalink | Reply
    Tags: , , documentation   


    Planning an install party (next tuesday 10/01/2016 TO BE CONFIRMED) at the WTC with @xuv & @ptr_h to test the installation guide of the polymorph engine. If you want to be part of it, no probl’, everybody is welcome, just let me know!

    Note: the installation guide will be completed this week for linux. A guide for windows will follow.

  • frankiezafe 12:54 on 2017-01-04 Permalink | Reply
    Tags: , documentation, ,   


    Updates the engine wiki done:

    • guide for project setup with cmake
    • guide for project import in netbeans

    I realise that the installation procedure is not complete yet, and it must be done before fosdem. It’s becoming urgent!

  • frankiezafe 17:52 on 2016-11-25 Permalink | Reply
    Tags: , documentation   


    First version of doxygen documentation.

    It’s quite cool to see the mental structure i’m building since several weeks come to life in the diagrams.

    There a huge work to be done to comment and clarify the code!

    The documentation is available online: http://polymorph.cool/doxygen/

  • frankiezafe 16:40 on 2016-11-24 Permalink | Reply
    Tags: achitecture, , documentation   


    New object for lights in polymorph package.

    The image above shows that plights can be manipulated with the same methods as pnodes. This seems obvious, but it required a serious refactoring of the existing code: from now on, all “visible objects”, including sound sources, inherits from a common object, called … PObject (unexepected, isn’t it).

    The advantage of doing so is that links can be created between any kind of objects, and all are linkable to bullet.

    Conceptually, it was also mandatory to use “smart” objects in the package, and therefore being able to say that some classes are polymorphic 🙂

  • frankiezafe 20:01 on 2016-10-21 Permalink | Reply
    Tags: documentation,   

    Today: XML

    Until now, @louise was not able to access objects position and configuration… I guess it was quite frustrating for her, as she is working on the assets of the Tuning Score game.

    Now it’s better. Based on the work made for #PEEL, a XML description of the objects to load is available.

    It looks like this:


    Each polymorph node is an object having:

    • an origin transformation;
    • a local transformation, only applied on the mesh attached to this node, not its children;
    • a primitive to display, when you don’t need to load a mesh – available: cube, sphere, plane & empty (very useful, i got it now);
    • a mesh to display;
    • a material, when you want to use something else than the default one;
    • a bullet configuration, for physics, dynamic or static, with the possibility to use a special mesh and a configuration tag that gives access to a few physical parameters.

    I’m going to deploy this on louise computer and it will be over for this week!

    • frankiezafe 00:11 on 2016-10-22 Permalink | Reply

      note: provide a DTD to validate and explains the XML > check if tinyxml supports it.

  • frankiezafe 19:22 on 2016-10-19 Permalink | Reply
    Tags: , , documentation,   

    Long time no seen!

    After fixing tiny and absolutly not sexy issues in bullet code, programming went to an even less fancy topic: efficient temporary storage of udp packets.

    Indeed, OSC messages (basically udp messages) arrives asynchronously. The display thread is running at ~60fps, but messages can pop in at any time. To avoid a display thread interruption each time a message is received, they have to be stored until the main thread request them.

    The first approach was to push them in a std::vector. If the main thread never requested them, this vector might eventually become VERY long. To solve that, setting a maximum size seemed to be a good option. Each time a new message is received, if the vector is longer than maximum, the first element, witch is also the oldest, is deleted.

    There’s 2 important performance issues in this approach (fixed by the new one :)):

    • removing the first item ( =>resizing the vector) and push back an item at each reception ( =>resizing the vector once again) is not efficient at all;
    • read and write access to the same object, implying that you can not write while reading and reverse.

    Sooner in my life, someone told me about ring buffer. The name was nice and the idea behind was appealing!

    Here is what has been implemented in the class that receives and parses the OSC messages (readable text below the image, click to enlarge).


    polymorph::POscReceiver – ring buffer logic

    POscReceiver uses ring buffer to store received messages temporarily.
    If its capacity is 10, it uses an array of 10 PMessageData.
    When the maximum number of messages is reached, the oldest message is overwritten.
    The position of the oldest one is shifted by one each time a new message is stored in an “overflowed” array.


    polymorph::POscReceiver – read and write buffer

    POscReceiver uses 2 ring buffers.
    Reception and parsing are managed in a separated thread.
    Buffers are swapped when the main process request a read access.

Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc