Tagged: analysis Toggle Comment Threads | Keyboard Shortcuts

  • frankiezafe 22:39 on 2017-02-10 Permalink | Reply
    Tags: analysis, , , , ,   

    I’ve learned something really important today: an OpenGL context can be accessed by one and ONLY one thread! See Under what circumstances would glGenBuffers/glGenBuffersARB fail?.

    And this is the first time I feel annoyed by the singleton approach of Ogre3D. In my asset converter util, I use Ogre object, the MeshManager mainly, to convert xml files to .mesh files. Due to the limitation of OpenGL and the singleton pattern, I can’t declare a new OpenGL context in my conversion thread by using the Ogre managers…

    I struggled for several hours with that before find the post on stackoverflow.

    This implies a freeze during mesh conversion, wich prevent me to animate a progress bar and keeping the conversion strickly in background.

    I’ll work on the loading and display of the processed meshes next week.

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

    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.

  • frankiezafe 11:29 on 2016-09-16 Permalink | Reply
    Tags: analysis, , ,   

    A bit of architecture

    Concerns sound sources located in the 3d environment.

    On the C++ side, sound::system manages all the sound sources and knowns about the location and orientation of the cam. It also contains the general configuration of the mix (gain, number of tracks, etc.).

    At each frame, the sound::system renders a serie of relations, representing the position of sources in the camera local coordinates (where are the sound sources in the user point of view, to be a bit simplier).

    The sound::system being aware of the number of tracks in the sound engine, it is able to manage efficiently wich source to send to witch track. For instance, if the number of active sound sources is higher than the number of tracks, sound::system will order the closer or the most important sources to send to the sound engine.

    On the #puredata side, the job is simplified. All tracks are similar and reacts to messages sent by sound::system.

    Each sound source knowns about the sound file to load. This info is sent onnce when the source becomes active : activated status.

    Sound::system is able to handle 2 types of communication.

    • In edition, it sends osc messages to puredata, the program with graphical interface. This allows musician to work live on the sound.
    • In production, it sends the messages to libpd internally.

    This 2 modes implies using custom objects in pd that are able to use both modes.


    Thanks to @yacine_sebti for his expertise in pd.

    Currently in development in #peel.

  • frankiezafe 16:16 on 2016-08-15 Permalink | Reply
    Tags: analysis, , ,   

    Game logic on its way: tube is closing correctly, only when top and bottom are aligned. No time to make a video today, so i post a serie of 3 pictures showing the connection animation, programmatically validated.




    For those who like schema, here is , in a very abstract form, the relations between objects.


  • frankiezafe 12:44 on 2016-07-15 Permalink | Reply
    Tags: analysis,   

    The graphical research of yesterday was driven by a structure problem: how to describe progammatically game objects more complex then a tube with 2 ends. This forced me to review the analysis i’ve made before , based on simple geometries.
    Each game object will now be a group of several specialised objects: a segment (the main part), and “joints”, containing pushers and switches.



    Joint structure


  • frankiezafe 14:30 on 2016-07-11 Permalink | Reply
    Tags: analysis, ,   

    Working on PEEL basic concepts, defining the programmatic objects.

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