Tag: RegEngine

Entries for tag "RegEngine", ordered from most recent. Entry count: 3.

Warning! Some information on this page is older than 5 years now. I keep it for reference, but it probably doesn't reflect my current knowledge and beliefs.

Pages: 1

# Reflection in RegEngine - Part 2

Jul 2010

In the Part 1 I've shown the basics of my reflection system - classes that describe a class, property and enum. Now the question arises about how do I actually create these objects? Where do I get the information about the classes and properties in my code from? There are many possibilities which I considered:

[*] The simplest one would be to explicitly build these data structures by hand - white some initialization code that would do new Class(...);, new FloatProperty(...) and so on. Oviously this is also the most inconvenient way.

[*] Objects describing classes and properties could be automatically generated by code created by some smart usage of C++ macros and templates. I mean declaring classes and their field using something like DECLARE_CLASS(MyClass, ParentClass) and DECLARE_PROPERTY(Prop1, float), either instead or next to the real class and member declarations. This might be a good idea.

[*] Finally, a separate file with either description of classes and properties in some format or a direct C++ code for building it could be generated from some input data. These input data could be extracted from:

I've decided to create class- and property-describing objects by hand in C++ code but on top of that I've coded an optional tool that takes description file in a special language and automtically generates such code. The code written by hand looks like this:

// Header file

class ComplexItemObject : public ItemObject
    static void RegisterClass_();
    static Class * GetClass() { return m_Class; }
    virtual Class * Object_GetClass() { return m_Class; }
    static Class *m_Class;
    wstring m_Name;
    bool m_B1;
    common::COLORF m_Colorf;

// CPP file

Class * ComplexItemObject::m_Class;

void ComplexItemObject::RegisterClass_()
    m_Class = new Class(L"ComplexItemObject", ItemObject::GetClass(), &CreateFunc, &CloneFunc);
    m_Class->SetLabel(L"Complex Item Object");

    StlStringProperty *prop1 = new StlStringProperty();
    prop1->Init(L"Name", 0);

    BoolProperty *prop2 = new BoolProperty();
    prop2->Init(L"B1", 1);

    FloatVectorProperty *prop3 = new FloatVectorProperty(3, VectorProperty::SEMANTICS_COLOR);
    prop3->Init(L"Colorf", 2);


Similar code can be automatically generated by my console tool called ReflectionAuto from a .reflect file. The file format is a description language based on my Tokenizer. ReflectionAuto takes in as input and outputs a separate C++ file that adds this boring reflection initialization code to the described classes. The description of the class shown above looks like:

class ComplexItemObject {
    extends ItemObject;
    label "Complex Item Object";
    property string Name { access m_Name; };
    property bool B1 { access m_B1; };
    property int4(color) Colori { access m_Colori; };

That covers the basics (not everything I actually have) when it comes to building description of the classes and properties from my code to make the reflection system aware of them. In the next part I'll show how do I access real objects from my reflection system, including reading and writing properties, as well as creating and manipulation whole objects.

Comments | #c++ #RegEngine #engine Share

# Reflection in RegEngine - Part 1

Jul 2010

Do you remember my old entry about RegEngine? I didn't drop this project. I slowly code it and recently I've finished a reflection system, which I want to show you now.

Generally speaking, reflection is the ability of a code to be aware of itself - especially about its classes and fields. Many high level programming languages and especially sripting languages already have extensive built-in reflection system. In C++ it's not the case because source code is compiled to machine code and all information about classes and fields is lost (except simple RTTI).

Why do we need reflection anyway? When coding a game engine, we deal with many different kinds of objects (like texture, mesh, monster or terrain) and each class have its own set of properties of different types (like int, float, bool, string, vector or color). But we, as game developers, are not willing to code dialog windows for editing these properties or code serialization to/from file for each of these classes. So the idea is to make the code aware of existance of different classes, different property types and on top of that enable automatic exposing all objects to the editor (via so called Property Grid control), as well as serialization to/from a file - all in consistent manner, coded only once.

I've seen many reflection systems and designing my own was a hard process because I had to make some difficult decisions. The way I did it is a matter of some compromise - my solution is not the most general, efficient, powerful and "ultimate" one possible. My reflection system can be seen as consisting of three layers:

1. Bottom layer is the collection of objects describing classes - their names, inheritance and the list of properties, where each property has an identifier, name, type and optionally additional attributes dependand on this type.

2. On top of that there is a code that keeps track of all reflection-compatible objects that currently exist in the system, allows creating, destroying and manipulating them, as we all reading and writing values of class properties in a particular object.

3. Finally, much real functionality can be accomplished using these two previous layers. One of them is serialization - loading and saving single or all objects to/from a file in some file format, either text or binary. Another important thing is exposing all these functions (manipulating objects and their properties) for the user via the editor. There are more possibiblities I could use in the future, like:

When looking for inspiration and exploring possible solutions about how a reflection system can look like, it's worth looking at how it's made in:

Now I want to show some code, at least parts of header files. It all starts in my system from a single global object of type Reflection, which owns the collection of objects describing all classes and enums registered in the system. This collection is built at program startup and the g_Reflection objects allows finding them by name in runtime.

Read full entry > | Comments | #engine #RegEngine #c++ Share

# RegEngine - Design

Feb 2010

I'm now starting coding new game engine. It's called RegEngine. Here is a general design. It's coded in C++ for Windows. This time it will be general game engine, not only renderer. Also, this time I'm going to create an editor (I've never done this before).

I will use wxWidgets 2.9 as GUI library for the editor. It's not an obvious choice though. For example, C++/CLI (which I use at work) is also nice technology as it allows to freely mix native and managed code so one can create GUI with Windows Forms while coding the rest in native C++. But personally I prefer something that is fully native. Qt is also good, looks more mature, stable and, well, "serious" than wxWidgets and it's also free for some time. But wxWidgets is more lightweight than Qt (to a certain degree, as GUI library can be). It also looks like wxWidgets is the only GUI library that has both docking and property grid control built in. (I'm talking about version 2.9 here, because stable 2.8 version of wx doesn't have the property grid yet.)

I want to separate engine from renderer. But I'm not going to make an abstraction to be able to transparently switch between DirectX and OpenGL as it makes no sense for me. I just want to have the ability to use my engine, with all its functionality like scenes, actors, scripts, AI, sound etc. with new renderer I would code some day, let it be DirectX 11 or software one. To do this, my engine will be component based. An actor standing in the scene will just have its name and/or some ID, position, bounding volume and a set of components. If it's visible, its rendering component will be an object from the renderer.

There is also a great idea I want to incorporate into my engine that I know from Krzysiek K. (greetings!). It goes like this: The game, which will be a document for the editor (that's what you can create as New, Open, Save, Save As etc.) is a single, big tree of objects of different type. This tree includes both resources (like textures, meshes, sounds) and scenes with hierarchies of actors inside them, as well as any other entities (like dialogs in an RPG game). Object can have sub-objects and can also have a set of properties of different types (like bool, int, float, string, vector, matrix, color). Framework for these properties (I'll call it "reflection") will automatically serialize them to/from file, show them in property grid in the editor and hopefully make them visible to scripts. This whole idea gives consistent framework to store, serialize and edit all game data.

As creating new dialog boxes is not my favourite activity (no matter if it's coding or clicking :) I've been thinking for a long time about the "ultimate" set of general controls necessary to make a game editor. I currently think that it's sufficient to have:

Some not so necessary and more difficult to code controls are:

RegEngine will consist of modules compiled as static libraries:

First screenshot:

Comments | #engine #RegEngine Share

Pages: 1

[Stat] [STAT NO AD] [Download] [Dropbox] [pub] [Mirror]
Copyright © 2004-2017