The file osg-OpenSceneGraph-3.4.0\include\osg\Types
typedefs int8_t, int16_t, int32_t and int64_t
These are typedefed as signed __intX in several other places.
With VS2008, this causes an error "int8_t redifined, different basic types"
Explicitly declaring them signed fixes the error."
The change I made is to check GL_QUERY_RESULT_AVAILABLE before retrieving the query, to ensure that there won't be a stall. If the query result is not available yet, we'll leave it alone and try again in the next frame.
Had to make a few more changes than I'd liked, mostly because the TestResult mechanism wasn't designed for holding on to query objects for more than one frame. As well, I'm thinking that RetrieveQueriesCallback and ClearQueriesCallback could be merged together, if we wanted to go for more refactoring. For though now my strategy is to make as little changes as possible. Let me know what you think of the patch."
In OSG 3.4, osgText::Text( ::_quadIndices) uses DrawElementsUInt that will fail on these devices and no text will appear - tested on Samsung Galaxy Trend 2 SM-G313HN.
When DrawElementsUInt is replaced with DrawElementsUShort it works, although I'm not sure if this can cause other problems with some fonts.
Fix:
- In include\osgText\Text, line 316:
replace: "osg::ref_ptr< osg::DrawElementsUInt > _quadIndices;"
with: "osg::ref_ptr< osg::DrawElementsUShort > _quadIndices;"
- In src\osgText\Text.cpp, line 2094:
replace: "_quadIndices = new DrawElementsUInt(PrimitiveSet::TRIANGLES);"
with: "_quadIndices = new DrawElementsUShort(PrimitiveSet::TRIANGLES);"
"
Font::getKerning(...), Font::getGlyph3D(...) doesn't ask for a font resolution so it uses the last font resolution requested by Font:: getGlyph(...).
This can leads to different results depending of the precedent call to Font::getGlyph(...).
See http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2016-January/271952.html for more infos.
This fix adds a font resolution parameter to Font::getKerning(...), Font::getGlyph3D(...) and to the font implementations.
This was made under the base revision r15182."
"E:\osg\osgSvnGit\OpenSceneGraph\include\osg/Callback(286): warning C4099: 'osg::DrawableUpdateCallback' : type name first seen using 'class' now seen using 'struct' (E:\osg\osgSvnGit\OpenSceneGraph\src\osgUtil\RenderBin.cpp)
E:\osg\osgSvnGit\OpenSceneGraph\include\osg/Callback(27) : see declaration of 'osg::DrawableUpdateCallback'
attached is a modified version of include/osg/Callback:
changing
- struct OSG_EXPORT DrawableUpdateCallback : public virtual Callback
- {
to
+ class OSG_EXPORT DrawableUpdateCallback : public virtual Callback
+ {
+ public:
and the same changes for DrawableEventCallback and DrawableCullCallback"
Simplfifer::ContinueSimplificationCallback to be able to decide whether up or downsampling is required,
removing the previous hardwards reliance on getSampleRatio<1.0.
forcing users to use osgDB::readRef*File() methods. The later is preferable as it closes a potential threading bug when using paging databases in conjunction
with the osgDB::Registry Object Cache. This threading bug occurs when one thread gets an object from the Cache via an osgDB::read*File() call where only
a pointer to the object is passed back, so taking a reference to the object is delayed till it gets reassigned to a ref_ptr<>, but at the same time another
thread calls a flush of the Object Cache deleting this object as it's referenceCount is now zero. Using osgDB::readREf*File() makes sure the a ref_ptr<> is
passed back and the referenceCount never goes to zero.
To ensure the OSG builds when OSG_PROVIDE_READFILE is to OFF the many cases of osgDB::read*File() usage had to be replaced with a ref_ptr<> osgDB::readRef*File()
usage. The avoid this change causing lots of other client code to be rewritten to handle the use of ref_ptr<> in place of C pointer I introduced a serious of
templte methods in various class to adapt ref_ptr<> to the underly C pointer to be passed to old OSG API's, example of this is found in include/osg/Group:
bool addChild(Node* child); // old method which can only be used with a Node*
tempalte<class T> bool addChild(const osg::ref_ptr<T>& child) { return addChild(child.get()); } // adapter template method
These changes together cover 149 modified files, so it's a large submission. This extent of changes are warrent to make use of the Object Cache
and multi-threaded loaded more robust.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15164 16af8721-9629-0410-8352-f15c8da7e697
This approach unifies much of the code handling the clean up of OpenGL graphics data, avoids lots of local mutexes and static variables that were previously required,
and enables the clean up scheme to be easily extended by users providing their own GraphicsObjectManager subclasses.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15130 16af8721-9629-0410-8352-f15c8da7e697
It should stop and wait for a signal on either of those two. Due to a few logical inversions it boils down to replacing || with &&
OLD _block->set((!_requestList.empty() || !_pager->_databasePagerThreadPaused));
NEW _block->set((!_requestList.empty() && !_pager->_databasePagerThreadPaused));//release the threads to run IF (work_to_be_done && not_paused)
This bug is present since svn rev 8663 (just before 2.6.0 release)
attached is a zip with the files:
OpenSceneGraph\include\osgDB\ImagePager
This file is valid for svn branch and stable 3.2 and 3.4
branches 2.6 - 3.0 have the same bug, but other differences in the file."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15125 16af8721-9629-0410-8352-f15c8da7e697
I used osgSetGLExtensionsFuncPtr to remove the symbols. I don't know how to test this path, but it did remove the symbols from libosgViewer.so. I have also not been able yet to see if that was sufficient for our customer.
I did this by looking at other cases, and I tried to follow some of the same practices in PixelBufferX11, like using _useSGIX in a similar way to the previous _useGLX1_3."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15041 16af8721-9629-0410-8352-f15c8da7e697
