Remove the last of the odd C++/python wrapper code from http://www.python.org/doc/PyCPP.html (~1998)
* Use python subclasses rather then having fake subclassing through get/set attributes calling parent types.
* PyObject getset arrays are created while initializing the types, converted from our own attribute arrays. This way python deals with subclasses and we dont have to define getattro or setattro functions for each type.
* GameObjects and Scenes no longer have attribute access to properties. only dictionary style access - ob['prop']
* remove each class's get/set/dir functions.
* remove isA() methods, can use PyObject_TypeCheck() in C and issubclass() in python.
* remove Parents[] array for each C++ class, was only used for isA() and wasnt correct in quite a few cases.
* remove PyTypeObject that was being passed as the last argument to each class (the parent classes too).
TODO -
* Light and VertexProxy need to be converted to using attributes.
* memory for getset arrays is never freed, not that bad since its will only allocates once.
Note that the animation conversion from existing 2.4x blend files doesnt yet set the Action pointer in the actuator so the only way to test is to use the python api to set the new converted action active on the actuator because there is no user interface.
* extract_pose_from_pose only checked one of the list items for NULL when looping over them yet its possible they are different sizes.
* game_free_pose needed to be used rather then MEM_freeN, channels would never be freed leaking memory.
* setChannel() would make a new pose that wasnt aligned with the existing pose, the lists are assumed aligned so when extracting the channels its unlikely this was ever useful.
* Added getChannel() - returns pose loc/size/quat
* Added option args for setChannel(channel, matrix) or setChannel(channel, loc, size, quat)
svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r19820:HEAD
Notes:
* Game and sequencer RNA, and sequencer header are now out of date
a bit after changes in trunk.
* I didn't know how to port these bugfixes, most likely they are
not needed anymore.
* Fix "duplicate strip" always increase the user count for ipo.
* IPO pinning on sequencer strips was lost during Undo.
use PY_SET_ATTR_FAIL and PY_SET_ATTR_SUCCESS return values so the fake subclassing can know if a value failed to be set or if it was missing from the type. (with PY_SET_ATTR_MISSING)
Also noticed some other mistakes.
- KX_LightObject, setting the type didnt check for an int.
- KX_SoundActuator, didnt return an error when assigning an invalid orientation value
- KX_GameObject, worldOrientation didnt return an error value.
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
PyObjectPlus::ProcessReplica() is now called when any of its subclasses are replicated.
This is important because PyObjectPlus::ProcessReplica() NULL's the 'm_proxy' python pointer I added recently.
Without this a replicated subclass of PyObjectPlus could have an invalid pointer (crashing the BGE).
This change also means CValue::AddDataToReplica() can be moved into CValue::ProcessReplica() since ProcessReplica is always called.
Separate getting a normal attribute and getting __dict__, was having to do too a check for __dict__ on each class (multiple times per getattro call from python) when its not used that often.
- More verbose error messages.
- BL_Shader wasnt setting error messages on some errors
- FilterNormal depth attribute was checking for float which is bad because scripts often expect ints assigned to float attributes.
- Added a check to PyVecTo for a tuple rather then always using a generic python sequence. On my system this is over 2x faster with an optmized build.
- comments to PyObjectPlus.h
- remove unused/commented junk.
- renamed PyDestructor to py_base_dealloc for consistency
- all the PyTypeObject's were still using the sizeof() their class, can use sizeof(PyObjectPlus_Proxy) now which is smaller too.
Use each types dictionary to store attributes PyAttributeDef's so it uses pythons hash lookup (which it was already doing for methods) rather then doing a string lookup on the array each time.
This also means attributes can be found in the type without having to do a dir() on the instance.
- action attribute wasnt checking for NULL (own fault)
- KX_Scene getCamera wasnt checking for NULL
- CListValue had asserts for not yet implimented functionality, this would close blender. Better to print an error if the user manages to run this functions (I managed to by CListValue.count([1,2,3]))
- Initialize python types with PyType_Ready, which adds methods to the type dictionary.
- use Pythons get/setattro (uses a python string for the attribute rather then char*). Using basic C strings seems nice but internally python converts them to python strings and discards them for most functions that accept char arrays.
- Method lookups use the PyTypes dictionary (should be faster then Py_FindMethod)
- Renamed __getattr -> py_base_getattro, _getattr -> py_getattro, __repr -> py_base_repr, py_delattro, py_getattro_self etc.
From here is possible to put all the parent classes methods into each python types dictionary to avoid nested lookups (api has 4 levels of lookups in some places), tested this but its not ready yet.
Simple tests for getting a method within a loop show this to be between 0.5 and 3.2x faster then using Py_FindMethod()
Added the method into the PyType so python knows about the methods (its supposed to work this way).
This means in the future the api can use PyType_Ready() to store the methods in the types dictionary.
Python3 removes Py_FindMethod and we should not be using it anyway since its not that efficient.
Notes:
* Sequence transform strip uses G.scene global, this is commented
out now, should be fixed.
* Etch-a-ton code was most difficult to merge. The files already in
2.5 got merged, but no new files were added. Calls to these files
are commented out with "XXX etch-a-ton". editarmature.c and
transform_snap.c were complex to merge. Martin, please check?
* Game engine compiles and links again here for scons/make/cmake
(player still fails to link).
Use 'const char *' rather then the C++ 'STR_String' type for the attribute identifier of python attributes.
Each attribute and method access from python was allocating and freeing the string.
A simple test with getting an attribute a loop shows this speeds up attribute lookups a bit over 2x.
but don't have an action got the pose of already added armatures, even
though they're not related. This also fixes an issue where the armature
in Blender would end up in the pose from the game after ESC, removes
unneeded copies made during armature evaluation, and also solves the
constraint copying hack.
I'm getting this error now:
GPG_Application.cpp: In member function 'void GPG_Application::stopEngine()':
/System/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/marshal.h:12: error: too many arguments to function 'PyObject* PyMarshal_WriteObjectToString(PyObject*)'
GPG_Application.cpp:720: error: at this point in file
Are we offically not supporint older versions of python now? :)
Kent
* removed macros that were not used much, some misleading.
* removed error string setting calls that overwrote the error set by PyArg_ParseTuple with a less useful one.
* use python macros Py_RETURN_NONE, Py_RETURN_TRUE, Py_RETURN_FALSE
When using states, an action like kick or throw can often switch out before finishing playing the action, and there was no way to play from the start frame the second time round. (even setting the actions current frame through python doesn't work work)
This meant an error in a script could be reported in a different line or script file which makes it quite hard to trace the problem. There were also places where invalid pointers could be used because of this.
The whole game engine pyapi probably needs to have these checks added.
* Action FrameProp was checking if the string was true, not that it contained any text.
* Added GameObject.getVisible() since there is already a getVisible
* Added GameObject.getPropertyNames() Needed in apricot so Franky can collect and throw items in the level without having the names defined elsewhere or modifying his game logic which is stored in a separate blend file.
