sandey/blender
1
0
Fork 0
forked from bartvdbraak/blender
Code Pull Requests Activity
386122ada6
blender/source/gameengine/GameLogic/SCA_LogicManager.h

140 lines
4.5 KiB
C
Raw Normal View History

Initial revision
2002-10-12 11:37:38 +00:00
/**
* $Id$
*
Patch from GSR that a) fixes a whole bunch of GPL/BL license blocks that were previously missed; and b) greatly increase my ohloh stats!
2008-04-16 22:40:48 +00:00
* ***** BEGIN GPL LICENSE BLOCK *****
Initial revision
2002-10-12 11:37:38 +00:00
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
Patch from GSR that a) fixes a whole bunch of GPL/BL license blocks that were previously missed; and b) greatly increase my ohloh stats!
2008-04-16 22:40:48 +00:00
* of the License, or (at your option) any later version.
Initial revision
2002-10-12 11:37:38 +00:00
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
* Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
* The Original Code is Copyright (C) 2001-2002 by NaN Holding BV.
* All rights reserved.
*
* The Original Code is: all of this file.
*
* Contributor(s): none yet.
*
Patch from GSR that a) fixes a whole bunch of GPL/BL license blocks that were previously missed; and b) greatly increase my ohloh stats!
2008-04-16 22:40:48 +00:00
* ***** END GPL LICENSE BLOCK *****
Initial revision
2002-10-12 11:37:38 +00:00
* Regulates the top-level logic behaviour for one scene.
*/
#ifndef __KX_LOGICMANAGER
#define __KX_LOGICMANAGER
#ifdef WIN32
#pragma warning (disable:4786)
#endif
#include <vector>
//#include "GEN_Map.h"
#include <set>
#include <map>
#include <list>
#include "GEN_Map.h"
#include "STR_HashedString.h"
#include "Value.h"
BGE performance, 4th round: logic This commit extends the technique of dynamic linked list to the logic system to eliminate as much as possible temporaries, map lookup or full scan. The logic engine is now free of memory allocation, which is an important stability factor. The overhead of the logic system is reduced by a factor between 3 and 6 depending on the logic setup. This is the speed-up you can expect on a logic setup using simple bricks. Heavy bricks like python controllers and ray sensors will still take about the same time to execute so the speed up will be less important. The core of the logic engine has been much reworked but the functionality is still the same except for one thing: the priority system on the execution of controllers. The exact same remark applies to actuators but I'll explain for controllers only: Previously, it was possible, with the "executePriority" attribute to set a controller to run before any other controllers in the game. Other than that, the sequential execution of controllers, as defined in Blender was guaranteed by default. With the new system, the sequential execution of controllers is still guaranteed but only within the controllers of one object. the user can no longer set a controller to run before any other controllers in the game. The "executePriority" attribute controls the execution of controllers within one object. The priority is a small number starting from 0 for the first controller and incrementing for each controller. If this missing feature is a must, a special method can be implemented to set a controller to run before all other controllers. Other improvements: - Systematic use of reference in parameter passing to avoid unnecessary data copy - Use pre increment in iterator instead of post increment to avoid temporary allocation - Use const char* instead of STR_String whenever possible to avoid temporary allocation - Fix reference counting bugs (memory leak) - Fix a crash in certain cases of state switching and object deletion - Minor speed up in property sensor - Removal of objects during the game is a lot faster
2009-05-10 20:53:58 +00:00
#include "SG_QList.h"
Initial revision
2002-10-12 11:37:38 +00:00
Patch: [ #2439 ] Makes objects react properly to deformations after a mesh replacement call. from brian hayward (bthayward) Detailed description: Currently, when an armature deformed object's mesh is replaced by the ReplaceMesh actuator, the new mesh fails to deform to the armature's movement. My patch fixes this by properly replacing the deform controller along with the mesh (when appropriete). For instance, if one had an animated character using any of the standard deformation techniques (armature, ipo, RVK, or AVK), that character's mesh would currently be prevented from changing mid-game. It could be replaced, but the new mesh would lack the controller which tells it how to deform. If one wanted to dynamiclly add a hat on top of the character's head, it would require storing a secondary prebuilt character (mesh, armature, logic, ect...) on another layer FOR EACH HAT the character could possibly wear, then swapping out the whole character when the hat change was desired. So if you had 4 possible hat/character combos, you would have 4 character meshes, 4 armatures, 4 sets of logic, and so on. I find this lack of flexibility to be unresonable. With my patch, one could accomplish the same thing mearly by making one version of the character in the main layer, and adding an invisible object atop the character's head (which is parented to the head bone). Then whenever it becomes desirable, one can replace the invisible object's mesh with the desirable hat's mesh, then make it visible. With my patch, the hat object would then continue to deform to the character's head regardless of which hat was currently being worn. *note 1* for armature/mesh deformations, the new mesh must have properly assigned vertex groups which match one or more of the bones of the target armature before the replaceMesh call is made. Otherwise the vertices won't react to the armature because they won't know how. (not sure if vertices can be scripted to change groups after the game has started) *note 2* The added processing time involved with replacing the object's deform controller is negligible.
2005-04-18 11:44:21 +00:00
#include "KX_HashedPtr.h"
Initial revision
2002-10-12 11:37:38 +00:00
using namespace std;
BGE performance: - Vast performance increase when removing scene containing large number of objects: the sensor/controller map was updated for each deleted object, causing massive slow down when the number of objects was large (O(n^2)). - Use reference when scanning the sensor map => avoid useless copy. - Remove dynamically the object bounding box from the DBVT when the object is invisible => faster culling.
2009-05-01 20:34:23 +00:00
typedef std::list<class SCA_IController*> controllerlist;
typedef std::map<class SCA_ISensor*,controllerlist > sensormap_t;
Initial revision
2002-10-12 11:37:38 +00:00
/**
* This manager handles sensor, controllers and actuators.
* logic executes each frame the following way:
* find triggering sensors
* build list of controllers that are triggered by these triggering sensors
* process all triggered controllers
* during this phase actuators can be added to the active actuator list
* process all active actuators
* clear triggering sensors
* clear triggered controllers
* (actuators may be active during a longer timeframe)
*/
#include "SCA_ILogicBrick.h"
class SCA_LogicManager
{
vector<class SCA_EventManager*> m_eventmanagers;
BGE performance, 4th round: logic This commit extends the technique of dynamic linked list to the logic system to eliminate as much as possible temporaries, map lookup or full scan. The logic engine is now free of memory allocation, which is an important stability factor. The overhead of the logic system is reduced by a factor between 3 and 6 depending on the logic setup. This is the speed-up you can expect on a logic setup using simple bricks. Heavy bricks like python controllers and ray sensors will still take about the same time to execute so the speed up will be less important. The core of the logic engine has been much reworked but the functionality is still the same except for one thing: the priority system on the execution of controllers. The exact same remark applies to actuators but I'll explain for controllers only: Previously, it was possible, with the "executePriority" attribute to set a controller to run before any other controllers in the game. Other than that, the sequential execution of controllers, as defined in Blender was guaranteed by default. With the new system, the sequential execution of controllers is still guaranteed but only within the controllers of one object. the user can no longer set a controller to run before any other controllers in the game. The "executePriority" attribute controls the execution of controllers within one object. The priority is a small number starting from 0 for the first controller and incrementing for each controller. If this missing feature is a must, a special method can be implemented to set a controller to run before all other controllers. Other improvements: - Systematic use of reference in parameter passing to avoid unnecessary data copy - Use pre increment in iterator instead of post increment to avoid temporary allocation - Use const char* instead of STR_String whenever possible to avoid temporary allocation - Fix reference counting bugs (memory leak) - Fix a crash in certain cases of state switching and object deletion - Minor speed up in property sensor - Removal of objects during the game is a lot faster
2009-05-10 20:53:58 +00:00
// SG_DList: Head of objects having activated actuators
// element: SCA_IObject::m_activeActuators
SG_DList m_activeActuators;
// SG_DList: Head of objects having activated controllers
// element: SCA_IObject::m_activeControllers
SG_DList m_triggeredControllerSet;
Initial revision
2002-10-12 11:37:38 +00:00
// need to find better way for this
// also known as FactoryManager...
GEN_Map<STR_HashedString,CValue*> m_mapStringToGameObjects;
GEN_Map<STR_HashedString,void*> m_mapStringToMeshes;
GEN_Map<STR_HashedString,void*> m_mapStringToActions;
Patch: [ #2439 ] Makes objects react properly to deformations after a mesh replacement call. from brian hayward (bthayward) Detailed description: Currently, when an armature deformed object's mesh is replaced by the ReplaceMesh actuator, the new mesh fails to deform to the armature's movement. My patch fixes this by properly replacing the deform controller along with the mesh (when appropriete). For instance, if one had an animated character using any of the standard deformation techniques (armature, ipo, RVK, or AVK), that character's mesh would currently be prevented from changing mid-game. It could be replaced, but the new mesh would lack the controller which tells it how to deform. If one wanted to dynamiclly add a hat on top of the character's head, it would require storing a secondary prebuilt character (mesh, armature, logic, ect...) on another layer FOR EACH HAT the character could possibly wear, then swapping out the whole character when the hat change was desired. So if you had 4 possible hat/character combos, you would have 4 character meshes, 4 armatures, 4 sets of logic, and so on. I find this lack of flexibility to be unresonable. With my patch, one could accomplish the same thing mearly by making one version of the character in the main layer, and adding an invisible object atop the character's head (which is parented to the head bone). Then whenever it becomes desirable, one can replace the invisible object's mesh with the desirable hat's mesh, then make it visible. With my patch, the hat object would then continue to deform to the character's head regardless of which hat was currently being worn. *note 1* for armature/mesh deformations, the new mesh must have properly assigned vertex groups which match one or more of the bones of the target armature before the replaceMesh call is made. Otherwise the vertices won't react to the armature because they won't know how. (not sure if vertices can be scripted to change groups after the game has started) *note 2* The added processing time involved with replacing the object's deform controller is negligible.
2005-04-18 11:44:21 +00:00
GEN_Map<STR_HashedString,void*> m_map_gamemeshname_to_blendobj;
BGE patch: support runtime duplication of groups. Adding an object with Dupligroup option set will cause the group to be instantiated. No special actuator is needed for this feature, just put dupligroup objects in inactive layers and add them dynamically
2008-07-26 11:00:21 +00:00
GEN_Map<CHashedPtr,void*> m_map_blendobj_to_gameobj;
Patch: [ #2439 ] Makes objects react properly to deformations after a mesh replacement call. from brian hayward (bthayward) Detailed description: Currently, when an armature deformed object's mesh is replaced by the ReplaceMesh actuator, the new mesh fails to deform to the armature's movement. My patch fixes this by properly replacing the deform controller along with the mesh (when appropriete). For instance, if one had an animated character using any of the standard deformation techniques (armature, ipo, RVK, or AVK), that character's mesh would currently be prevented from changing mid-game. It could be replaced, but the new mesh would lack the controller which tells it how to deform. If one wanted to dynamiclly add a hat on top of the character's head, it would require storing a secondary prebuilt character (mesh, armature, logic, ect...) on another layer FOR EACH HAT the character could possibly wear, then swapping out the whole character when the hat change was desired. So if you had 4 possible hat/character combos, you would have 4 character meshes, 4 armatures, 4 sets of logic, and so on. I find this lack of flexibility to be unresonable. With my patch, one could accomplish the same thing mearly by making one version of the character in the main layer, and adding an invisible object atop the character's head (which is parented to the head bone). Then whenever it becomes desirable, one can replace the invisible object's mesh with the desirable hat's mesh, then make it visible. With my patch, the hat object would then continue to deform to the character's head regardless of which hat was currently being worn. *note 1* for armature/mesh deformations, the new mesh must have properly assigned vertex groups which match one or more of the bones of the target armature before the replaceMesh call is made. Otherwise the vertices won't react to the armature because they won't know how. (not sure if vertices can be scripted to change groups after the game has started) *note 2* The added processing time involved with replacing the object's deform controller is negligible.
2005-04-18 11:44:21 +00:00
BGE performance, 4th round: logic This commit extends the technique of dynamic linked list to the logic system to eliminate as much as possible temporaries, map lookup or full scan. The logic engine is now free of memory allocation, which is an important stability factor. The overhead of the logic system is reduced by a factor between 3 and 6 depending on the logic setup. This is the speed-up you can expect on a logic setup using simple bricks. Heavy bricks like python controllers and ray sensors will still take about the same time to execute so the speed up will be less important. The core of the logic engine has been much reworked but the functionality is still the same except for one thing: the priority system on the execution of controllers. The exact same remark applies to actuators but I'll explain for controllers only: Previously, it was possible, with the "executePriority" attribute to set a controller to run before any other controllers in the game. Other than that, the sequential execution of controllers, as defined in Blender was guaranteed by default. With the new system, the sequential execution of controllers is still guaranteed but only within the controllers of one object. the user can no longer set a controller to run before any other controllers in the game. The "executePriority" attribute controls the execution of controllers within one object. The priority is a small number starting from 0 for the first controller and incrementing for each controller. If this missing feature is a must, a special method can be implemented to set a controller to run before all other controllers. Other improvements: - Systematic use of reference in parameter passing to avoid unnecessary data copy - Use pre increment in iterator instead of post increment to avoid temporary allocation - Use const char* instead of STR_String whenever possible to avoid temporary allocation - Fix reference counting bugs (memory leak) - Fix a crash in certain cases of state switching and object deletion - Minor speed up in property sensor - Removal of objects during the game is a lot faster
2009-05-10 20:53:58 +00:00
// head of actuators being deactivated during the logic update
SG_DList m_removedActuators;
Initial revision
2002-10-12 11:37:38 +00:00
public:
SCA_LogicManager();
virtual ~SCA_LogicManager();
BGE performance: - Vast performance increase when removing scene containing large number of objects: the sensor/controller map was updated for each deleted object, causing massive slow down when the number of objects was large (O(n^2)). - Use reference when scanning the sensor map => avoid useless copy. - Remove dynamically the object bounding box from the DBVT when the object is invisible => faster culling.
2009-05-01 20:34:23 +00:00
Initial revision
2002-10-12 11:37:38 +00:00
//void SetKeyboardManager(SCA_KeyboardManager* keyboardmgr) { m_keyboardmgr=keyboardmgr;}
void RegisterEventManager(SCA_EventManager* eventmgr);
void RegisterToSensor(SCA_IController* controller,
class SCA_ISensor* sensor);
void RegisterToActuator(SCA_IController* controller,
class SCA_IActuator* actuator);
Switch fixed time system. Logic updates should now happen at 30Hz, physics at 60Hz. (By default, use Python to set.) Some actuators still run at framerate (IPO, Action) for nice smooth animation, and an excuse to buy high end hardware. Keyboard sensors can now hook escape key. Ctrl-Break can be used from within blender if you've forgotten an end game actuator. Fixed a stupid bug preventing some actuators working (like TrackTo).
2004-10-16 11:41:50 +00:00
void BeginFrame(double curtime, double fixedtime);
void UpdateFrame(double curtime, bool frame);
Initial revision
2002-10-12 11:37:38 +00:00
void EndFrame();
BGE performance, 4th round: logic This commit extends the technique of dynamic linked list to the logic system to eliminate as much as possible temporaries, map lookup or full scan. The logic engine is now free of memory allocation, which is an important stability factor. The overhead of the logic system is reduced by a factor between 3 and 6 depending on the logic setup. This is the speed-up you can expect on a logic setup using simple bricks. Heavy bricks like python controllers and ray sensors will still take about the same time to execute so the speed up will be less important. The core of the logic engine has been much reworked but the functionality is still the same except for one thing: the priority system on the execution of controllers. The exact same remark applies to actuators but I'll explain for controllers only: Previously, it was possible, with the "executePriority" attribute to set a controller to run before any other controllers in the game. Other than that, the sequential execution of controllers, as defined in Blender was guaranteed by default. With the new system, the sequential execution of controllers is still guaranteed but only within the controllers of one object. the user can no longer set a controller to run before any other controllers in the game. The "executePriority" attribute controls the execution of controllers within one object. The priority is a small number starting from 0 for the first controller and incrementing for each controller. If this missing feature is a must, a special method can be implemented to set a controller to run before all other controllers. Other improvements: - Systematic use of reference in parameter passing to avoid unnecessary data copy - Use pre increment in iterator instead of post increment to avoid temporary allocation - Use const char* instead of STR_String whenever possible to avoid temporary allocation - Fix reference counting bugs (memory leak) - Fix a crash in certain cases of state switching and object deletion - Minor speed up in property sensor - Removal of objects during the game is a lot faster
2009-05-10 20:53:58 +00:00
void AddActiveActuator(SCA_IActuator* sensor,bool event);
BGE state system improvement: the sensor with Level option enabled will trigger the controller of a newly activated state, even if the sensor is already connected to an active state; new isTriggered() python function to determine which sensor triggered the current controller. Previously, this behaviour was available only for sensors that were not connected to any active state, which was forcing the game designer to duplicate sensors in some cases. For example the Always sensors used to initialize the states needed to be duplicated for each state. With this patch, a single Always sensor with Level option enabled will suffice to initialize all the states. A Python controller can determine which sensor did trigger with the new SCA_ISensor::isTriggered() function. Notes: - When a sensor with level option enabled is connected to multiple controllers, only those of newly activated states will be triggered. The controllers of already activated states will receive no trigger, unless the sensor internal state toggled, in which case all the controllers are triggered as always. - The old isPositive() function returns the internal state of the sensor, positive or negative; the new isTriggered() function returns 1 only for sensors that generated an event in the current frame.
2008-08-23 11:54:27 +00:00
void AddTriggeredController(SCA_IController* controller, SCA_ISensor* sensor);
Initial revision
2002-10-12 11:37:38 +00:00
SCA_EventManager* FindEventManager(int eventmgrtype);
void RemoveGameObject(const STR_String& gameobjname);
/**
* remove Logic Bricks from the running logicmanager
*/
void RemoveSensor(SCA_ISensor* sensor);
void RemoveController(SCA_IController* controller);
BGE performance, 4th round: logic This commit extends the technique of dynamic linked list to the logic system to eliminate as much as possible temporaries, map lookup or full scan. The logic engine is now free of memory allocation, which is an important stability factor. The overhead of the logic system is reduced by a factor between 3 and 6 depending on the logic setup. This is the speed-up you can expect on a logic setup using simple bricks. Heavy bricks like python controllers and ray sensors will still take about the same time to execute so the speed up will be less important. The core of the logic engine has been much reworked but the functionality is still the same except for one thing: the priority system on the execution of controllers. The exact same remark applies to actuators but I'll explain for controllers only: Previously, it was possible, with the "executePriority" attribute to set a controller to run before any other controllers in the game. Other than that, the sequential execution of controllers, as defined in Blender was guaranteed by default. With the new system, the sequential execution of controllers is still guaranteed but only within the controllers of one object. the user can no longer set a controller to run before any other controllers in the game. The "executePriority" attribute controls the execution of controllers within one object. The priority is a small number starting from 0 for the first controller and incrementing for each controller. If this missing feature is a must, a special method can be implemented to set a controller to run before all other controllers. Other improvements: - Systematic use of reference in parameter passing to avoid unnecessary data copy - Use pre increment in iterator instead of post increment to avoid temporary allocation - Use const char* instead of STR_String whenever possible to avoid temporary allocation - Fix reference counting bugs (memory leak) - Fix a crash in certain cases of state switching and object deletion - Minor speed up in property sensor - Removal of objects during the game is a lot faster
2009-05-10 20:53:58 +00:00
void RemoveActuator(SCA_IActuator* actuator);
Initial revision
2002-10-12 11:37:38 +00:00
// for the scripting... needs a FactoryManager later (if we would have time... ;)
void RegisterMeshName(const STR_String& meshname,void* mesh);
void RegisterActionName(const STR_String& actname,void* action);
void* GetActionByName (const STR_String& actname);
void* GetMeshByName(const STR_String& meshname);
void RegisterGameObjectName(const STR_String& gameobjname,CValue* gameobj);
class CValue* GetGameObjectByName(const STR_String& gameobjname);
Patch: [ #2439 ] Makes objects react properly to deformations after a mesh replacement call. from brian hayward (bthayward) Detailed description: Currently, when an armature deformed object's mesh is replaced by the ReplaceMesh actuator, the new mesh fails to deform to the armature's movement. My patch fixes this by properly replacing the deform controller along with the mesh (when appropriete). For instance, if one had an animated character using any of the standard deformation techniques (armature, ipo, RVK, or AVK), that character's mesh would currently be prevented from changing mid-game. It could be replaced, but the new mesh would lack the controller which tells it how to deform. If one wanted to dynamiclly add a hat on top of the character's head, it would require storing a secondary prebuilt character (mesh, armature, logic, ect...) on another layer FOR EACH HAT the character could possibly wear, then swapping out the whole character when the hat change was desired. So if you had 4 possible hat/character combos, you would have 4 character meshes, 4 armatures, 4 sets of logic, and so on. I find this lack of flexibility to be unresonable. With my patch, one could accomplish the same thing mearly by making one version of the character in the main layer, and adding an invisible object atop the character's head (which is parented to the head bone). Then whenever it becomes desirable, one can replace the invisible object's mesh with the desirable hat's mesh, then make it visible. With my patch, the hat object would then continue to deform to the character's head regardless of which hat was currently being worn. *note 1* for armature/mesh deformations, the new mesh must have properly assigned vertex groups which match one or more of the bones of the target armature before the replaceMesh call is made. Otherwise the vertices won't react to the armature because they won't know how. (not sure if vertices can be scripted to change groups after the game has started) *note 2* The added processing time involved with replacing the object's deform controller is negligible.
2005-04-18 11:44:21 +00:00
void RegisterGameMeshName(const STR_String& gamemeshname, void* blendobj);
void* FindBlendObjByGameMeshName(const STR_String& gamemeshname);
BGE patch: support runtime duplication of groups. Adding an object with Dupligroup option set will cause the group to be instantiated. No special actuator is needed for this feature, just put dupligroup objects in inactive layers and add them dynamically
2008-07-26 11:00:21 +00:00
void RegisterGameObj(void* blendobj, CValue* gameobj);
void UnregisterGameObj(void* blendobj, CValue* gameobj);
CValue* FindGameObjByBlendObj(void* blendobj);
Initial revision
2002-10-12 11:37:38 +00:00
};
#endif //__KX_LOGICMANAGER
fixed spacing in the headers to get rid of some warnings and some other little minor spacing issues.
2002-10-30 02:07:20 +00:00
Copy Permalink