Demo: Green Dragon

Articles with the tag: C++

CharSim: release and summary

System architecture for version 001

What I planned in the spec is now complete and ready for release. The GLSL shaders now work at version level 120 (compatible with OpenGL 2.2) in order to support older graphics cards.

What has been the point of the project?

  • Am familiarised with 3D APIs and shaders.
  • Have explored and incorporated third-party libraries.
  • Learn and apply knowledge of mathematics and algorithms for a technical animation framework and basic game engine.
  • Handle debugging using exception handling and gdb.
  • Designed an object-oriented framework model.
  • Used C++ standard library tools (smart pointers to automatically refcount resource objects, lambda functions and their relation to STL algorithms, vectors, lists, maps, iterators).
  • Explored C++ design patterns (abstract classes used as interfaces, compositing and inheritance patterns).
  • Have worked with the distributed version control system Git for revisions and distribution.

Of course there are many features I still want to explore ...

Read More »

C++: Pointers versus references

Guides such as the C++ FAQ strongly recommend favouring the use of references over pointers. Using a const reference for getters is one option in my demo. However, to give the result a name in the class requires the declaration be made every time the function is run:

const std::vector<Bone>& bone_hierarchy = _mesh->get_bone_hierarchy();

Whereas a pointer (std::vector<Bone>*) or copied-value (std::vector<Bone>) can be declared as a private member in the class header and be mutated and and accessed by other functions.

According to http://www.parashift.com/c++-faq-lite/pass-by-value.html copied data is faster to access than references or pointers to data (in C++), so perhaps it would be better to copy the bone hierarchy structure outright each frame.

Read More »

Resource Identification

[27/02/14 20:50]

Implementing map of shared_ptrs for Mesh objects in ResMan.

Using simple name for ID. A game with many meshes would probably have a system of unique IDs, but not a live database as that would be too slow. A DB for the editor, maybe, which generates a unique ID for each asset.

Memory management

[27/02/14 20:51]

System of memory:
HDD -> Host -> Device

i.e. As a rule ResMan draws from HDD and stores meshes in Host memory then ModelNodes load it to GL buffers.

This stuff can be considered part of the caching process.

Read More »

ResMan and ModelNode interaction

Data types

class ResMan
    Mesh* GetMesh(resourceID)
    Texture* GetTexture(resourceID)

class ModelNode : SceneNode
    Mesh* _mesh
    Texture* _texture

class Renderer

Presumably Mesh* is really a GLUint associated with an OpenGL vertex buffer. Maybe Mesh can encapsulate this. ResMan should be able to unload the mesh vertex buffer from the device memory. Somehow.


Typedef Int ResourceID;
ResourceID mesh_resource_id;
ResourceID material_resource_id;

    mesh_resource_id = resman->load_mesh(filename)
    // Widely-used materials (such as a lava texture) can be spawned in GameEnv before objects grab references of them from resman. Here a model-specific material will be generated, but resman is still relevant for clones.
    material_resource_id = resman->CreateMaterial(new MaterialType(materialName, texturename, gloss, colour, etc));

    Mesh* mesh = resman->get_mesh(mesh_resource_id);
    Material* material = resman->get_material(material_resource_id);

  • If ...

Read More »

Input struct referencing and dereferencing woes

OK, struct pointers require weird casting and dereferencing to get at the data. Is it more overhead than using a class with get and set methods, though? Must make separate test file for these things.

[02/02/14 01:52]

Maybe use an array intead of a struct, since they are all ints... Depends on whether homogenous structs are slower than arrays...

[02/02/14 02:37]

Hang on - the struct doesn't need to be a pointer, only its members.

[02/02/14 16:41]

The GLFW poller function is only called on key action, so it wouldn't be too bad to have it copy a few values to a struct. This must be done for objects to handle themselves, as the callback function's values are fleeting.

It's a lot of memory copying, yes, but then the positions of objects will constantly be changing too so ...

Read More »

Framework development: Composition versus Inheritance

Speed of calls

Tutorial framework's SceneNode object inherits from Mesh, Texture and other objects. This intuitively seems like a bad idea as one has to make sure different classes don't share member names.

It should speed things up, though, as it doesn't have to make pointer calls to owned Material object.

Solution: elements contain local non-pointer Material object member and copy the passed Material's data.


This can then be called from inside the game loop for real-time material changes.

This does make objects larger, however, whereas before they would simply contain a reference to the same material object and could be all changed by changing the material. This way they'd all have to be set individually.

Composition versus Inheritance

Apparently inheritance of implementation-only things is bad, and composition should be used.

i.e. TestWorld invokes GameEngine object. Is this composition, and is ...

Read More »

Page 1 / 2 Older »