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.
- Fixed deadlock when loading ghost nodes from collision solids and
have non-identity scale applied.
Signed-off-by: deflected <deflected@users.noreply.github.com>
This new loop is better in two ways:
1) It reads straight into the Datagram's internal buffer,
saving the trouble of allocating an intermediate buffer
and wasting CPU time to copy out of it.
2) It's more cautious in the face of large (>4MB) lengths,
which are more likely to be due to corruption than the
datagram *actually* being that large.
It was an incomplete experiment for distributing rendering pipelines over
a LAN of computers all working in concert.
Who knows, it may return someday. Until then, it's best not to keep it
around.
This just starts with PandaNode, and uses DCAST_INTO_R instead of DCAST
to catch bad bams. BamWriter should never produce bam output that will
trigger this; I found this with a fuzzer.
I'm unsure about the tradeoff between bam loading performance and
robustness in the face of bad bams. It certainly makes a lot of sense
in debug builds, but we might want to consider a compile flag that
forces bam-related asserts always on even in release builds.
Found this by fuzzing; not concerned about updating the writer as
the writer itself should never do this. This is just to protect
against segfaults in the face of corrupt or malicious bams.
This should also be a slight performance boost since breaking out
of the loop upon discovering an incomplete child object means we don't
bother resolving everything else just to discard it all.
Also don't register them in _all_sounds, where they won't remove themselves
due to having already called cleanup() on themselves.
Additionally stops a sound in a cleaned-up state from being passed to the
app and played.
This has been due for a while. The last FFTW 2.x release was in 1999.
Note that this does change some of the loops; this has two benefits:
1) The halfcomplex storage order is now explained with a comment.
2) It fixed the special case "don't break a run of bytes for a zero" which
was never triggering due to the value not being *exactly* 0.0.
I have tested these changes against older FFT-compressed animation .bams
and no noticeable decompression changes are present, so a .bam version
bump is not necessary.
Sam Edwards
rdb
deflected