I'm betting you hit the same premultiplied alpha problem/limitation
reported in SDL_image.
http://bugzilla.libsdl.org/show_bug.cgi?id=868
The workaround/solution was to add a block of code at the end of the
loader to un-premultiply the alpha (now in the codebase).
If that is indeed the problem
Hello, just passing through again. I thought I would clarify the
questions being asked about iPhone.
First congrats on the ES support!
One thing you apparently need to be careful of is that Apple is now more
careful in its screening of iPhone apps that are submitted for the App
Store, they
I understand. I just thought calls named _NSGetEnviron and
exc_server (those are the calls they refer to in the article) sounded
like get some environment variable and some threading functions, so I
thought it might be possible that the low-level implementations of some
functions might use
I am not currently on the OSG track so I'm afraid I can't be much help
at the moment. But be aware that in Snow Leopard, the default
architecture is 64-bit (assuming you are on a 64-bit machine which
almost all Intel Macs are now). All the Carbon stuff in
osgViewerCarbon will likely not compile in
I don't know what the specific build issue is as I believe the local
FindFreeType.cmake module should be searched for first, but I thought I
would share some history.
Originally there was no FindFreeType.cmake module in CMake. I wrote the
original one for OpenSceneGraph and then submitted it to
void Text::computePositions()
{
unsigned int size =
osg::maximum(osg::DisplaySettings::instance()-getMaxNumberOfGraphicsCon
texts(),_autoTransformCache.size());
// FIXME: OPTIMIZE: This would be one of the ideal locations to
// call computeAverageGlypthWidthAndHeight(). It is
On 9/4/08, Robert Osfield [EMAIL PROTECTED] wrote:
Hi Filip,
On Thu, Sep 4, 2008 at 11:14 AM, Filip Wänström
[EMAIL PROTECTED] wrote:
Since I tried the CMake route that creates regular .so files and headers
in
/usr/local instead of creating mac os frameworks the template need to be
changed
Can anybody reproduce this problem? I am trying to build the current
OSG in the SVN trunk with the current CVS head of CMake.
GraphicsWindowCarbon.cpp is complaining it can't find certain Mac
system header files which is odd.
Thanks,
Eric
[ 40%] Building CXX object
I figured out the problem. The OSG build system is instructing the
process to also build 64-bit as part of the Universal, and of course
it doesn't work when it gets to osgViewer because there is no 64-bit
Carbon.
-Eric
On 7/19/08, E. Wing [EMAIL PROTECTED] wrote:
Can anybody reproduce
On 5/27/08, Andy Skinner [EMAIL PROTECTED] wrote:
I'll admit to being a little past the limit of my knowledge here ...
We would like to specify the -install_name arg with which we link the shared
libraries. I think it is because we don't want the paths where these things
were built to be in
On 5/6/08, Paul Martz [EMAIL PROTECTED] wrote:
Hi folks -- I'm struggling with building OSG on a new Mac OS X 10.5 system.
I'm using a command-line build, not XCode, so using ccmake and make to
build,
My current roadblock is the FreeType library, with the following error:
ld: cycle in dylib
FYI, I think I came across the OSG_GLU_TESS_CALLBACK_TRIPLEDOT issue
in my testing too. I think the answer is:
In Leopard, you need to flip the value.
In prior to Leopard, the value works as is.
If I recall, the thing is related to some casting which happens to
involve a GLenum. If so, I think
Hi, sorry, I've been really busy with other work (day job) which happens to
have no OSG or CMake at the moment so it has been hard for me to finish fixing
everything up. I have some stuff written, but it is incomplete and am still
trying to get over various CMake bugs which requires me to write
On 3/29/08, Robert Osfield [EMAIL PROTECTED] wrote:
HI Stephan,
On Sat, Mar 29, 2008 at 1:44 PM, Stephan Huber [EMAIL PROTECTED]
wrote:
Does CMake support building frameworks on OS X now? IMHO this was the
missing key feature, stopping us using CMake on OS X.
I don't know the answer to
This package will let you cross compile for 10.4 or 10.5 using the SDK
feature in Xcode 3. This makes it easier to build programs targeting
10.4 or 10.5 without having to remove/replace your regular frameworks
each time.
I've been sitting on this awhile. I've been hoping to clean up the
apparently needs
just that.. Do you want feedback?
Have a good holiday Robert.
Kind regards,
Stephen.
On Jan 30, 2008, at 8:21 AM, E. Wing wrote:
This package will let you cross compile for 10.4 or 10.5 using the SDK
feature in Xcode 3. This makes it easier to build programs targeting
10.4
I installed the 2.2 release, but now I'm looking for the wrappers
(I want to try out osgLua). Are they not included in the OSX install?
/Andreas
Sorry, I don't include the wrappers. I think you might be the first to ask.
I'm actually horribly ignorant on how they work and what you're
I only intend to do the dmg/drag-and-drop release. It's extremely well
documented and even has screencasts now. Somebody else did the
installer but I don't think there are concrete plans to continue it.
Newbies should understand the concepts discussed in the screencasts,
installer or not.
2
make: *** [all] Error 2
[EMAIL PROTECTED]/devEnv/research/APIs/OpenSceneGraph_svn$
biv
On Dec 13, 2007 1:01 AM, Andreas Goebel [EMAIL PROTECTED] wrote:
E. Wing schrieb:
In my opinion, you are best off getting Leopard. Apple will not be
updating OpenGL drivers for Tiger from
. About a month ago (), I
posted a message with the subject Undefined Symbols in OSG on Mac OS X
The OSG binary installer for Mac OS X 10.4 (the 10.4u SDK) *mostly*
worked, but my applications would not compile if I made calls to
osg::Image::readPixels() or osg::StateSet::setMode().
E
Actually, it's partially implemented, but not working as you can see.
If I recall, part of the problem was because OpenThreads and OSG are
merged together, there was an ambiguity problem. (I think I had
progressed as far as getting the OpenThreads and Producer
documentation working if you built
Is there a simpler way to give cmake user defined search paths?
So, telling people about the shiny world of 'ccmake' and begging for
procedures that are _highly_impractical_ on many people's setup is one
thing,
This strikes me as a newbie-like question, not an automation
(advanced) question
There are a bunch of ways to deal with this. You shouldn't modify the
CMakeCache directly. And you really shouldn't need to modify the
CMakeLists.txt.
1) Use the ccmake instead of cmake. It exists for this very reason and
is the easiest, most reliable answer. (I constantly beg people to use
I worked on a plotting system using OpenSceneGraph not too long ago.
Speed was a very important factor for us because we were dealing with
real time data. My experience with GNUplot is that it's not very good
for this type of situation.
OpenGL gave us a lot of power to be able to zoom and
projects, or to the XCode
directory from svn ?
Mihai
E. Wing wrote:
Sorry, the path was going to $(SDKROOT)/usr/X11R6/lib, but I forgot to
account the change to X.org, so the path needed to be
$(SDKROOT)/usr/X11/lib. I updated the Xcode project so both paths are
listed so it should now do
Some things have been updated.
First, a new 10.5 oriented binary package has been uploaded to:
http://www.openscenegraph.org/files/OpenSceneGraph-2.2.0/OpenSceneGraph-2.2.0-10.5SDK.dmg
Hopefully, Robert can add the link to the main downloads page soon.
The description should be:
Mac OS X 10.5
Yeah, Apple screwed up and broke binary compatibility between 10.4 and
10.5 when using OpenGL and C++. I have notes and binaries coming on
this, but the short story is you can't use 10.4 built frameworks
against the 10.5 SDK or you get the linking problems you see. Either
switch to the 10.4u SDK
I haven't had any problems with compiling or using the freetype plugin
in Leopard though I'm still on the final seed before GM. The
libfreetype that ships with Leopard is already Universal 32/64-bit.
The Xcode project works fine for me under 32-bit. (I haven't done
64-bit due to osgViewer's Carbon
I uploaded the OS X binary last week, but I have been unable to change
the downloads page to reflect it. Even with the password Jose setup
for me, I am not given the edit button for the downloads page.
The binary is located here:
I have a Mac binary package ready to go. Where/how should I upload it?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Should just work presuming no endian bugs in the underlying code.
On 9/17/07, Eric Sokolowsky [EMAIL PROTECTED] wrote:
I plan to create an OSG 1.2 based application on Mac OSX which is a
universal binary. Are there any issues that I need to be aware of
regarding the osgPlugins? If I use the
I think delete access may be restricted beyond the default osg login.
I couldn't find a delete link. However, if you upload a file, you get a
checkbox to replace a file if it already exists. I tried enabling that, but
my upload failed saying that the account didn't have the delete privalege.
D'oh. Are the files lost, or are the links just broken?
Thanks,
Eric
On 8/22/07, Paul Martz [EMAIL PROTECTED] wrote:
Eric Wing has put a few very informative videos on the OSG wiki
regarding installing/using OSG on a Mac:
Can't say much about Leopard due to the NDA. But there has been public
traffic about Carbon and 64-bit. The summary is that there will be no
64-bit path for Carbon. That means GraphicsWindowCarbon will not work
and a Cocoa version of GraphicsWindow is the way to go for 64-bit.
(I've warned people
34 matches
Mail list logo
