Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 02 Oct 2013
Offline Last Active Yesterday, 12:00 PM

Posts I've Made

In Topic: boost::signals2 combiner not compiling...

21 September 2014 - 11:58 AM

I am facepalming so hard right now, thanks!

In Topic: Wrote an Entity-Component Framework

16 September 2014 - 02:07 AM

@Juliean - That's exactly what I'm doing. biggrin.png

In Topic: Microsoft buys Mojang for $2.5 Billion

15 September 2014 - 02:13 PM

I can't wait to sign into MineCraft with my Windows Live Account rolleyes.gif

In Topic: Wrote an Entity-Component Framework

15 September 2014 - 02:10 PM

it doesn't appear as though the systems are declaring anything about what components they support, the call to addsystem() is providing that information externally, which isn't quite the same thing.

The information eventually ends up inside the base class of System. The reason I didn't want to do it through System's constructor was for three reasons:

  • It would force the user to write a constructor every time he derives from System just to pass in the necessary information.
  • Adding future options/more arguments to addSystem would cause every derived class' constructor to be re-written -> unnecessary.
  • addSystem() is more capable of making default decisions when arguments aren't supplied because the class it belongs to has access to all systems (such as execution reordering).

You could create a system that only knows how to work on a component of type A, and call addSystem() and tell the systemmanager it works on components of type B, and it would be quite happy to sit there idle I'm guessing?

What Starfarer42 said and you'll get a runtime error if you try to fetch a component from an entity that doesn't exist.
@ Starfarer42 & KulSeran

Thanks for the explanation, now I get where you're coming from. I've added it to my todo list.


Two other things I'm working on are:

  • Each system to precompute a list of entities it supports instead of comparing every time world.update() is called.
  • A multithreaded approach at processing entities.

In Topic: Wrote an Entity-Component Framework

12 September 2014 - 03:22 AM

Thanks for the feedback!



I'd say the biggest issue with this system is that you're storing components on entities without a decent wrapper for how to allocate those components.
Ideally, each component would be contiguous in ram, as opposed to disjoint as your example code will generate (via "new Position(...)").  I'd like to see a better wrapper that hides the allocation scheme of the components to allow for better memory access patterns.

Very good point, I'll see if I can get that to work. Is there a common technique when trying to store varying types in contiguous memory? I can think of two immediate ways, such as maintaining n number of std::vector objects where n=number of types, or doing some allocation trickery since the types are known at compile time. [EDIT] Actually scratch the first suggestion, there's guaranteed to only ever be one instance of every component.




Passing a unique pointer instead of a raw pointer is also better if you are giving up ownership

I actually removed that because I found it makes its usage a little unwieldy and harder to read. I know that shouldn't be an argument...