14
Nov
Each fWorld keeps track of its own time
Each fWorld keeps track of its own time starting with zero at creation. In order to simulate time, a world must be updated. Updating is done by calling the method update() with one argument: the amount of time that the core should update. This method will be called by an outsider probably a thread in the application. This feature gives us the ability to run the world in slow motion or fast forward, but most important of all, we can make two identical worlds run equally fast on different machines. For example, if you run the same game on a very fast machine and a very slow machine that stand one foot from each other, the worlds will still be synchronized. One of them will run much more smoothly, since it will be updated more often and with shorter time intervals, while the other one will chop forward with jerky motions but will still keep up as much as possible. Some parallels can be drawn with the bouncing rectangles in Chapter 2, Using Objects for Animation, except that the applet shown there will run at different speeds depending on the host machine. Each time the world is updated the following things take place: All objects are updated. At this stage all the objects in the world make changes to their internal state. A static object will not do much except age, while a moving object will update its position and angle. Extensions of the generic core objects will take additional actions that will give them their own personal behavior. This will be shown in the basic examples. Collisions are detected. Before the core checks for a collision between two objects, it will first ask them both: Is either of you interested in a collision with other? If that is the case, then a detection will be done and the interested parties will be notified. This notification will be turned into an event that is taken care of at the next stage. How to use collision notification will be shown in one of the basic examples. All objects are instructed to handle their events. Since the world runs at discrete time intervals, it must be ensured that things happen in a certain order. For example, you wouldn t want to start changing the position of an object in the middle of a collision detection. To ensure the integrity of the core, most actions on an object will be done through events that are taken care of at this stage. The event making, posting, and handling is hidden within the objects. An example is the collision notification. When objects collide, their collisionWith(..) method is called. In this method the object will make an event and put it in its event list. At the event handling stage (this stage), the event will be cracked, and another method, handleCollisionWith(..), is called. It might seem like a lot of beating around the bush, but this way guarantees that things happen when they should. I jumped over two stages that do not play a major role in understanding the core. One of them is the divineIntervention(..) method, and the other is the insertion of new objects stage, both of which are reserved for networking capabilities in later versions. Previous Table of Contents Next
Hint: This post is supported by Gama hrvatski web hosting services