to make is easier to write code that can work on DrawElementUByte, UShort or UInt.
Changed the osgTerrain::GeometryTechnique so that it automatically chooses
the use of DrawElementUShort or DrawElementsUInt accordining to the size of the tile.
/Users/uli/Projects/osg/OpenSceneGraph/src/osgPlugins/ffmpeg/FFmpegDecoderVideo.cpp: In member function \u2018int osgFFmpeg::FFmpegDecoderVideo::convert(AVPicture*, int, AVPicture*, int, int, int)\u2019:
/Users/uli/Projects/osg/OpenSceneGraph/src/osgPlugins/ffmpeg/FFmpegDecoderVideo.cpp:245: error: invalid conversion from \u2018int\u2019 to \u2018PixelFormat\u2019
/Users/uli/Projects/osg/OpenSceneGraph/src/osgPlugins/ffmpeg/FFmpegDecoderVideo.cpp:245: error: initializing argument 3 of \u2018SwsContext* sws_getContext(int, int, PixelFormat, int, int, PixelFormat, int, SwsFilter*, SwsFilter*, double*)\u2019
It expects 'src_pix_fmt' and 'dst_pix_fmt' to be of type 'PixelFormat' rather than int. The attached cast fixes this (for me).
I've also added Matroska video to the list of supported extensions"
Please look at the .diff files for details. I have already enjoyed the latest Chinese *big* movie "Red Cliff" with the fixed ffmpeg plugin and osgmovie. :D"
the condition around a #pragma warning that is specific to visual
studio as _WIN32 is also defined for mingw compile but the #pragma is
not applicable there."
order, and not in the order they are listed in the constructor. To
avoid possible trouble, gcc warns about this. Attached modification
fixes the initializer order to silence this warning."
Also, there was also a small bug in osgDB's CMakeLists.txt that was causing an error when I tested with CMake 2.4.4.
IF(${OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX} STREQUAL "quicktime")
was changed to
IF(OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX STREQUAL "quicktime")
"
Very simple cases of state configuration are supported (all the ones I really need):
- single per pixel not attenuated non spot light source ON/OFF
- exp2 fog ON/OFF
- diffuse texture in rgb + optional specular gloss in alpha (Texture unit 0) ON/OFF
- normal map texture (Texture unit 1 and Tangent in VertexAttribArray 6) ON/OFF
- blending and alpha testing (not in shader pipeline)
To view fixed function pipeline files and paged databases simply run >osgshadergen myfile.osg"
the filename extension is "vert" or "frag" but still lets this be
overridden by the Options (for those crazy people who store their
fragment shaders in .vert files :) )."
ADD_LIBRARY(${TARGET_TARGETNAME} MODULE ${TARGET_SRC} ${TARGET_H})
which gives them .so extensions. Since ".so" != ".dylib" osgDB::listAllAvailablePlugins finds no plug-ins. I believe the correct solution is to use CMAKE_SHARED_MODULE_SUFFIX instead. This builds and runs correctly on OS X but I have not tested on other platforms.
Attached is an updated src/osgDB/CMakeLists.txt based on rev 9915. The change is at line 108. To validate: build and then run bin/osgconv --formats. You should get many screenfuls of plug-in features, extensions and options."
In my example case, there are 2 threads - one is a worker thread created by OpenThreads::Thread. The other thread is the main thread i.e. the thread that is intrinsically created when you execute the application. The crucial problem is that for the main thread, OpenThreads::Thread::CurrentThread() will return null.
I'll demonstrate this by breaking ReentrantMutex::lock() into sub-statements:
1.) if (_threadHoldingMutex==OpenThreads::Thread::CurrentThread())
2.) if (_lockCount>0){
3.)
OpenThreads::ScopedLock<OpenThreads::Mutex> lock(_lockCountMutex);
++_lockCount;
return 0;
4.)
int result = Mutex::lock();
if (result==0)
{
OpenThreads::ScopedLock<OpenThreads::Mutex> lock(_lockCountMutex);
5.)
_threadHoldingMutex = OpenThreads::Thread::CurrentThread();
_lockCount = 1;
return result;
An error will occur in the following case:
1) The worker thread calls lock(), it gets to the start of statement 5.
2) The main thread calls lock(). Statement 1 is evaluated as true as _threadHoldingMutex is null, and OpenThreads::Thread::CurrentThread() returns null.
3) The worker thread executes statement 5.
4) The main thread executes statement 2 and evaluates it as true, because the worker thread has set _lockCount to 1. The main thread executes statement 3, and now can access the mutexed-data at the same time as the worker thread!
The simple solution to this is to always protect access to _lockCount and _threadHoldingMutex using _lockCountMutex. I have done this in the file I am submitting."
