Tagged: game engine Toggle Comment Threads | Keyboard Shortcuts

  • xuv 18:52 on 2017-03-21 Permalink | Reply
    Tags: , game engine, itch.io,   

    Polymorph Engine is on itch.io 

    The Polymorph Engine is on itch.io, the go-to community website for sharing, rating and downloading indie games. It sits in the well-named “tools” section where it is already getting some attention.

    But we need your help to bring it further. So if you have an itch.io account, be sure to check the Polymorph Engine page, download the install script, give it a 5 stars ratings, or even add it to your favorites.

    While you are there, be also sure to check out and follow Frankie and xuv profiles and collections, you might discover some gems.

    Let us know about your itch.io profile in the comments. We’ll be sure to check it out.

     
  • frankiezafe 21:10 on 2017-02-22 Permalink | Reply
    Tags: , game engine, ,   

    Several hours of work later, the class PMaterial is fully integrated to PNode. This part has been tricky: materials and textures are shared objects, managed by managers below the objects.

    The approach is to create PMaterial on demand, when you call pnode.getMaterial, for instance. Once created, it stays in the pnode until you destroy it or overwrite the material with another.

    This limits the memory consumption and force the coder to always retrieve the material pointer from the pnode, and not to store it.

    Another cool feature of the pnode.getMaterial is that the material can be created RT if the mesh doesn’t specify one.

    On the PMaterial level, it is becoming very easy to add the methods to access the different layers of the Ogre material.

    For instance, here is the code used to create the 2 materials applied on the balls in the image above:

    pmat_even.create( "Test", "Nice material" );
    pmat_even.diffuse( 1, 0, 0 );
    // activation of fog
    pmat_even.fogMode( Ogre::FOG_EXP );
    pmat_even.fogDensity( 0.1 );
    pmat_even.fogDistance( 10, 15 );
    pmat_even.fogColor( 0.4, 0.4, 0.4 ); // same as background
    // cloning pmat_even in pmat_odd
    pmat_odd.clone( &pmat_even );
    pmat_odd.fogColor( 0.8, 0.8, 0.8 );
    pmat_odd.shading( Ogre::SO_FLAT );
    // adding a pass on the material
    pmat_odd.addPass();
    // there are now 2 passes in technique 0 of this material
    uint tid = 0;
    uint pid = 1;
    pmat_odd.emissive( 1,0,1, tid,pid );
    pmat_odd.shading( Ogre::SO_FLAT, tid,pid );
    pmat_odd.polygon( Ogre::PM_WIREFRAME, tid,pid );
    

    It’s super easy to clone a material, at creation or via the clone method. The second pass of the odd material have to be set manually. Passes are not cloneable (yet?).

    As you may notice, mentioning the technique or pass to attack is optional. If your material has only one technique and one pass, the call is very short. Once you beginning to build a more complex material, adding 2 uint at the end of your arguments should not be too difficult…

    The material of the cube is also created manually:

    PMaterial pmat2( pmat_even );
    // disabling the fog
    pmat2.fogMode( Ogre::FOG_NONE );
    pmat2.diffuse( 1, 1, 1 );
    // checking the number of textures
    if ( pmat2.getTextureUnitCount( ) == 0 ) {
    	// adding one 
    	pmat2.addTexture( "General", "child-computer.jpg" );
    } else {
    	// modifying the first one
    	pmat2.setTexture( "General", "child-computer.jpg" );
    }
    cube.material( &pmat2, true );
    

    More, soon!

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

    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 23:59 on 2017-01-13 Permalink | Reply
    Tags: , game engine, , , visualisation   

    screenshot01132017_235526088

    screenshot01132017_235531770

    screenshot01132017_235541017

    Working on a debugging view for skeletons, a good way to learn how #ogre3d is storing skeletal data. There’s a scaling issue: the points in the face are not correctly placed, they should be at the lips borders, at the basis of the nose and closer to the eyebrows.

    The visualisation is not the same as in blender: bones are linked to their parent head, not tail. It’s simply because the information about the size of the bone is not available in ogre. The only information available for a bone are its position and orientation.

    A fix will come soon!

     
  • xuv 17:35 on 2017-01-09 Permalink | Reply
    Tags: game engine, installation, ,   

    Polymorph Engine on ArchLinux 

    Thanks to the great work and tutorial from @frankiezafe, I managed to compile and run the basic examples of Polymorph on an ArchLinux system. I had to make a few changes to the documentation and find the right flags for some libraries (instructions here). But everything seems to be running smoothly. More tests to come later, I guess.

    ArchLinux screenshot running Polymorph Engnie basic sample

    Save

     
  • frankiezafe 23:42 on 2017-01-03 Permalink | Reply
    Tags: , , game engine, ,   

    screenshot01032017_233404150

    Today, a lot of bug fixes on the basic classes of the polymorph packages.

    New: it is now possible to declare the resources folders in the XML! The common resources.cfg of Ogre can be replaced by a configuration.xml, placed in the same folder as the exec.

    The resources.cfg was looking like this:

    [Essential]
    Zip=../media/packs/PolymorphTrays.zip

    [General]
    FileSystem=../media
    FileSystem=../media/materials/scripts
    FileSystem=../media/materials/textures
    FileSystem=../media/models

    In the XML, it’s converted to this, with control over recursivity and read access.

        <resources>
            <group name=”Essential”>
                <resource path=”../media/packs/PolymorphTrays.zip” type=”Zip”/>
            </group>
            <group name=”General”>
                <resource path=”../media/models” type=”FileSystem” recursive=”1″ readonly=”0″/>
                <resource path=”../media/materials” type=”FileSystem” recursive=”1″ readonly=”0″/>
                <resource path=”../media/materials/textures” type=”FileSystem” recursive=”1″ readonly=”0″/>
            </group>
        </resources>

    The sreenshot comes from an evolution of the XML example, see Dynamic scenes loading

     
  • frankiezafe 18:40 on 2016-11-25 Permalink | Reply
    Tags: , , game engine,   

    scene-loading

    Dynamic scenes loading.

    Based on an #XML description of the project, that looks like this:

    • <polymorph version=”0.1″ date=”20161124″>
      • <scenes>
        • <scene id=”3″>
          • <pobjects>
            • <plight name=”main_sun” visible=”1″ debug=”1″>
            • <pnode name=”floor” visible=”1″ debug=”0″>

    and so on, it is easy to load a new scene. The deletion and creation job is managed by a cool object call “PObjectManager” see: http://polymorph.cool/doxygen/classpolymorph_1_1_p_object_manager.html (thanks, doxygen!)

    In the example.1.xml, the key ‘n’ is binded to the method PObjectManager.nextScene().

    A little note: in the scene 1 (the middle one), the pile of plates has been done via a special tag:

    <repeat count=”20″ offset_pos=”0,10,0″ offset_dir=”0,5,0″ offset_scale=”-2,0,-2″ />

    When placed in a pnode, it will generate copies of the object automatically. Similar to array modifier of blender.

     
  • frankiezafe 19:35 on 2016-11-20 Permalink | Reply
    Tags: game engine, programming,   

    selection_709

    Here is the output and the code of the empty example. It is using polymorph package.

    Once installed (the tricky part, soon fixed with a magic installation script), you just have to extends PolymorphApplication class and start working.

    As you may notice, the class CustomApp does nothing on its own. It just calls the mother class’ methods. The purpose of this empty project is to enlight crucial methods to overwrite in order to start coding something.

    I’m now working on a basic example, showing how to add primitives, load meshes, add lights and animate them.

     
    • frankiezafe 21:34 on 2016-11-20 Permalink | Reply

      @xuv & @balt : i think it’s important to be obvious on what is polymorph and what is ogre by keeping the namespaces as they are. For instance, creating a PNode requires to call polymorph::PNode. When you want to create a vec3, there you have to call Ogre::Vector3.
      In the example above, the using namespace is only used in cpp => for all class params (.h), they have to be set this way. It will be explained in the basic example.
      What d’u think?

      • xuv 14:19 on 2016-11-21 Permalink | Reply

        @frankiezafe : seems coherent.

        • frankiezafe 15:53 on 2016-11-21 Permalink | Reply

          i’ve started working on a “PObject”, wich is a common ground for PNodes, PLights and PSounds. It’s a abstract object defining anyhting located in the 3d world, with possibility to attach them together or add physics on them.
          Result: ultra tuff conceptual work, using an abstract class + a template class for PObject – will work in a few days.

  • frankiezafe 17:05 on 2016-11-19 Permalink | Reply
    Tags: , , game engine,   

    Polymorph package is on its way!

    Until today, polymorph was a collection of Ogre addons, independent from each other. The approach has changed a lot during the development of Tuning score. All extra libraries are now linked into one big package:

    • Bullet – physical engine;
    • libPD – sound engine;
    • OSC – Open Sound Control messages, based on udp;
    • tinyXML – for project loading;
    • SDL – for gamepad and joysticks.

    The package uses a project file format, in XML + provides high-level objects and a base class containing all mandatory methods to manage a game:

    • scene & resources loading;
    • window management and events;
    • keyboard and mouse events.

    A large documentation has to be written, but programming architecture is now fixed.

     
  • xuv 17:43 on 2016-10-25 Permalink | Reply
    Tags: game engine, , ,   

    Polymorph weekly news #9 

    Tuning Scores chair physics

    No news is good news. Polymorph is alive and kicking. The train is on its tracks. The ball is rolling.

    It’s already almost a week since I’ve chatted with @frankiezafe and @louise about the advancements of their project. You might have also noted that they don’t post much either on this blog. As François says it, it’s because the progress they make is not that big of  step to share, or does not produce some visuals that would look good on the blog. Back a couple weeks, when features where being added almost every day, things were exciting. Now, the real work of polishing and improving what has been initiated is actually happening and that just does not seem as exciting to share. Although it’s exciting for the team to see it growing.

    A second meeting with Contredanse was much more productive and finally we started talking about gameplay. Baptiste and Florence could put their hands on the mouse and feel what a player could feel. Discussion ensued on object movements and reactions in the virtual world. The manipulation of the camera created interesting problems and awkwardness that needs to be addressed. And a common set of objects has been defined and should be limited to a stone, a stick, a chair, a cup and a chain for now. @louise is iterating on the appearance of those and playing around with their physics properties.

    François is deep into physics programming. He also took a big decision regarding all the tools he is building. Instead of trying to produce some independent Ogre libraries, he will concentrate on making it all work in the Polymorph Engine (PE). As a reminder, the PE is a bundle, a package of great open source libraries to make video games. The choice to release work as a bundle instead as independent modules is mainly a practical one. It will take less time to code. The modules are also very much interdependent for now. So making them detachable from the PE would require extra work that the team does not have at the moment. Maybe in the future. But again, making a full featured game engine on top of Ogre was always one of the goal of Polymorph. The ability to break this apart is then for later.

    Where is PEEL you might ask? On hold for now. Tuning Scores is the priority since the prototype needs to be delivered by December. All eyes are on this goal now. And challenges remain, such as multiple mouses input for example. Anyway, all progress on Tuning Score is good for PEEL. So no worries, François will be back on it for Christmas.

    See you next time.

    PS: All screenshots by @louise

    Tuning Scores chair

     
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