Related
I started programming in C++ after a 1-year break, and I am having difficulties here and there (not that I really knew it before the break).
My current problem is that I don't know how to use pointers properly.
I have the following std::vector:
std::vector<std::shared_ptr<IHittable>> world;
Where IHittable is the interface of Hittable objects.
Now, in this std::vector, multiple derivations of IHittable are pushed, like Sphere, Triangle, etc.
Each of these derived classes has a function intersects() like this:
Intersection Sphere::intersects(const Ray & ray)
{
auto x = ...
...
return {x, this};
}
Intersection looks like this:
class Intersection
{
public:
Intersection(double t, IHittable * object);
[[nodiscard]] double t() const;
[[nodiscard]] IHittable * object() const;
private:
double t_;
IHittable * object_ = nullptr;
};
I really don't know how to write this code correctly.
I need to return a this pointer from the member function intersects() of an object which is itself allocated dynamically and is stored in a std::shared_ptr.
Is there a way to handle this?
Another example:
std::vector<std::shared_ptr<IHittable>> world;
world.push_back(std::make_shared<Sphere>());
auto s = Intersection(4.0, world[0]);
Should work.
PS: I could just create multiple std::vectors without std::shared_ptr:
std::vector<Sphere> spheres;
std::vector<Triangles> spheres;
...
But IMHO, it would be nice to iterate over every object at once.
PS2: I am now using shared_from_this() and most of my code works, thanks.
I think this sounds like a good fit for std::enable_shared_from_this as Remy pointed out in the comments.
I whipped up a simplified example which hopefully makes it clear how it can be used to achieve what you're after.
class Intersection;
class IHittable : public std::enable_shared_from_this<IHittable> {
public:
virtual Intersection intersects( ) = 0;
virtual void print( ) const = 0;
virtual ~IHittable( ) = default;
};
class Intersection {
public:
Intersection( std::shared_ptr<IHittable> object )
: object_{ std::move( object ) }
{ }
void print_shape( ) const {
object_->print( );
}
private:
std::shared_ptr<IHittable> object_;
};
class Square : public IHittable {
public:
Intersection intersects( ) override {
return Intersection{ shared_from_this( ) };
}
void print( ) const override {
std::cout << "Square\n";
}
};
int main( ) {
std::vector<std::shared_ptr<IHittable>> objects{
std::make_shared<Square>( ) };
const auto intersect{ objects.front( )->intersects( ) };
intersect.print_shape( );
}
I am learning C++ and my first language in JavaScript. A common pattern to prevent bugs when passing lots of parameters to a function is to pass an object instead. The benefit of it that order doesn't matter and values are always read as intended.
Example:
function checkStuff({param1, param3, param2}) {}
checkStuff({param2, param3, param1})
I find myself constantly mixing order of parameters when passing them to class constructors. Of course, compiler and IDE will scream when types are not matching - the problem starts when my constructor definition looks like this:
Sprite(const std::string &textureFile, int animationSpeed, int frameWidth,
int frameHeight, int width, int height, int scale)
Is there a pattern or another option I can pass to cmake on top of this add_compile_options(-Wall -Wextra -Wpedantic) to prevent mixing these up?
More structure is one way to tackle the problem and one friendly with the language. You could combine things like animation speed, frame width, frame height, etc, into a single structure. Maybe ideally the language would be less awkward about this but I do find it useful in, general, to not be tempted to have like 12+ parameters we want to pass into a single function.
Also in my opinion, struct is fine... or class with all public fields (just stylistic in C++) when all you are using the object for is transmitting multiple parameter fields. Sometimes I encounter an allergy to this in C++ (like people wanting to turn private implementation tree nodes into fancy classes with separate public/private members, when they could just be a basic C-style struct) and I don't think there should be if you're just transmitting data in C++.
You know, public vs. private. The whole point of distinguishing "public" is to protect a good chunk of your code from unpredictable use cases, to maintain invariants. You defend your "kingdom". You don't have to turn everything into a "kingdom" (don't need to arm peasants in plate mail armor). Just use C-like structs to help implement "private' implementation details if you need to do so. Use the strong "shield/pavise" of the C++ knight for the most public, widely-accessible things you design. Just like with your own private parts. I mean I don't want to stand in a train with my crotch exposed, but I need to take a shower every now and then which will require me to be naked.
I generally use strong-types-for-strong-interfaces approach to prevent wrong ordering and also state the intention more clearly. It could be found a bit verbose but it makes the code more readable and less error-prone when used appropriately. You can read the article for further and detailed explanation.
I am just sharing a simple demonstration how to represent the order and meaning of the constructor parameters explicitly for the Sprite class.
#include <string>
template <typename T, typename param>
class strong_type
{
public:
explicit strong_type ( T const& value ) : m_value ( value ) {}
explicit strong_type ( T&& value = T{} ) : m_value ( std::move ( value ) ) {}
T& get()
{
return m_value;
}
T const& get() const
{
return m_value;
}
private:
T m_value;
};
using animation_speed = strong_type<int , struct AnimationSpeedTag>;
using frame_width = strong_type<int , struct FrameWidthTag>;
using frame_height = strong_type<int , struct FrameHeightTag>;
using width = strong_type<int , struct WidthTag>;
using height = strong_type<int , struct HeightTag>;
using scale = strong_type<int , struct ScaleTag>;
class Sprite
{
public:
Sprite( const std::string &texture_file , animation_speed s , frame_width fw ,
frame_height fh , width w , height h , scale sc )
: m_texture_file { texture_file }
, m_animation_speed { s.get() }
, m_frame_width { fw.get() }
, m_frame_height { fh.get() }
, m_width { w.get() }
, m_height { h.get() }
, m_scale { sc.get() }
{ }
private:
// There is no harm to hold the values as primitive types
// Just take it as `strong type`
std::string m_texture_file;
int m_animation_speed {};
int m_frame_width {};
int m_frame_height {};
int m_width {};
int m_height {};
int m_scale {};
};
int main() {
// instead of
// Sprite my_sprite { "sprites/char.dds" , 12 , 640 , 480 , 320 , 240 , 1 };
Sprite my_sprite { "sprites/char.dds" , animation_speed { 12 } ,
frame_width { 640 } , frame_height { 480 } ,
width { 320 } , height { 240 } , scale { 1 } };
}
run online
Another way is passing a struct which holds the required parameters, but I don't suggest that way. Because actually it is not solving the problem, just moving it one step further. The parameters in struct still might have been left unassigned.
A demonstration :
#include <string>
struct sprite_parameters
{
std::string texture_file;
int animation_speed {};
int frame_width {};
int frame_height {};
int width {};
int height {};
int scale {};
};
class Sprite
{
public:
Sprite( const sprite_parameters& params )
: m_texture_file { params.texture_file }
, m_animation_speed { params.animation_speed }
, m_frame_width { params.frame_width }
, m_frame_height { params.frame_height }
, m_width { params.width }
, m_height { params.height }
, m_scale { params.scale }
{ }
private:
std::string m_texture_file;
int m_animation_speed {};
int m_frame_width {};
int m_frame_height {};
int m_width {};
int m_height {};
int m_scale {};
};
int main() {
// instead of
// Sprite my_sprite { "sprites/char.dds" , 12 , 640 , 480 , 320 , 240 , 1 };
sprite_parameters params;
params.texture_file = "sprites/char.dds";
params.animation_speed = 150;
params.frame_width = 320;
params.frame_height = 240;
params.width = 640;
params.height = 480;
// params.scale = 1; OK, I forgot this, what will happen now.
// It is just ugly obscure bug.
Sprite my_sprite { params };
}
run online
I've been experimenting with making a component based system similar to Unity's, but in C++. I'm wondering how the GetComponent() method that Unity implements works. It is a very powerful function. Specifically, I want to know what kind of container it uses to store its components.
The two criteria I need in my clone of this function are as follows. 1. I need any inherited components to be returned as well. For example, if SphereCollider inherits Collider, GetComponent<Collider>() will return the SphereCollider attached to the GameObject, but GetComponent<SphereCollider>() will not return any Collider attached. 2. I need the function to be fast. Preferably, it would use some kind of hash function.
For criteria one, I know that I could use something similar to the following implementation
std::vector<Component*> components
template <typename T>
T* GetComponent()
{
for each (Component* c in components)
if (dynamic_cast<T>(*c))
return (T*)c;
return nullptr;
}
But that doesn't fit the second criteria of being fast. For that, I know I could do something like this.
std::unordered_map<type_index, Component*> components
template <typename T>
T* GetComponent()
{
return (T*)components[typeid(T)];
}
But again, that doesn't fit the first criteria.
If anybody knows of some way to combine those two features, even if it's a little slower than the second example, I would be willing to sacrifice a little bit. Thank you!
Since I'm writing my own game engine and incorporating the same design, I thought I'd share my results.
Overview
I wrote my own RTTI for the classes I cared to use as Components of my GameObject instances. The amount of typing is reduced by #defineing the two macros: CLASS_DECLARATION and CLASS_DEFINITION
CLASS_DECLARATION declares the unique static const std::size_t that will be used to identify the class type (Type), and a virtual function that allows objects to traverse their class hierarchy by calling their parent-class function of the same name (IsClassType).
CLASS_DEFINITION defines those two things. Namely the Type is initialized to a hash of a stringified version of the class name (using TO_STRING(x) #x), so that Type comparisons are just an int compare and not a string compare.
std::hash<std::string> is the hash function used, which guarantees equal inputs yield equal outputs, and the number of collisions is near-zero.
Aside from the low risk of hash collisions, this implementation has the added benefit of allowing users to create their own Component classes using those macros without ever having to refer to|extend some master include file of enum classs, or use typeid (which only provides the run-time type, not the parent-classes).
AddComponent
This custom RTTI simplifies the call syntax for Add|Get|RemoveComponent to just specifying the template type, just like Unity.
The AddComponent method perfect-forwards a universal reference variadic parameter pack to the user's constructor. So, for example, a user-defined Component-derived class CollisionModel could have the constructor:
CollisionModel( GameObject * owner, const Vec3 & size, const Vec3 & offset, bool active );
then later on the user simply calls:
myGameObject.AddComponent<CollisionModel>(this, Vec3( 10, 10, 10 ), Vec3( 0, 0, 0 ), true );
Note the explicit construction of the Vec3s because perfect-forwarding can fail to link if using deduced initializer-list syntax like { 10, 10, 10 } regardless of Vec3's constructor declarations.
This custom RTTI also resolves 3 issues with the std::unordered_map<std::typeindex,...> solution:
Even with the hierarchy traversal using std::tr2::direct_bases the end result is still duplicates of the same pointer in the map.
A user can't add multiple Components of equivalent type, unless a map is used that allows/solves collisions without overwriting, which further slows down the code.
No uncertain and slow dynamic_cast is needed, just a straight static_cast.
GetComponent
GetComponent just uses the static const std::size_t Type of the template type as an argument to the virtual bool IsClassType method and iterates over std::vector< std::unique_ptr< Component > > looking for the first match.
I've also implemented a GetComponents method that can get all components of the requested type, again including getting from the parent-class.
Note that the static member Type can be accessed both with and without an instance of the class.
Also note that Type is public, declared for each Component-derived class, ...and capitalized to emphasize its flexible use, despite being a POD member.
RemoveComponent
Lastly, RemoveComponent uses C++14's init-capture to pass that same static const std::size_t Type of the template type into a lambda so it can basically do the same vector traversal, this time getting an iterator to the first matching element.
There are a few comments in the code about ideas for a more flexible implementation, not to mention const versions of all these could also easily be implemented.
The Code
Classes.h
#ifndef TEST_CLASSES_H
#define TEST_CLASSES_H
#include <string>
#include <functional>
#include <vector>
#include <memory>
#include <algorithm>
#define TO_STRING( x ) #x
//****************
// CLASS_DECLARATION
//
// This macro must be included in the declaration of any subclass of Component.
// It declares variables used in type checking.
//****************
#define CLASS_DECLARATION( classname ) \
public: \
static const std::size_t Type; \
virtual bool IsClassType( const std::size_t classType ) const override; \
//****************
// CLASS_DEFINITION
//
// This macro must be included in the class definition to properly initialize
// variables used in type checking. Take special care to ensure that the
// proper parentclass is indicated or the run-time type information will be
// incorrect. Only works on single-inheritance RTTI.
//****************
#define CLASS_DEFINITION( parentclass, childclass ) \
const std::size_t childclass::Type = std::hash< std::string >()( TO_STRING( childclass ) ); \
bool childclass::IsClassType( const std::size_t classType ) const { \
if ( classType == childclass::Type ) \
return true; \
return parentclass::IsClassType( classType ); \
} \
namespace rtti {
//***************
// Component
// base class
//***************
class Component {
public:
static const std::size_t Type;
virtual bool IsClassType( const std::size_t classType ) const {
return classType == Type;
}
public:
virtual ~Component() = default;
Component( std::string && initialValue )
: value( initialValue ) {
}
public:
std::string value = "uninitialized";
};
//***************
// Collider
//***************
class Collider : public Component {
CLASS_DECLARATION( Collider )
public:
Collider( std::string && initialValue )
: Component( std::move( initialValue ) ) {
}
};
//***************
// BoxCollider
//***************
class BoxCollider : public Collider {
CLASS_DECLARATION( BoxCollider )
public:
BoxCollider( std::string && initialValue )
: Collider( std::move( initialValue ) ) {
}
};
//***************
// RenderImage
//***************
class RenderImage : public Component {
CLASS_DECLARATION( RenderImage )
public:
RenderImage( std::string && initialValue )
: Component( std::move( initialValue ) ) {
}
};
//***************
// GameObject
//***************
class GameObject {
public:
std::vector< std::unique_ptr< Component > > components;
public:
template< class ComponentType, typename... Args >
void AddComponent( Args&&... params );
template< class ComponentType >
ComponentType & GetComponent();
template< class ComponentType >
bool RemoveComponent();
template< class ComponentType >
std::vector< ComponentType * > GetComponents();
template< class ComponentType >
int RemoveComponents();
};
//***************
// GameObject::AddComponent
// perfect-forwards all params to the ComponentType constructor with the matching parameter list
// DEBUG: be sure to compare the arguments of this fn to the desired constructor to avoid perfect-forwarding failure cases
// EG: deduced initializer lists, decl-only static const int members, 0|NULL instead of nullptr, overloaded fn names, and bitfields
//***************
template< class ComponentType, typename... Args >
void GameObject::AddComponent( Args&&... params ) {
components.emplace_back( std::make_unique< ComponentType >( std::forward< Args >( params )... ) );
}
//***************
// GameObject::GetComponent
// returns the first component that matches the template type
// or that is derived from the template type
// EG: if the template type is Component, and components[0] type is BoxCollider
// then components[0] will be returned because it derives from Component
//***************
template< class ComponentType >
ComponentType & GameObject::GetComponent() {
for ( auto && component : components ) {
if ( component->IsClassType( ComponentType::Type ) )
return *static_cast< ComponentType * >( component.get() );
}
return *std::unique_ptr< ComponentType >( nullptr );
}
//***************
// GameObject::RemoveComponent
// returns true on successful removal
// returns false if components is empty, or no such component exists
//***************
template< class ComponentType >
bool GameObject::RemoveComponent() {
if ( components.empty() )
return false;
auto & index = std::find_if( components.begin(),
components.end(),
[ classType = ComponentType::Type ]( auto & component ) {
return component->IsClassType( classType );
} );
bool success = index != components.end();
if ( success )
components.erase( index );
return success;
}
//***************
// GameObject::GetComponents
// returns a vector of pointers to the the requested component template type following the same match criteria as GetComponent
// NOTE: the compiler has the option to copy-elide or move-construct componentsOfType into the return value here
// TODO: pass in the number of elements desired (eg: up to 7, or only the first 2) which would allow a std::array return value,
// except there'd need to be a separate fn for getting them *all* if the user doesn't know how many such Components the GameObject has
// TODO: define a GetComponentAt<ComponentType, int>() that can directly grab up to the the n-th component of the requested type
//***************
template< class ComponentType >
std::vector< ComponentType * > GameObject::GetComponents() {
std::vector< ComponentType * > componentsOfType;
for ( auto && component : components ) {
if ( component->IsClassType( ComponentType::Type ) )
componentsOfType.emplace_back( static_cast< ComponentType * >( component.get() ) );
}
return componentsOfType;
}
//***************
// GameObject::RemoveComponents
// returns the number of successful removals, or 0 if none are removed
//***************
template< class ComponentType >
int GameObject::RemoveComponents() {
if ( components.empty() )
return 0;
int numRemoved = 0;
bool success = false;
do {
auto & index = std::find_if( components.begin(),
components.end(),
[ classType = ComponentType::Type ]( auto & component ) {
return component->IsClassType( classType );
} );
success = index != components.end();
if ( success ) {
components.erase( index );
++numRemoved;
}
} while ( success );
return numRemoved;
}
} /* rtti */
#endif /* TEST_CLASSES_H */
Classes.cpp
#include "Classes.h"
using namespace rtti;
const std::size_t Component::Type = std::hash<std::string>()(TO_STRING(Component));
CLASS_DEFINITION(Component, Collider)
CLASS_DEFINITION(Collider, BoxCollider)
CLASS_DEFINITION(Component, RenderImage)
main.cpp
#include <iostream>
#include "Classes.h"
#define MORE_CODE 0
int main( int argc, const char * argv ) {
using namespace rtti;
GameObject test;
// AddComponent test
test.AddComponent< Component >( "Component" );
test.AddComponent< Collider >( "Collider" );
test.AddComponent< BoxCollider >( "BoxCollider_A" );
test.AddComponent< BoxCollider >( "BoxCollider_B" );
#if MORE_CODE
test.AddComponent< RenderImage >( "RenderImage" );
#endif
std::cout << "Added:\n------\nComponent\t(1)\nCollider\t(1)\nBoxCollider\t(2)\nRenderImage\t(0)\n\n";
// GetComponent test
auto & componentRef = test.GetComponent< Component >();
auto & colliderRef = test.GetComponent< Collider >();
auto & boxColliderRef1 = test.GetComponent< BoxCollider >();
auto & boxColliderRef2 = test.GetComponent< BoxCollider >(); // boxColliderB == boxColliderA here because GetComponent only gets the first match in the class hierarchy
auto & renderImageRef = test.GetComponent< RenderImage >(); // gets &nullptr with MORE_CODE 0
std::cout << "Values:\n-------\ncomponentRef:\t\t" << componentRef.value
<< "\ncolliderRef:\t\t" << colliderRef.value
<< "\nboxColliderRef1:\t" << boxColliderRef1.value
<< "\nboxColliderRef2:\t" << boxColliderRef2.value
<< "\nrenderImageRef:\t\t" << ( &renderImageRef != nullptr ? renderImageRef.value : "nullptr" );
// GetComponents test
auto allColliders = test.GetComponents< Collider >();
std::cout << "\n\nThere are (" << allColliders.size() << ") collider components attached to the test GameObject:\n";
for ( auto && c : allColliders ) {
std::cout << c->value << '\n';
}
// RemoveComponent test
test.RemoveComponent< BoxCollider >(); // removes boxColliderA
auto & boxColliderRef3 = test.GetComponent< BoxCollider >(); // now this is the second BoxCollider "BoxCollider_B"
std::cout << "\n\nFirst BoxCollider instance removed\nboxColliderRef3:\t" << boxColliderRef3.value << '\n';
#if MORE_CODE
// RemoveComponent return test
int removed = 0;
while ( test.RemoveComponent< Component >() ) {
++removed;
}
#else
// RemoveComponents test
int removed = test.RemoveComponents< Component >();
#endif
std::cout << "\nSuccessfully removed (" << removed << ") components from the test GameObject\n";
system( "PAUSE" );
return 0;
}
Output
Added:
------
Component (1)
Collider (1)
BoxCollider (2)
RenderImage (0)
Values:
-------
componentRef: Component
colliderRef: Collider
boxColliderRef1: BoxCollider_A
boxColliderRef2: BoxCollider_A
renderImageRef: nullptr
There are (3) collider components attached to the test GameObject:
Collider
BoxCollider_A
BoxCollider_B
First BoxCollider instance removed
boxColliderRef3: BoxCollider_B
Successfully removed (3) components from the test GameObject
Side-note: granted Unity uses Destroy(object) and not RemoveComponent, but my version suits my needs for now.
Apologies if this is not what you are looking for, but I had an idea to use the unordered map with a type index and, with the help of some metaprogramming and TR2, place multiple pointers to the component into the map, including its direct base classes as additional keys. So getComponent<SphereCollider>() and getComponent<Collider>() along with a down-cast will have the same pointee.
#include <tr2/type_traits>
#include <tuple>
#include <typeindex>
#include <unordered_map>
#include <iostream>
class Component {
public:
virtual ~Component() {}
};
class GameObject {
public:
template <typename T>
void addComponent(T *component);
template <typename T>
T *getComponent();
std::unordered_map<std::typeindex, Component *> components;
};
template <typename>
struct direct_bases_as_tuple {};
template <typename... Types>
struct direct_bases_as_tuple<std::tr2::__reflection_typelist<Types...>> {
typedef std::tuple<Types...> type;
};
template <std::size_t N, typename ComponentBases, typename ComponentType>
struct AddComponent {
GameObject *owner;
explicit AddComponent(GameObject *owner) : owner(owner) {}
void operator()(ComponentType *component) {
AddComponent<N-1, ComponentBases, ComponentType>{owner}(component);
using BaseType = std::tuple_element<N-1, ComponentBases>::type;
owner->components[typeid(BaseType)] = component;
}
};
template <typename ComponentBases, typename ComponentType>
struct AddComponent<0u, ComponentBases, ComponentType> {
GameObject *owner;
explicit AddComponent(GameObject *owner) : owner(owner) {}
void operator()(ComponentType *component) {
return;
}
};
template <typename T>
void GameObject::addComponent(T *component) {
using ComponentBases = direct_bases_as_tuple<std::tr2::direct_bases<ComponentType>::type>::type;
constexpr classCount = std::tuple_size<ComponentBases>::value;
AddComponent<classCount, ComponentBases, T>{this}(component);
components[typeid(T)] = component;
}
template <typename T>
T * GameObject::getComponent() {
auto iter = components.find(typeid(T));
if (iter != std::end(components)) {
return dynamic_cast<T *>(iter->second);
}
return nullptr;
}
class Collider : public Component {};
class SphereCollider : public Collider {};
int main() {
GameObject gameObject;
gameObject.addComponent(new SphereCollider);
//get by derived class
SphereCollider *sphereColliderA = gameObject.getComponent<SphereCollider>();
//get by subclass
SphereCollider *sphereColliderB = dynamic_cast<SphereCollider *>(
gameObject.getComponent<Collider>()
);
if (sphereColliderA == sphereColliderB) {
std::cout << "good" << std::endl;
}
}
I created the AddComponent struct to recurse through the component base classes at compile-time and insert the pointer (value) with the corresponding class (key) each iteration. The helper struct direct_bases_as_tuple was inspired by Andy Prowl's answer to change the direct bases into a tuple. I compiled this using GCC 4.9.2 using C++11 features.
I know this post is already answered, but if you look into Game Programming Patterns, in this book he has a design pattern called Service Locator, and at the end, it says Unity uses this pattern together with the Component Pattern. I wish I could answer into more specifics, but this could be another way to approach this.
The Unity engine is linked with a forked mono runtime, on which unity scripts are executed.
In UnityEngine.Component
public class Component : Object
{
.
.
[TypeInferenceRule(TypeInferenceRules.TypeReferencedByFirstArgument)]
public Component GetComponent(Type type)
{
return this.gameObject.GetComponent(type);
}
[GeneratedByOldBindingsGenerator]
[MethodImpl(MethodImplOptions.InternalCall)]
internal extern void GetComponentFastPath(Type type, IntPtr oneFurtherThanResultValue);
[SecuritySafeCritical]
public unsafe T GetComponent<T>()
{
CastHelper<T> castHelper = default(CastHelper<T>);
this.GetComponentFastPath(typeof(T), new IntPtr((void*)(&castHelper.onePointerFurtherThanT)));
return castHelper.t;
}
.
.
}
The C# code performs native calls, called Icalls to C++ methods that have been bound to the C# methods using the C# runtime library API. Bodyless (unimplemented) methods need either an extern, abstract or partial specifier as a rule so all internal calls are marked as extern. When the runtime sees a method with the [MethodImpl(MethodImplOptions.InternalCall)] attribute it knows it needs to make an Icall, so it looks up the function it has been bound to and jumps to that address.
An Icall does not need to be static in C# and automatically passes the this MonoObject of the component to the C++ handler function. If they are static then the this object is usually deliberately passed as a parameter using a C# shim method and making the shim method the static Icall. Using Icalls, types are not marshalled unless they are blittable types, meaning all other types are passed as MonoObject, MonoString etc.
Typically the C++ methods are functions or static methods but I think they can be non static methods as well, so long as they aren't virtual, because the address cannot be fixed by the runtime.
in UnityEngine.GameObject
public sealed class GameObject : Object
{
.
.
public GameObject(string name)
{
GameObject.Internal_CreateGameObject(this, name);
}
public GameObject()
{
GameObject.Internal_CreateGameObject(this, (string) null);
}
[WrapperlessIcall]
[TypeInferenceRule(TypeInferenceRules.TypeReferencedByFirstArgument)]
[MethodImpl(MethodImplOptions.InternalCall)]
public extern Component GetComponent(System.Type type);
[WrapperlessIcall]
[MethodImpl(MethodImplOptions.InternalCall)]
private static extern void Internal_CreateGameObject([Writable] GameObject mono, string name);
.
.
}
The C# constructor for the GameObject contains a call to a native method. The body of the constructor is run after initialisation of the C# object such that there is already a this pointer. Internal_CreateGameObject is the static shim function that is actually called.
Someone's example implementation of their own C++ Internal_CreateGameObject using mono:
bool GameObjectBinding::init()
{
MonoClass *gameObjectClass = Mono::get().getClass("GameObject");
gameObject_NativeID_Field = mono_class_get_field_from_name(gameObjectClass, "nativeID");
MonoClass *transformClass = Mono::get().getClass("Transform");
transform_NativeID_Field = mono_class_get_field_from_name(transformClass, "nativeID");
mono_add_internal_call("GameEngine_CS.GameObject::internal_createGameObject", GameObjectBinding::createGameObject);
mono_add_internal_call("GameEngine_CS.GameObject::internal_deleteGameObject", GameObjectBinding::deleteGameObject);
mono_add_internal_call("GameEngine_CS.GameObject::internal_getGameObject", GameObjectBinding::getGameObject);
mono_add_internal_call("GameEngine_CS.GameObject::internal_getTransform", GameObjectBinding::getTransform);
return true;
}
void GameObjectBinding::createGameObject(MonoObject * monoGameObject)
{
Object *newObject = LevelManager::get().getCurrentLevel()->createObject(0);
mono_field_set_value(monoGameObject, gameObject_NativeID_Field, (void*)newObject->getID());
}
mono_add_internal_call has been used to bind this method to GameObjectBinding::createGameObject, to which the this pointer is passed as a MonoObject pointer. A native object is then created to represent the GameObject, and mono_field_set_value is then used to set the NativeID field of the C# object to the ID of the new native object. This way the native object can be accessed from the MonoObject which is the internal implementation of the C# object. The GameObject is represented by 2 objects essentially.
public sealed class GameObject : Object
{
.
.
private UInt32 nativeID;
public UInt32 id { get { return nativeID; } }
.
.
}
This field is bound in the runtime using
mono_set_dirs( "/Library/Frameworks/Mono.framework/Home/lib", "/Library/Frameworks/Mono.framework/Home/etc" );
mono_config_parse( nullptr );
const char* managedbinarypath = "C:/Test.dll";
MonoDomain* domain = mono_jit_init(managedbinarypath)
MonoAssembly* assembly = mono_domain_assembly_open (domain, managedbinarypath);
MonoImage* image = mono_assembly_get_image (assembly);
MonoClass* gameobjectclass = mono_class_from_name(image, "ManagedLibrary", "GameObject");
gameObject_NativeID_Field = mono_class_get_field_from_name( gameobjectclass, "nativeID" );
GetComponent<T>() passes typeof(T) to GetComponentFastPath (the native call) which passes the this pointer of the component as well. The native implementation of GetComponentFastPath will receive this as a MonoObject* and a MonoReflectionType* for the type. The bound C++ method will then call mono_reflection_type_get_type() on the MonoReflectionType* to get the MonoType* (here are the primitive types: https://github.com/samneirinck/cemono/blob/master/src/native/inc/mono/mono/metadata/blob.h), or for object types you can get the MonoClass* from MonoType* using mono_class_from_mono_type(). It will then get the game object that is attached to the Component and search the components that the object has in some internal data structure.
Someone's example implementation of their own C++ GetComponent using mono:
id ModuleScriptImporter::RegisterAPI()
{
//GAMEOBJECT
mono_add_internal_call("TheEngine.TheGameObject::CreateNewGameObject", (const void*)CreateGameObject);
mono_add_internal_call("TheEngine.TheGameObject::AddComponent", (const void*)AddComponent);
mono_add_internal_call("TheEngine.TheGameObject::GetComponent", (const void*)GetComponent);
}
MonoObject* ModuleScriptImporter::GetComponent(MonoObject * object, MonoReflectionType * type)
{
return current_script->GetComponent(object, type);
}
MonoObject* CSharpScript::GetComponent(MonoObject* object, MonoReflectionType* type)
{
if (!CheckMonoObject(object))
{
return nullptr;
}
if (currentGameObject == nullptr)
{
return nullptr;
}
MonoType* t = mono_reflection_type_get_type(type);
std::string name = mono_type_get_name(t);
const char* comp_name = "";
if (name == "CulverinEditor.Transform")
{
comp_name = "Transform";
}
MonoClass* classT = mono_class_from_name(App->importer->iScript->GetCulverinImage(), "CulverinEditor", comp_name);
if (classT)
{
MonoObject* new_object = mono_object_new(CSdomain, classT);
if (new_object)
{
return new_object;
}
}
return nullptr;
}
C# methods can be invoked from C++:
MonoMethodDesc* desc = mono_method_desc_new (const char *name, gboolean include_namespace);
MonoClass* class = mono_class_from_name (MonoImage *image, const char* name_space, const char *name);
MonoMethod* method = mono_method_desc_search_in_class (MonoMethodDesc *desc, MonoClass *klass);
MonoMethod* method = mono_method_desc_search_in_image (MonoMethodDesc *desc, MonoImage *image);
MonoObject* obj = mono_runtime_invoke (MonoMethod *method, void *obj, void **params,
MonoObject **exc);
See: https://gamedev.stackexchange.com/questions/115573/how-are-methods-like-awake-start-and-update-called-in-unity/183091#183091
There is a good introduction article to ECS: https://austinmorlan.com/posts/entity_component_system/ made differently than TOM__'s post.
I've been experimenting with making a component based system similar to Unity's, but in C++. I'm wondering how the GetComponent() method that Unity implements works. It is a very powerful function. Specifically, I want to know what kind of container it uses to store its components.
The two criteria I need in my clone of this function are as follows. 1. I need any inherited components to be returned as well. For example, if SphereCollider inherits Collider, GetComponent<Collider>() will return the SphereCollider attached to the GameObject, but GetComponent<SphereCollider>() will not return any Collider attached. 2. I need the function to be fast. Preferably, it would use some kind of hash function.
For criteria one, I know that I could use something similar to the following implementation
std::vector<Component*> components
template <typename T>
T* GetComponent()
{
for each (Component* c in components)
if (dynamic_cast<T>(*c))
return (T*)c;
return nullptr;
}
But that doesn't fit the second criteria of being fast. For that, I know I could do something like this.
std::unordered_map<type_index, Component*> components
template <typename T>
T* GetComponent()
{
return (T*)components[typeid(T)];
}
But again, that doesn't fit the first criteria.
If anybody knows of some way to combine those two features, even if it's a little slower than the second example, I would be willing to sacrifice a little bit. Thank you!
Since I'm writing my own game engine and incorporating the same design, I thought I'd share my results.
Overview
I wrote my own RTTI for the classes I cared to use as Components of my GameObject instances. The amount of typing is reduced by #defineing the two macros: CLASS_DECLARATION and CLASS_DEFINITION
CLASS_DECLARATION declares the unique static const std::size_t that will be used to identify the class type (Type), and a virtual function that allows objects to traverse their class hierarchy by calling their parent-class function of the same name (IsClassType).
CLASS_DEFINITION defines those two things. Namely the Type is initialized to a hash of a stringified version of the class name (using TO_STRING(x) #x), so that Type comparisons are just an int compare and not a string compare.
std::hash<std::string> is the hash function used, which guarantees equal inputs yield equal outputs, and the number of collisions is near-zero.
Aside from the low risk of hash collisions, this implementation has the added benefit of allowing users to create their own Component classes using those macros without ever having to refer to|extend some master include file of enum classs, or use typeid (which only provides the run-time type, not the parent-classes).
AddComponent
This custom RTTI simplifies the call syntax for Add|Get|RemoveComponent to just specifying the template type, just like Unity.
The AddComponent method perfect-forwards a universal reference variadic parameter pack to the user's constructor. So, for example, a user-defined Component-derived class CollisionModel could have the constructor:
CollisionModel( GameObject * owner, const Vec3 & size, const Vec3 & offset, bool active );
then later on the user simply calls:
myGameObject.AddComponent<CollisionModel>(this, Vec3( 10, 10, 10 ), Vec3( 0, 0, 0 ), true );
Note the explicit construction of the Vec3s because perfect-forwarding can fail to link if using deduced initializer-list syntax like { 10, 10, 10 } regardless of Vec3's constructor declarations.
This custom RTTI also resolves 3 issues with the std::unordered_map<std::typeindex,...> solution:
Even with the hierarchy traversal using std::tr2::direct_bases the end result is still duplicates of the same pointer in the map.
A user can't add multiple Components of equivalent type, unless a map is used that allows/solves collisions without overwriting, which further slows down the code.
No uncertain and slow dynamic_cast is needed, just a straight static_cast.
GetComponent
GetComponent just uses the static const std::size_t Type of the template type as an argument to the virtual bool IsClassType method and iterates over std::vector< std::unique_ptr< Component > > looking for the first match.
I've also implemented a GetComponents method that can get all components of the requested type, again including getting from the parent-class.
Note that the static member Type can be accessed both with and without an instance of the class.
Also note that Type is public, declared for each Component-derived class, ...and capitalized to emphasize its flexible use, despite being a POD member.
RemoveComponent
Lastly, RemoveComponent uses C++14's init-capture to pass that same static const std::size_t Type of the template type into a lambda so it can basically do the same vector traversal, this time getting an iterator to the first matching element.
There are a few comments in the code about ideas for a more flexible implementation, not to mention const versions of all these could also easily be implemented.
The Code
Classes.h
#ifndef TEST_CLASSES_H
#define TEST_CLASSES_H
#include <string>
#include <functional>
#include <vector>
#include <memory>
#include <algorithm>
#define TO_STRING( x ) #x
//****************
// CLASS_DECLARATION
//
// This macro must be included in the declaration of any subclass of Component.
// It declares variables used in type checking.
//****************
#define CLASS_DECLARATION( classname ) \
public: \
static const std::size_t Type; \
virtual bool IsClassType( const std::size_t classType ) const override; \
//****************
// CLASS_DEFINITION
//
// This macro must be included in the class definition to properly initialize
// variables used in type checking. Take special care to ensure that the
// proper parentclass is indicated or the run-time type information will be
// incorrect. Only works on single-inheritance RTTI.
//****************
#define CLASS_DEFINITION( parentclass, childclass ) \
const std::size_t childclass::Type = std::hash< std::string >()( TO_STRING( childclass ) ); \
bool childclass::IsClassType( const std::size_t classType ) const { \
if ( classType == childclass::Type ) \
return true; \
return parentclass::IsClassType( classType ); \
} \
namespace rtti {
//***************
// Component
// base class
//***************
class Component {
public:
static const std::size_t Type;
virtual bool IsClassType( const std::size_t classType ) const {
return classType == Type;
}
public:
virtual ~Component() = default;
Component( std::string && initialValue )
: value( initialValue ) {
}
public:
std::string value = "uninitialized";
};
//***************
// Collider
//***************
class Collider : public Component {
CLASS_DECLARATION( Collider )
public:
Collider( std::string && initialValue )
: Component( std::move( initialValue ) ) {
}
};
//***************
// BoxCollider
//***************
class BoxCollider : public Collider {
CLASS_DECLARATION( BoxCollider )
public:
BoxCollider( std::string && initialValue )
: Collider( std::move( initialValue ) ) {
}
};
//***************
// RenderImage
//***************
class RenderImage : public Component {
CLASS_DECLARATION( RenderImage )
public:
RenderImage( std::string && initialValue )
: Component( std::move( initialValue ) ) {
}
};
//***************
// GameObject
//***************
class GameObject {
public:
std::vector< std::unique_ptr< Component > > components;
public:
template< class ComponentType, typename... Args >
void AddComponent( Args&&... params );
template< class ComponentType >
ComponentType & GetComponent();
template< class ComponentType >
bool RemoveComponent();
template< class ComponentType >
std::vector< ComponentType * > GetComponents();
template< class ComponentType >
int RemoveComponents();
};
//***************
// GameObject::AddComponent
// perfect-forwards all params to the ComponentType constructor with the matching parameter list
// DEBUG: be sure to compare the arguments of this fn to the desired constructor to avoid perfect-forwarding failure cases
// EG: deduced initializer lists, decl-only static const int members, 0|NULL instead of nullptr, overloaded fn names, and bitfields
//***************
template< class ComponentType, typename... Args >
void GameObject::AddComponent( Args&&... params ) {
components.emplace_back( std::make_unique< ComponentType >( std::forward< Args >( params )... ) );
}
//***************
// GameObject::GetComponent
// returns the first component that matches the template type
// or that is derived from the template type
// EG: if the template type is Component, and components[0] type is BoxCollider
// then components[0] will be returned because it derives from Component
//***************
template< class ComponentType >
ComponentType & GameObject::GetComponent() {
for ( auto && component : components ) {
if ( component->IsClassType( ComponentType::Type ) )
return *static_cast< ComponentType * >( component.get() );
}
return *std::unique_ptr< ComponentType >( nullptr );
}
//***************
// GameObject::RemoveComponent
// returns true on successful removal
// returns false if components is empty, or no such component exists
//***************
template< class ComponentType >
bool GameObject::RemoveComponent() {
if ( components.empty() )
return false;
auto & index = std::find_if( components.begin(),
components.end(),
[ classType = ComponentType::Type ]( auto & component ) {
return component->IsClassType( classType );
} );
bool success = index != components.end();
if ( success )
components.erase( index );
return success;
}
//***************
// GameObject::GetComponents
// returns a vector of pointers to the the requested component template type following the same match criteria as GetComponent
// NOTE: the compiler has the option to copy-elide or move-construct componentsOfType into the return value here
// TODO: pass in the number of elements desired (eg: up to 7, or only the first 2) which would allow a std::array return value,
// except there'd need to be a separate fn for getting them *all* if the user doesn't know how many such Components the GameObject has
// TODO: define a GetComponentAt<ComponentType, int>() that can directly grab up to the the n-th component of the requested type
//***************
template< class ComponentType >
std::vector< ComponentType * > GameObject::GetComponents() {
std::vector< ComponentType * > componentsOfType;
for ( auto && component : components ) {
if ( component->IsClassType( ComponentType::Type ) )
componentsOfType.emplace_back( static_cast< ComponentType * >( component.get() ) );
}
return componentsOfType;
}
//***************
// GameObject::RemoveComponents
// returns the number of successful removals, or 0 if none are removed
//***************
template< class ComponentType >
int GameObject::RemoveComponents() {
if ( components.empty() )
return 0;
int numRemoved = 0;
bool success = false;
do {
auto & index = std::find_if( components.begin(),
components.end(),
[ classType = ComponentType::Type ]( auto & component ) {
return component->IsClassType( classType );
} );
success = index != components.end();
if ( success ) {
components.erase( index );
++numRemoved;
}
} while ( success );
return numRemoved;
}
} /* rtti */
#endif /* TEST_CLASSES_H */
Classes.cpp
#include "Classes.h"
using namespace rtti;
const std::size_t Component::Type = std::hash<std::string>()(TO_STRING(Component));
CLASS_DEFINITION(Component, Collider)
CLASS_DEFINITION(Collider, BoxCollider)
CLASS_DEFINITION(Component, RenderImage)
main.cpp
#include <iostream>
#include "Classes.h"
#define MORE_CODE 0
int main( int argc, const char * argv ) {
using namespace rtti;
GameObject test;
// AddComponent test
test.AddComponent< Component >( "Component" );
test.AddComponent< Collider >( "Collider" );
test.AddComponent< BoxCollider >( "BoxCollider_A" );
test.AddComponent< BoxCollider >( "BoxCollider_B" );
#if MORE_CODE
test.AddComponent< RenderImage >( "RenderImage" );
#endif
std::cout << "Added:\n------\nComponent\t(1)\nCollider\t(1)\nBoxCollider\t(2)\nRenderImage\t(0)\n\n";
// GetComponent test
auto & componentRef = test.GetComponent< Component >();
auto & colliderRef = test.GetComponent< Collider >();
auto & boxColliderRef1 = test.GetComponent< BoxCollider >();
auto & boxColliderRef2 = test.GetComponent< BoxCollider >(); // boxColliderB == boxColliderA here because GetComponent only gets the first match in the class hierarchy
auto & renderImageRef = test.GetComponent< RenderImage >(); // gets &nullptr with MORE_CODE 0
std::cout << "Values:\n-------\ncomponentRef:\t\t" << componentRef.value
<< "\ncolliderRef:\t\t" << colliderRef.value
<< "\nboxColliderRef1:\t" << boxColliderRef1.value
<< "\nboxColliderRef2:\t" << boxColliderRef2.value
<< "\nrenderImageRef:\t\t" << ( &renderImageRef != nullptr ? renderImageRef.value : "nullptr" );
// GetComponents test
auto allColliders = test.GetComponents< Collider >();
std::cout << "\n\nThere are (" << allColliders.size() << ") collider components attached to the test GameObject:\n";
for ( auto && c : allColliders ) {
std::cout << c->value << '\n';
}
// RemoveComponent test
test.RemoveComponent< BoxCollider >(); // removes boxColliderA
auto & boxColliderRef3 = test.GetComponent< BoxCollider >(); // now this is the second BoxCollider "BoxCollider_B"
std::cout << "\n\nFirst BoxCollider instance removed\nboxColliderRef3:\t" << boxColliderRef3.value << '\n';
#if MORE_CODE
// RemoveComponent return test
int removed = 0;
while ( test.RemoveComponent< Component >() ) {
++removed;
}
#else
// RemoveComponents test
int removed = test.RemoveComponents< Component >();
#endif
std::cout << "\nSuccessfully removed (" << removed << ") components from the test GameObject\n";
system( "PAUSE" );
return 0;
}
Output
Added:
------
Component (1)
Collider (1)
BoxCollider (2)
RenderImage (0)
Values:
-------
componentRef: Component
colliderRef: Collider
boxColliderRef1: BoxCollider_A
boxColliderRef2: BoxCollider_A
renderImageRef: nullptr
There are (3) collider components attached to the test GameObject:
Collider
BoxCollider_A
BoxCollider_B
First BoxCollider instance removed
boxColliderRef3: BoxCollider_B
Successfully removed (3) components from the test GameObject
Side-note: granted Unity uses Destroy(object) and not RemoveComponent, but my version suits my needs for now.
Apologies if this is not what you are looking for, but I had an idea to use the unordered map with a type index and, with the help of some metaprogramming and TR2, place multiple pointers to the component into the map, including its direct base classes as additional keys. So getComponent<SphereCollider>() and getComponent<Collider>() along with a down-cast will have the same pointee.
#include <tr2/type_traits>
#include <tuple>
#include <typeindex>
#include <unordered_map>
#include <iostream>
class Component {
public:
virtual ~Component() {}
};
class GameObject {
public:
template <typename T>
void addComponent(T *component);
template <typename T>
T *getComponent();
std::unordered_map<std::typeindex, Component *> components;
};
template <typename>
struct direct_bases_as_tuple {};
template <typename... Types>
struct direct_bases_as_tuple<std::tr2::__reflection_typelist<Types...>> {
typedef std::tuple<Types...> type;
};
template <std::size_t N, typename ComponentBases, typename ComponentType>
struct AddComponent {
GameObject *owner;
explicit AddComponent(GameObject *owner) : owner(owner) {}
void operator()(ComponentType *component) {
AddComponent<N-1, ComponentBases, ComponentType>{owner}(component);
using BaseType = std::tuple_element<N-1, ComponentBases>::type;
owner->components[typeid(BaseType)] = component;
}
};
template <typename ComponentBases, typename ComponentType>
struct AddComponent<0u, ComponentBases, ComponentType> {
GameObject *owner;
explicit AddComponent(GameObject *owner) : owner(owner) {}
void operator()(ComponentType *component) {
return;
}
};
template <typename T>
void GameObject::addComponent(T *component) {
using ComponentBases = direct_bases_as_tuple<std::tr2::direct_bases<ComponentType>::type>::type;
constexpr classCount = std::tuple_size<ComponentBases>::value;
AddComponent<classCount, ComponentBases, T>{this}(component);
components[typeid(T)] = component;
}
template <typename T>
T * GameObject::getComponent() {
auto iter = components.find(typeid(T));
if (iter != std::end(components)) {
return dynamic_cast<T *>(iter->second);
}
return nullptr;
}
class Collider : public Component {};
class SphereCollider : public Collider {};
int main() {
GameObject gameObject;
gameObject.addComponent(new SphereCollider);
//get by derived class
SphereCollider *sphereColliderA = gameObject.getComponent<SphereCollider>();
//get by subclass
SphereCollider *sphereColliderB = dynamic_cast<SphereCollider *>(
gameObject.getComponent<Collider>()
);
if (sphereColliderA == sphereColliderB) {
std::cout << "good" << std::endl;
}
}
I created the AddComponent struct to recurse through the component base classes at compile-time and insert the pointer (value) with the corresponding class (key) each iteration. The helper struct direct_bases_as_tuple was inspired by Andy Prowl's answer to change the direct bases into a tuple. I compiled this using GCC 4.9.2 using C++11 features.
I know this post is already answered, but if you look into Game Programming Patterns, in this book he has a design pattern called Service Locator, and at the end, it says Unity uses this pattern together with the Component Pattern. I wish I could answer into more specifics, but this could be another way to approach this.
The Unity engine is linked with a forked mono runtime, on which unity scripts are executed.
In UnityEngine.Component
public class Component : Object
{
.
.
[TypeInferenceRule(TypeInferenceRules.TypeReferencedByFirstArgument)]
public Component GetComponent(Type type)
{
return this.gameObject.GetComponent(type);
}
[GeneratedByOldBindingsGenerator]
[MethodImpl(MethodImplOptions.InternalCall)]
internal extern void GetComponentFastPath(Type type, IntPtr oneFurtherThanResultValue);
[SecuritySafeCritical]
public unsafe T GetComponent<T>()
{
CastHelper<T> castHelper = default(CastHelper<T>);
this.GetComponentFastPath(typeof(T), new IntPtr((void*)(&castHelper.onePointerFurtherThanT)));
return castHelper.t;
}
.
.
}
The C# code performs native calls, called Icalls to C++ methods that have been bound to the C# methods using the C# runtime library API. Bodyless (unimplemented) methods need either an extern, abstract or partial specifier as a rule so all internal calls are marked as extern. When the runtime sees a method with the [MethodImpl(MethodImplOptions.InternalCall)] attribute it knows it needs to make an Icall, so it looks up the function it has been bound to and jumps to that address.
An Icall does not need to be static in C# and automatically passes the this MonoObject of the component to the C++ handler function. If they are static then the this object is usually deliberately passed as a parameter using a C# shim method and making the shim method the static Icall. Using Icalls, types are not marshalled unless they are blittable types, meaning all other types are passed as MonoObject, MonoString etc.
Typically the C++ methods are functions or static methods but I think they can be non static methods as well, so long as they aren't virtual, because the address cannot be fixed by the runtime.
in UnityEngine.GameObject
public sealed class GameObject : Object
{
.
.
public GameObject(string name)
{
GameObject.Internal_CreateGameObject(this, name);
}
public GameObject()
{
GameObject.Internal_CreateGameObject(this, (string) null);
}
[WrapperlessIcall]
[TypeInferenceRule(TypeInferenceRules.TypeReferencedByFirstArgument)]
[MethodImpl(MethodImplOptions.InternalCall)]
public extern Component GetComponent(System.Type type);
[WrapperlessIcall]
[MethodImpl(MethodImplOptions.InternalCall)]
private static extern void Internal_CreateGameObject([Writable] GameObject mono, string name);
.
.
}
The C# constructor for the GameObject contains a call to a native method. The body of the constructor is run after initialisation of the C# object such that there is already a this pointer. Internal_CreateGameObject is the static shim function that is actually called.
Someone's example implementation of their own C++ Internal_CreateGameObject using mono:
bool GameObjectBinding::init()
{
MonoClass *gameObjectClass = Mono::get().getClass("GameObject");
gameObject_NativeID_Field = mono_class_get_field_from_name(gameObjectClass, "nativeID");
MonoClass *transformClass = Mono::get().getClass("Transform");
transform_NativeID_Field = mono_class_get_field_from_name(transformClass, "nativeID");
mono_add_internal_call("GameEngine_CS.GameObject::internal_createGameObject", GameObjectBinding::createGameObject);
mono_add_internal_call("GameEngine_CS.GameObject::internal_deleteGameObject", GameObjectBinding::deleteGameObject);
mono_add_internal_call("GameEngine_CS.GameObject::internal_getGameObject", GameObjectBinding::getGameObject);
mono_add_internal_call("GameEngine_CS.GameObject::internal_getTransform", GameObjectBinding::getTransform);
return true;
}
void GameObjectBinding::createGameObject(MonoObject * monoGameObject)
{
Object *newObject = LevelManager::get().getCurrentLevel()->createObject(0);
mono_field_set_value(monoGameObject, gameObject_NativeID_Field, (void*)newObject->getID());
}
mono_add_internal_call has been used to bind this method to GameObjectBinding::createGameObject, to which the this pointer is passed as a MonoObject pointer. A native object is then created to represent the GameObject, and mono_field_set_value is then used to set the NativeID field of the C# object to the ID of the new native object. This way the native object can be accessed from the MonoObject which is the internal implementation of the C# object. The GameObject is represented by 2 objects essentially.
public sealed class GameObject : Object
{
.
.
private UInt32 nativeID;
public UInt32 id { get { return nativeID; } }
.
.
}
This field is bound in the runtime using
mono_set_dirs( "/Library/Frameworks/Mono.framework/Home/lib", "/Library/Frameworks/Mono.framework/Home/etc" );
mono_config_parse( nullptr );
const char* managedbinarypath = "C:/Test.dll";
MonoDomain* domain = mono_jit_init(managedbinarypath)
MonoAssembly* assembly = mono_domain_assembly_open (domain, managedbinarypath);
MonoImage* image = mono_assembly_get_image (assembly);
MonoClass* gameobjectclass = mono_class_from_name(image, "ManagedLibrary", "GameObject");
gameObject_NativeID_Field = mono_class_get_field_from_name( gameobjectclass, "nativeID" );
GetComponent<T>() passes typeof(T) to GetComponentFastPath (the native call) which passes the this pointer of the component as well. The native implementation of GetComponentFastPath will receive this as a MonoObject* and a MonoReflectionType* for the type. The bound C++ method will then call mono_reflection_type_get_type() on the MonoReflectionType* to get the MonoType* (here are the primitive types: https://github.com/samneirinck/cemono/blob/master/src/native/inc/mono/mono/metadata/blob.h), or for object types you can get the MonoClass* from MonoType* using mono_class_from_mono_type(). It will then get the game object that is attached to the Component and search the components that the object has in some internal data structure.
Someone's example implementation of their own C++ GetComponent using mono:
id ModuleScriptImporter::RegisterAPI()
{
//GAMEOBJECT
mono_add_internal_call("TheEngine.TheGameObject::CreateNewGameObject", (const void*)CreateGameObject);
mono_add_internal_call("TheEngine.TheGameObject::AddComponent", (const void*)AddComponent);
mono_add_internal_call("TheEngine.TheGameObject::GetComponent", (const void*)GetComponent);
}
MonoObject* ModuleScriptImporter::GetComponent(MonoObject * object, MonoReflectionType * type)
{
return current_script->GetComponent(object, type);
}
MonoObject* CSharpScript::GetComponent(MonoObject* object, MonoReflectionType* type)
{
if (!CheckMonoObject(object))
{
return nullptr;
}
if (currentGameObject == nullptr)
{
return nullptr;
}
MonoType* t = mono_reflection_type_get_type(type);
std::string name = mono_type_get_name(t);
const char* comp_name = "";
if (name == "CulverinEditor.Transform")
{
comp_name = "Transform";
}
MonoClass* classT = mono_class_from_name(App->importer->iScript->GetCulverinImage(), "CulverinEditor", comp_name);
if (classT)
{
MonoObject* new_object = mono_object_new(CSdomain, classT);
if (new_object)
{
return new_object;
}
}
return nullptr;
}
C# methods can be invoked from C++:
MonoMethodDesc* desc = mono_method_desc_new (const char *name, gboolean include_namespace);
MonoClass* class = mono_class_from_name (MonoImage *image, const char* name_space, const char *name);
MonoMethod* method = mono_method_desc_search_in_class (MonoMethodDesc *desc, MonoClass *klass);
MonoMethod* method = mono_method_desc_search_in_image (MonoMethodDesc *desc, MonoImage *image);
MonoObject* obj = mono_runtime_invoke (MonoMethod *method, void *obj, void **params,
MonoObject **exc);
See: https://gamedev.stackexchange.com/questions/115573/how-are-methods-like-awake-start-and-update-called-in-unity/183091#183091
There is a good introduction article to ECS: https://austinmorlan.com/posts/entity_component_system/ made differently than TOM__'s post.
I am having a strange problem instantiating a structure living inside a class, where in construction it calls the destructor (several times) and even calls the parent object destructor.
Class with structure:
class Model {
public:
struct StepModelIO {
StepModelIO(Model model, ...) {DoConstruction(Model model, ...);}
StepModelIO(const StepModelIO &other) {DoConstruction(Model model, ...); }
~StepModelIO() {}
DoConstruction() {
...
}
}
Model(...) {
...
}
Model(const Model &other) {DoConstruction(...);}
~Model() {
...
}
private:
DoConstruction(...) {
}
}
Calling function:
void main() {
Model::StepModelIO stepArgs = Model::StepModelIO(...);
}
The resulting set of calls, with 'object' being the StepModelIO and 'parent' being the Model:
Construct parent w/ copy constructor
Construct object
Destruct parent
Construct object w/ copy constructor
Construct parent w/ copy constructor
Construct object
Destruct parent
Destruct object
Destruct object (again...)
Destruct parent
Unsurprisingly the resulting structure (a StepModelIO) is not in a good state after this all happens, and the path seemed ridiculous. I have the structure housed like this to use the same generic at the parent Model object, which may explain some of the issues.
I have tried (perhaps naively) to use the 'rule of three' on constructors and destructors, it's possible I've munged this up badly.
Edit: Full code
template<typename U, typename V>
class Model{
public:
struct StepModelIO {
Model<U, V> model;
U u;
V v;
StepModelIO() {}
StepModelIO(Model<U, V> model, U u, V v) {
this->model = model;
this->u = u;
this->v = v;
}
StepModelIO (const StepModelIO &other) {
StepModelIO(other.model, other.u, other.v);
}
~StepModelIO() {
}
};
Model(char * libraryPath) {DoConstruction(libraryPath);}
Model() {}
Model (const Model &other) {
DoConstruction(other.m_LibraryPath);
}
~Model() {
this->Stop();
}
void Init() {
if (!this->m_Initialised) {
this->ModelInit();
m_Initialised = true;
}
}
void Stop() {
if (this->m_Initialised) {
this->ModelStop();
m_Initialised = false;
}
}
void Restart() {
this->ModelRestart();
}
void Step(U u, V v) {
ModelStep(u, v);
}
private:
char* m_LibraryPath;
HINSTANCE m_ModelDLL;
bool m_Initialised;
typedef int (__cdecl * EmptyModelFunctionPointer)(); // Interpret integer as C code pointer named 'EmptyModelFunctionPointer'
typedef int (__cdecl * ModelFunctionPointer)(U u, V v);
EmptyModelFunctionPointer ModelInit;
EmptyModelFunctionPointer ModelStop;
EmptyModelFunctionPointer ModelRestart;
ModelFunctionPointer ModelStep;
virtual void DoConstruction(char * libraryPath){
this->m_Initialised = false;
this->m_LibraryPath = libraryPath;
this->m_ModelDLL = LoadLibrary(libraryPath);
this->ModelInit = GetFunction<EmptyModelFunctionPointer>(m_ModelDLL, "Init");
this->ModelStop = GetFunction<EmptyModelFunctionPointer>(m_ModelDLL, "Stop");
this->ModelRestart = GetFunction<EmptyModelFunctionPointer>(m_ModelDLL, "Restart");
this->ModelStep = GetFunction<ModelFunctionPointer>(m_ModelDLL, "Step");
}
template<typename pointerType>
pointerType GetFunction(HINSTANCE modelLibrary, char * functionName){
return (pointerType)GetProcAddress(HMODULE (modelLibrary),functionName);
}
};
Caller:
StepModelIO<Type_1*, Type_2*> stepArgs = StepModelIO<Type_1*, Type_2*>(newModel, &a, &b[0]);
You're passing things by value, which will result in temporary objects being constructed and destructed. Pass them by const reference instead.
change
StepModelIO(Model model, ...)
to
StepModelIO(const Model &model, ...)
You've now changed the code. So you really want this, I think.
StepModelIO(const Model<U, V> &model, const U &u, const V &v)
I have notices tat inside the class StepModelIO you have a member Model<U, V> model; so for each instance of class StepModelIO the destructor of model will be caled also; first ~StepModelIO() and second ~Model<U, V>()
so given the code you provided:
Model::StepModelIO stepArgs = Model::StepModelIO(...);
This has two objects of the type StepModelIO. One is the on in the right (rvalue) and the second one is stepArgs.
First the destructor for the one in the right is called resulting in:
1:Destruct StepModelIO
2:Destruct Model
And when the destruction of stepArgs occurs :
3:Destruct StepModelIO
4:Destruct Model