Parenting a BulletVehicle's wheels to the chassis-BulletRigidBodyNode now works as expected. Previously doing this would make the wheels appear to be positioned one frame ahead of the chassis, because the wheel's position were synced before the chassis' position.
For more information see issue #250.
Closes#349
Bullet automatically interpolate most bodies for us (for example the "chassis"
of a BulletVehicle), but BulletVehicle-wheels must be manually interpolated by
calling 'updateWheelTransform()'. Otherwise they will slowly rubber-band
between their intended position and a position one frame ahead in time.
For more information see issue #250.
This problem occurs when movePointer is used to reset the mouse back to the center every frame, a very common way to implement mouselook on Windows (which has no relative mouse mode). Any movement between the last event loop run and the call to movePointer is destroyed, resulting in quite choppy mouselook in most implementations.
The solution is for getPointer to always return the latest mouse cursor position. This goes a long way but is not 100% perfect; see the discussion in #359 for other solutions.
Fixes#359
I think there was some confusion about how set_aux_rgba (and friends) worked; it seems the original intent was to toggle each individual buffer whereas it is actually interpreted as a count of how many of these buffers should be enabled. We should try to clarify the API and/or replace it with something better as soon as possible.
They export no code, and are really only used to contain several
preprocessor macros relevant to their respective packages. On
Windows, they're a problem: MSVC doesn't generate a .lib when
compiling a .dll that exports nothing.
The assert is being triggered because the window is already being removed in open_windows. It does not really matter if it returns false anyway, as long as the window is removed one way or another.
This is useful because these types are created at static init time, and giving them a constexpr constructor and trivial destructor lets them be created during constant initialization, which helps to prevent static init ordering issues.
This was a regression in 0bb81a43c9 which was not keeping an edge case in mind if a weak pointer is locked during object destruction. This issue was fixed by 525a05ea2b1d00a1db901f883f1755943aeff33c, but that is not enough since it causes CharacterJointEffect::get_character() to return null now, so we need a separate method to check if a CharacterJointEffect belongs to a given character. This is more efficient, too.
Fixes#330
This came up in #330; the Character destructor caused something to call lock() on a weak pointer to that character, which would induce a ref() and unref() pair, but since the refcount was 0, this would call the destructor and thereby create infinite recursion.
I considered instead calling mark_deleted() inside unref() so that the callbacks get to run before the object is actually deleted, and was_deleted() will become true as soon as unref() reaches 0. However, this would require grabbing the lock in unref() to be fully thread-safe, since we would need to bring the refcount to 0 and mark the object as deleted in one atomic operation, so this would be an unacceptable general performance penalty.
Instead, WeakPointerTo::lock() now atomically increments the reference count if it is not already zero, and returns null otherwise. This should be safe because the object cannot be deleted while the WeakReferenceList lock is held.
Newer versions of FFmpeg deprecate returning 0 to indicate
EOF, and instead request use of AVERROR_EOF.
The oldest supported versions of FFmpeg/libav will treat any
error code the same as returning 0.
Fixes#315
This comes up when building with DEBUG_THREADS; there is a PipelineCycler created at static init time, and the type tracking in Pipeline won't work properly if the CData's parent's TypeHandle has not yet been initialized.
There is a bug in clang versions before 3.2 (including the one shipped with Xcode) that makes it give a "conflicting types" compile error when there is a static constexpr function defined outside the class. The way to work around this is either to remove one of the "static" or "constexpr" keywords, or to simply put the definition inline.
See: https://stackoverflow.com/a/17494592/2135754
I would try and upgrade Xcode to version 5 to see if the problem is fixed, but the buildbot still runs OS X Lion (10.7) and the last version of Xcode that works on Lion is 4.6.3, so it seems easier to just apply these workarounds for now.
This renames acquire/release to lock/unlock in order to be compatible with std::lock_guard and std::unique_lock (which will eventually replace the *MutexHolder classes). It will also allow us to typedef MutexImpl to std::mutex later on.
To access a WeakPointerTo in a thread-safe way, use something like this:
if (auto ptr = weak_ptr.lock()) {
..use ptr as regular PointerTo
}
The new implementation no longer needs a reference to be stored to all weak pointers on the WeakReferenceList; a mere count of weak pointers is sufficient. Therefore, callbacks theoretically no longer require a WeakPointerTo to be constructed.
The WeakPointerTo class is not actually atomic; it could be made so, but I don't believe it's worth it at this time.
We don't guarantee a specific order in this case, especially because they can be run in either order if there is more than one thread, but it is still useful to have a defined order for single-threaded task chains. To that end, tasks
are now run in the order in which they were added to taskMgr.add (in absence of any other ordering constraints).
Fixes#309
- Release the global lock during the user tick callback
and allow interactions with bullet world
- Acquire the lock again after the callback
Signed-off-by: deflected <deflected@users.noreply.github.com>
Instead of wrapping the whole subdirectory's CMakeLists in
a gigantic if block, we use if(NOT HAVE_FOO) + return()
This is tidier since it keeps the indentation generally consistent
across all CMakeLists files.
This commit isn't technically quite right, since Interrogate should
use the definitions from COMPILE_DEFINITIONS but the module should
be built with INTERFACE_COMPILE_DEFINITIONS, but whatever. That can
be changed if it becomes a nuisance later on.
The rationale here is it's consistent with how CMake treats these
two properties.
This changes the target_link_libraries() declarations so they only
go directly to a component library if it's in the same metalib.
If it's outside of the metalib, the correct thing to do is link against
the metalib. CMake takes care of the transitive linking for us, so
there isn't actually any big change here.
This distinction allows us to better support Python 3, since it will raise exceptions when trying to put arbitrary binary data in a str object.
This also adds some convenience functions for efficiently initializing a Datagram or PTA_uchar from a vector_uchar.
We need to support this because Ubuntu 14.04 ships with this
version, and has no "backports" option to bring in a newer version
(without use of a PPA or compiling it yourself).
We can consider raising the minimums again once Trusty is EOL.
Previously this would close and reopen the codec context;
that's entirely unnecessary, as all supported versions of
libavcodec support flushing the buffers instead.
This leverages libavcodec >= 57.37.100's new asynchronous API,
which both allows decoding in hardware and in a separate thread,
and in any case would free up more CPU time for Panda's app loop.
This also avoids use of the now-deprecated `avcodec_decode_audio4`
AVStream.codec is deprecated as of libavformat version 57.41.100,
so if this version is detected, we switch to AVStream.codecpar instead.
Note this also makes it necessary to construct and use our own codec
context - but doing that is a cleaner approach anyway.
lavcodec: 54.86.100
lavformat: 54.59.106
lavutil: 52.13.100
These are the versions included in FFmpeg 1.1, which is the oldest
release that works with Panda already: we've been using
`av_opt_set_sample_fmt` (introduced in FFmpeg 1.1) since
03e96d8c4a (August 2013) and nobody has
complained since. In other words, I'm not dropping support for anything
here, I'm just making the supported versions explicit.
It would seem that interpretKeyEvents/insertText would be the right way to do this, but while that does handle AltGr keys correctly, it does not handle dead keys at all. This approach seems to do the right things.
This can happen when a system event (eg. on macOS) triggers a terminate from within process_events.
This is a workaround for a common error; the proper fix is not to put PandaFramework in the global scope.
This is designed to sanity-check the buildsystem, ensuring that the
expected BUILDING_ macros are defined at the expected time. It
also helps catch cases where the wrong BUILDING_/EXPCL_ macros
are used.
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
rdb
David Carlsson
Sam Edwards
Younguk Kim
Donny Lawrence
deflected
Sebastian Hoffmann