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.
