I will try to help where I can, here goes

- I would say that replacing FastDelegate could be a great choice since it is standard, just so long as it; a) offers the same flexibility, b) Has comparable speeds. Not being able to compare them though isn't really very nice however.

- I would say in my opinion, DONT link the event listeners to actor id's, events are something you are going to want to use all over the place, it is a very generic system. Find a way to compare the functions (if possible), or stick with FastDelegate.

- Personally, I allow components to access their OWNERS components, but any communication from actor-actor is done in different ways, most of the time, the events are passed to a centralized system ie. When the transform is dirty for an actor, I send out an even notifying all systems that they need to update their representations of the actor, so the physics system will find the rigid body for that actor, and set its position (although you really shouldn't teleport rigid bodies like that if you don't have to), and the render system will find the scene node, and update its transform. Rather than directing events to the components for those actors, I use the systems they are meant to interface with. NOW, if you had AI implemented in a component, it might register to game logic events such as the player moving to loudly, and it would respond by investigating. That sort of decoupling is really handy, because you don't have to have spaghetti code linking objects/players. Instead, when an object makes noise, it just sends off an event and doesn't worry about who reacts to it.

- This one is an easy one, what I generally do is automatically create a scene node acting as the root of each actor, than when you add your render components scene node, look for the node that is automatically created, and add your new one as a child. This way it is easy to find, keeps your graph nice and clean, and makes removal of an actor much quicker.

- This one doesn't have alot of material on the web, you can find bits and pieces, and even catch more experienced devs talking about how they did certain things, but rendering engines are usually massive, so it would need a book in itself (or multiple books), just to get you started on it. As far as how the separation between the graph and the API occur, I have found (from my investigations, and experiences);

- A rendering queue is built up by your graph, this gives a lot of benefits such as easier sorting (transparency, conserving API calls/switches), and also makes multi-threaded rendering much easier.
- The queue contains render 'operations' which describe either low level commands to be applied, or even high level 'entities' to be rendered.
- An entity draw operation would define the mesh and materials with things such as; Buffers (vertices, indices), Shaders, Textures, Animations
- I would even say at this level your rendering could still be abstract
- The reason this helps with multi-threading, is that all of the OpenGL (or Direct3D) calls will be confined to the thread which processes your queue which saves a lot of hassle (rather than trying to keep everything shared with multiple contexts), everything called from your scene graph is just a common render operation.

I hope this helps, let me know if you want to go more in depth on a topic.

Regarding FastDelegate:

I'll start by saying that std::function and C++ 11 lambdas are perfectly valid choices for an event system. I actually looked in both before settling on FastDelegate. I think it's incorrect to tightly couple it with the actor system; you're only going to cause yourself more headaches down the road. For those who are curious, here's my take and why I chose FastDelegates.

When you say that's it strange to think of functions as being comparable, it's actually the opposite. Most modern high-level languages allow you to treat functions as first-class objects. Specifically, I wanted to mimic C#'s delegate functions which are a nice, clean way to solve this problem. std::function doesn't quite do this, but it does get a step closer.

As I said, I looked into using C++ 11's std::function as well as lambda functions when I wrote the event chapter, but they didn't offer what I was looking for. I didn't want an id because there was no simple way to look it up. I wasn't willing to couple the actor system with the event system because the two are absolutely separate. Furthermore, std::function and lambdas are also quite a bit slower than a fast delegate (I did some benchmarks), though probably not enough to significantly matter unless you're sending tons of events.

Again, what you've effectively done is tightly coupled the actor system and the event system. This type of coupling is generally not desirable. What happens if I want to send an event from one system to another? I can't, I would need to make that system an actor or invent a new id (which would be very hacky). In the version shown in GCC4, you could take that event system and drop it into any game engine and have it work just fine. The bottom line is that your coupling isn't very maintainable.

Finally, Fast delegate likely won't change much, but it is EXTREMELY well documented. Just open the header file or read the codeproject article and you'll see the author go into excruciating detail on the implementation. You can also open the 3rd party lib folder, find the file, and read the code. Now take a look at the implementation for std::function and tell me which one has better documentation.

In the end, the choice is yours. If you like std::function better, go for it.

Regarding the actor event system:

The use-case I was talking about was more about communication within the actor. Specifically, the actor would act as an event system that only its components registered to. That way you could send a single event to one or more actors and not care how they were handled.

For example, let's say you have a grenade that explodes. You could grab all actors within a radius and send a "grenade exploded" event to those actors (not through the global event system). The actors in turn would broadcast that event to the components registered, in this case the AI component and a health component are registered to receive that event. The health component would damage the player and the AI component would change the behavior.

Without this, you'd end up grabbing the actor, then getting both of those components from the actor. You'd check if the component existed and, if it did, you'd call some function to get the desired result. This tightly couples those components to the grenade.

Turning actors into mini-event systems is a great way to handle that. The downside is that it's more overhead per actor, so if you do have 1000 actors, it might be a bit much.

Also, when the grenade explodes, you would never want to send a global event and just test out 99% of the actors. You'd have some kind of space partitioning system, like a quadtree or octree, to handle choosing which actors to notify. Once you have the list of actors you needed to affect, you could either use this method of notifying the actors or send a global event caught & processed by another system that updated things.

For example, I have component systems that I allow components to register to. When an actor is created with a component, those systems are notified and store a weak ref to that component. Thus, when a grenade explodes, I can send a global "grenade exploded" event that is caught by my two component systems (or for AI and one for health) to update the appropriate actors.

There are many ways to solve this problem. I've seen a number of them used before, but the one that's most common is to just grab the components and update them directly.

-Rez

Originally posted by boxy
You're very right! I had a look at the source code and it's extremely well documented I spoke way too soon. Still, I find it a bit off putting that the library hasn't seen much (if any) love from it's author at all for the last 7 or 8 years.

That's because he hasn't had to. Still, a lot of engineers are leery about using code they find on the internet. I totally get that and used to be the same way. To each their own.

I can see why having an ID system for the EventManager could be hacky, but when I first thought about it. It sounded pretty good in terms of performance. Both removing and retrieving now run in log time by using a map (the event system in GCC used a list if I remember correctly). And instead of comparing delegates, we only compare the ID. It comes at the expense of the listeners having to hold a copy of that ID if they want to ever de-register from the event system.

You can't think about performance until you're actually trying to solve a performance problem, especially when you're just starting out. You won't know which is better. In fact, I would be willing to bet that your system is slower overall.

For example, look at these two functions. They both swap two variables. One does it with a temporary variable and the other does it with XOR.



Which one is faster? Most people will tell you the XOR method is faster since you're not storing a temporary variable. I've seen articles telling you to always do this because it's better. The reality is that it's usually not, the temp variable is almost always better.

Assumptions and premature optimizations are very bad and always cause more harm then good.

Do I just let Actor inherit from EventManager?

That's the simplest way to do it, yeah. The event manager is a bit heavy weight for what you'd need there, but it's a good place to start.

Wow, that sounds crazy from a naive point of view. You would have as many ComponentSystems as there are different types of Component!

Not exactly. Most components don't need systems, only the ones that actively process stuff every frame. I don't have an Update() function on my components; meaning that my actors never take up per-frame CPU time unless they have to. I think I have maybe five or six systems in the entire engine, compared to the 30+ components I ended up with. For example, the TransformComponent doesn't need a system, nor does the ScriptComponent. None of my Lua-based components are ticked either, so they don't have anything.

If you're interested, I'd check out this post:
mcshaffry.com/GameCode/thread.php?threadid=1916&sid=

I go pretty deep into the component system I built for my own engine. The one I built for GCC 4 is loosely based off of it.

-Rez