[osg-users] OpenGL ES-2.0, OpenGL ES-1.1 and OpenGL 3.x support now ready for testing :-)
robert.osfield at gmail.com
Sat Nov 21 08:11:59 PST 2009
Good to hear for you again, and thanks to really useful insight to the
state of play under iPhone.
Using SDL as a stop gap for getting the OSG up and running under OSX
seems sensible. One could just comment out the compile of the Cocoa
and Carbon components of osgViewer and just leave it as a naked viewer
lib, and the compile the osgviewerSDL example.
On Fri, Nov 20, 2009 at 8:23 PM, E. Wing <ewmailing at gmail.com> wrote:
> 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 apparently got bitten by some apps harvesting phone numbers
>>> such... I don't know personally, but I read it here:
>>> Seems some of the calls they rejected apps for seems to be an equivalent
>>> getenv(), which OSG uses, so it might be interesting to check the actual
>>> approval rules and see if we can disable things that would cause apps to
>>> rejected with an iphone-specific define in CMake or something.
> According to the article, they admittedly used private APIs which is
> explicitly forbidden in Apple's license terms. I don't believe getenv
> or any ANSI C function is considered private. Private stuff is usually
> proprietary Apple APIs hidden away and undocumented which you have to
> go out of your way to use. I can't imagine OSG would hit any of these
> either by accident or on purpose.
> osgDB and static linking:
> Yes, iPhone license terms forbid dynamic linking and dynamic loading.
> Pain in the arse. However, I thought we already had a static linking
> option in the build options, primarily used by Windows users to make
> distribution easier. I would suggest trying that option to see if that
> works around the issue.
> Officially, I don't think there is CMake support for iPhone yet.
> However, the rumor mill has it that some large project may already
> have it working. It might have been Orge3D.
>>>BTW, on the iPhone what is the scheme for creating windows and
>>>graphics contexts? Is Cocoa based? Would it be possible to use any
>>>of the existing osgViewer support for OSX?
>> Yes IPhone uses cocoa and Objective C which at the momnet I rather suck at (jump to
>> c++ at first chance). It does use views and windows although at the mo my window is
>> created in the interface editor. I think the cocoa viewer should be a pretty good start point
>> for an iphoneViewer.
> iPhone also uses Cocoa, though the class View hierarchy on iPhone is
> different than on the desktop so there will need to be a new viewer
> implementation. The most similar APIs are Core Animation/CALayer which
> have very few differences, but I don't think the OSG viewer uses Core
> Animation. But the desktop OpenGL and ES versions of CALayer do have a
> few differences so there would have to be some #defines. And you would
> still need to encapsulate the layers in a view class which is where
> most of the differences really reside. (e.g. mouse input vs
> multi-touch, etc.)
> The code flow and design patterns should be almost mirrors of each other though.
> One other caveat though. The ImageIO backend I wrote for Mac does not
> work on iPhone because ImageIO wasn't ported to the iPhone, so you
> will likely want a UIImage backend. I implemented one for SDL_image
> which was derived from an ImageIO one I wrote for SDL_image, which was
> ultimately derived from the one I wrote for OSG.
> So you might look at SDL for inspiration for both the view and image
> loader in addition to the existing osg Cocoa viewer. (You might also
> experiment with just using the SDL/OSG viewer since SDL already has
> preliminary iPhone support.)
> osg-users mailing list
> osg-users at lists.openscenegraph.org
More information about the osg-users