Comments on: Growing a Ginkgo (2): Components [...] one of the key pieces of technology in our brand new game engine Ginkgo: The component system. The original posting – and some valuable comments – can be found on the fabulous [...] [...] one of the key pieces of technology in our brand new game engine Ginkgo: The component system. The original posting – and some valuable comments – can be found on the fabulous [...]

]]>
By: Ginkgo’s Game Loop » #AltDevBlogADay/2011/02/08/growing-a-ginkgo-2-components/#comment-943 Ginkgo’s Game Loop » #AltDevBlogADay Wed, 23 Feb 2011 14:28:26 +0000 In the current version everything fails _very_ easily. We'll keep it like that while we've got our hands in the innards of the engine every day. Once we'll near production, I guess we'll have to settle for a more subtle solution to this problem. In the current version everything fails _very_ easily. We’ll keep it like that while we’ve got our hands in the innards of the engine every day. Once we’ll near production, I guess we’ll have to settle for a more subtle solution to this problem.

]]>
By: martin/2011/02/08/growing-a-ginkgo-2-components/#comment-840 martin Thu, 17 Feb 2011 06:55:44 +0000 (OOPS - replied to the wrong thing - just in case, I'll reply to the RIGHT thing. Hopefully.) Interesting stuff. I’m also attempting to implement a version of Terrence Cohen’s system. I’d love more details on what’s going on in your macros, as information on Terrence’s COMPONENT macro is non-existent. This is what I’m currently tackling – my TypeRegistrar is not currently linked in any way to component classes. How is yours linked, I wonder? Scratching my head a bit… I also notice you’ve chosen to go non-virtual with the update function as opposed to his virtual update function. I figured (naively?!) that the vtable indirection would be absorbed by the d-cache once you’ve updated the first component of a type, and all the repeated calls (for the rest of the components in the pool) wouldn’t really cost… Keep it coming! (OOPS – replied to the wrong thing – just in case, I’ll reply to the RIGHT thing. Hopefully.)

Interesting stuff. I’m also attempting to implement a version of Terrence Cohen’s system.

I’d love more details on what’s going on in your macros, as information on Terrence’s COMPONENT macro is non-existent. This is what I’m currently tackling – my TypeRegistrar is not currently linked in any way to component classes. How is yours linked, I wonder? Scratching my head a bit…

I also notice you’ve chosen to go non-virtual with the update function as opposed to his virtual update function. I figured (naively?!) that the vtable indirection would be absorbed by the d-cache once you’ve updated the first component of a type, and all the repeated calls (for the rest of the components in the pool) wouldn’t really cost…

Keep it coming!

]]>
By: Brooksoid/2011/02/08/growing-a-ginkgo-2-components/#comment-830 Brooksoid Wed, 16 Feb 2011 16:32:07 +0000 Nice post. I really like the notification callback for changes made to the parent object. This would be a great way for components to cache pointers to each other and cut down the number of dynamic queries required. Of course this is making the reasonable assumption that queries outnumber component instance changes by an order of magnitude. I would also be interested to hear if and how you support a GetComponent( ComponentType ) on an object instance. Nice post. I really like the notification callback for changes made to the parent object. This would be a great way for components to cache pointers to each other and cut down the number of dynamic queries required. Of course this is making the reasonable assumption that queries outnumber component instance changes by an order of magnitude. I would also be interested to hear if and how you support a GetComponent( ComponentType ) on an object instance.

]]>
By: Sven Bergström/2011/02/08/growing-a-ginkgo-2-components/#comment-344 Sven Bergström Wed, 09 Feb 2011 09:51:30 +0000 It depends on the component. If it requires specific other components it causes a break in our debug build. If it just queries for another component and doesn't find any, the results are varied. As I said, we use a fail-early approach: The sooner the system complains the better. Once our tools pipeline is properly set up and our engine is more stable we have to re-evaluate our stance. And for release builds as well. It depends on the component. If it requires specific other components it causes a break in our debug build. If it just queries for another component and doesn’t find any, the results are varied. As I said, we use a fail-early approach: The sooner the system complains the better. Once our tools pipeline is properly set up and our engine is more stable we have to re-evaluate our stance. And for release builds as well.

]]>
By: Sven Bergström/2011/02/08/growing-a-ginkgo-2-components/#comment-342 Sven Bergström Wed, 09 Feb 2011 08:38:27 +0000 Ah. Of course. Added the link to the first post. Ah. Of course. Added the link to the first post.

]]>
By: Sven Bergström/2011/02/08/growing-a-ginkgo-2-components/#comment-340 Sven Bergström Tue, 08 Feb 2011 20:30:09 +0000