shadowlordalpha / djinnengine Goto Github PK

The ActorController needs to handle the update and rendering functions to be 
able to update and 
render all actors in the game world. I would not like to pass this off to the 
objects, since the 
controller should take the data and draw them, not tell the actors to draw 
themselves.

While I like the way Apple did the Texture2D, I feel that in order for me to 
learn how to really use 
OpenGL, I would need to write my own implementation of a texture class.

Currently re-working all OpenGL calls: (ScreenController setupView for example) 
and re-working 
the update / draw functions of the Particle Controller / Particle Emitter 
systems in order to attempt 
and track down the OpenGL bug I described in previous issue. 

Should be done by the weekend, and fully committed. If the bug still remains, 
I'll just remove the 
point sprites drawing functionality from the Particle Emitter and work it as a 
GL_TRIANGLE_FAN

 In the TestGame class, remove the call to testActor->draw( deltaTime ); and let the particle engine 
draw normally. Program should crash with an "EXC_BAD_ACCESS"

Create a system that takes advantage of storing several textures in a single 
PNG file and just 
rendering a portion of that texture to screen. With this system, you can have 
an animation have 
several frames, but all be contained on the same texture, and you would render 
the appropriate 
portion of the texture

Update any animation or logic this object may require. Currently being 'faked' 
in the testActor 
object in the UnitTests.

#warning TODO:: Do I want to return a pointer to the actor, or do I wish the 
controller keep all 
information and flush that information when scene changes?

I think the safest way to do this is have the controller manage all actors 
currently active in the 
world and if the client wishes to get a reference to that actor, there should 
be a way to do that 
via the Actors Identity.

To that end, what I may end up doing is when the actor is constructed, a copy 
of the ID is 
returned to the client so if the client needs to track specific actors, it can 
store that ID and refer 
to it later.. if not, then it can just let the controller handle all logic for 
the actor. An example of 
when you'd want to store the ID and refer to it later is the Player.

There are various ways to do this though, will need to play around with some 
things before I 
commit any changes.