Linked lists, Managers and actors

Yesterday evening, after writing the erudite blog post about textures, lighting and what I'd been working on, I went and watched a show about the goodies with my dad. I took with me a pad, and sketched out a rough diagram of the relationships between actors, lights, physics bodies, and managers (for the lights and actors) in my game.

Today, I sat down and implemented it.

Instead of the mess I had yesterday, I now have a beautifully organised, manageable,  expandable system for controlling actors and lights. Writing the system also introduced me to the beauty of linked lists.

I used linked lists in each of the manager classes, for both actors, and for lights. The linked list was formed of either Actor or Light objects, with pointers to the next and previous objects in the list. This isn't an especially new idea, but I had a couple of main reasons for wanting to structure the managers like this:

1) Eaisily implementable, expandable storage.
I can hear you now screaming "adam, if you wanted expandable storage, why didnt you use the std::vector???", or, I would if anyone read this blog. Of course, I could have used the std::vector class, but I had one massive reason against it. Pointers. Each of the bodies in the physics engine stores a pointer to its Actor, each Actor stores a pointer to its Light and each Light stores a pointer to its actor. If I was to implement the managers storage as a vector then it would have meant a lot more work for me in the long run figuring out how to manage pointers to members of vectors, and I couldn't be bothered.  As is, the linked list system works very well, as well as being very easy to iterate through.

2) As a learning exercise in pointers.
Despite having programmed quite a lot in c++, I am a bit of a novice with pointers. Implementing the data as a linked list forced me to really get to grips with pointers, manipulating them, and initialising them with new.

Having finished the core of the Actor, Actor_manager, Light and Light_manager classes, I can now begin to expand on them, and to implement further functionality, like shadows.

I still have two main hurdles to jump before properly getting shadows working:
1) Sensor shapes for the lights.
Ideally I would like to have a Box2d shape associated with the light, so that I can test intersection with bodies in the world, and thus whether I need to draw shadows for them.
2) Contact callbacks.
Instead of testing intersections manually, Box2d allows the programmer to define a contact callback class, which will call functions when two fixtures (wrappers for shapes) intersect. Once I have this up and running, I can configure it so that shadows will be drawn for fixtures when they intersect with shapes.

So, onwards and upwards!