[osg-users] OpenGL ES-2.0, OpenGL ES-1.1 and OpenGL 3.x support now ready for testing :-)

E. Wing ewmailing at gmail.com
Fri Nov 20 12:23:51 PST 2009


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
>> and
>> such... I don't know personally, but I read it here:
>>
>> http://www.develop-online.net/news/33266/Unity-iPhone-games-rejected-by-Apple
>> http://forum.unity3d.com/viewtopic.php?t=35744
>>
>> Seems some of the calls they rejected apps for seems to be an equivalent
>> of
>> 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
>> be
>> 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.


CMake:
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.)

-Eric


More information about the osg-users mailing list