This reverses the relationship between EXPCL_PANDA_COMPONENT
and BUILDING_PANDA, where BUILDING_PANDA is just shorthand for
BUILDING_PANDA_COMPONENT and BUILDING_PANDA_COMPONENT itself
sets the EXPCL_PANDA_COMPONENT defines.
Also removes EXPCL_PANDA.
- When a bullet world is created it sets the filter
algorithm callback that will use. Later changes to
PRC config data should not lead to false assumptions
that the bullet world is working with the new config.
Signed-off-by: deflected <deflected@users.noreply.github.com>
Closes#289
- Return vector_uchar from readSubfile instead of
string. This will correct problems with Python 3 unicode
strings and will return bytes instead.
Signed-off-by: deflected <deflected@users.noreply.github.com>
Closes#290
The GCC documentation states that, as of GCC 2.7.2, these aren't
necessary for proper program behavior. The documentation further
discourages their use because they don't suppress unnecessary code
duplication.
The Panda codebase these days uses "extern template class" instead,
which tells the compiler not to perform implicit template expansion
because an explicit template expansion is available for linking
elsewhere in the program. This is a more compiler-neutral way of
achieving the same thing as '#pragma interface', making
'#pragma interface' not only redundant, it could also mask problems
in the "extern template class" machinery.
As of f69354d9fa603ac05dfd924af3844f749fd50cdd, this is just always
expected on all platforms. If it's not defined,
TemplateClass<X>::_type_handle won't link correctly with some compilers
(e.g. Clang) and the lack of 'extern template class' will result in
duplicated code in any case. In short, turning it off causes problems.
makepanda also always turns this on, so it doesn't represent any
optional feature or autodetected platform-specific behavior anyway.
It can be launched from the termux shell using the provided run_python.sh script, which can communicate with the Panda activity using a socket (which is the only way we can reliably get command-line output back to the program.)
The Python script needs to be readable by the Panda activity (which implies it needs to be in /sdcard).
The standard library is packed into the .apk, and loaded using zipimport. Extension modules are included using a special naming convention and import hook in order to comply with Android's strict demands on how libraries must be named to be included in an .apk.
[skip ci]
This can be done by setting the extra string org.panda3d.OUTPUT_URI to tcp://host:port
Writing to a log file can still be done using file:///path/to/log.txt
[skip ci]
The rationale is that CharacterJoint should contain all of the joint
state information, and JointVertexTransform should be pretty much devoid
of state so that we don't have to worry about synchronizing it.
JointVertexTransform::_matrix was just a cached/precomputed matrix
that transforms from original vertex positions to animated vertex
positions, so moving it to CharacterJoint doesn't change any engine
functionality.
This also removes the useless lock on recomputing that matrix. It was
useless because it was computing from shared state in CharacterJoint
that wasn't properly synchronized, but this would have to be fixed by
making CharacterJoint pipeline-cycled - a lock won't do.
Without this, the audio might encounter an error, call cleanup()
on itself, and (if in the middle of update()) try to dereference
its recently cleaned-up _sd pointer.
Fixes#230
The rationale for this change is Apple's OpenAL implementation,
which needs a little time after the
`alSourcei(source, AL_BUFFER, 0);`
call before any buffers used by that source are free for deletion.
The defaults in the config variables are such that the OpenAL manager
will attempt to delete a buffer up to 6 times (that is, the original
attempt plus 5 reattempts), with delays of 1ms, 2ms, 4ms, 8ms, and 16ms
before each reattempt - which means it'll wait a grand total of 31ms for
a buffer to be free before assuming that some even greater problem must
be happening and giving up.
This happened when a M_dual transparent object is given the
M_filled_wireframe render attrib. M_dual would copy the transparent
parts of the object to the transparent back-to-front bin, before
the M_filled_wireframe handler could deal with the M_filled_wireframe
flag.
The solution is just to switch the order - let M_filled_wireframe be
dealt with before the transparency code gets a chance to make a copy.
What's being addressed here is the circumstance where an ancestor of
a PlaneNode has a ClipPlaneAttrib that references said PlaneNode.
The code here is just being copied out of LightAttrib, which has the
exact same mode of operation (it nominates a sorted list of on/off
NodePaths) and a compatible structure. LightAttrib has had this problem
in the past, so using the same solution makes sense.
