Tagged: documentation Toggle Comment Threads | Keyboard Shortcuts

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

    selection_711

    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   

    plights-comments

    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:

    selection_698

    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).


    oscreceiver-ring-buffers-01

    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.


    oscreceiver-ring-buffers-02

    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.

     
  • frankiezafe 18:31 on 2016-10-07 Permalink | Reply
    Tags: , documentation, doxygen   

    First generation of documentation with doxygen and … OMG! it’s a huge mess!

    Defining an architecture and clean namespaces is really required, and must to be done as soon as possible.

    Doc is here: polymorph.cool/doxygen

    selection_697

     
  • frankiezafe 11:44 on 2016-08-18 Permalink | Reply
    Tags: documentation, ,   

    first pages of polymorph engine’s wiki starts to be ok: https://bitbucket.org/frankiezafe/polymorph-engine/wiki/Home

     
c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
Reply
e
Edit
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Cancel