Support IPhone Build

[GoogleCodeExporter]

Apply iphone build patch to Gamekit(r513)

1. download & unzip iphone_patch.zip to ./src directory
2. open a console terminal

$cd ./src
$svn co http://gamekit.googlecode.com/svn/trunk/ . -r 513
$patch -p0 -i ./r513_iphone_build.diff

3. run cmake-gui (>= 2.8.0)

setup source directory(./src) & build directory(./build)
click 'configure' button
check on OGREKIT_BUILD_IPHONE
check off OGREKIT_BUILD_GLRS
click 'configure' button few times until 'generate' button is enabled.
click 'generate' button

4. now you need to fix library link path in the xcodeproj file.
go to the console terminal

$cd ../build #your build directory
$./fix_linker_paths.sh 

5. open OGREKIT.xcodeproj in ./build diretory 
start build

tested on:
 mac os x: 10.6.4
 cmake: 2.8.0
 xcode 3.2.3
 iphone4 simulator

Original issue reported on code.google.com by harkon...@gmail.com on 21 Aug 2010 at 12:44

Attachments:

• iphone_patch.zip
• gamekit_iphonedemo.png

[GoogleCodeExporter]

Removed unnecessary .svn folder in iphonedemo.

A osx build issue is fixed, you don't need to changed project architectures 
option to 32-bit universal.

Original comment by harkon...@gmail.com on 21 Aug 2010 at 10:22

Attachments:

• iphone_patch.zip

[GoogleCodeExporter]

Great work. I have do not have the necessary software to test is (Does it 
compile on other os than osx?) But I will try to check it. 

Just a few remarks after a quick overlook at the patch:
-Some files are patched just for identing changes.
-I guess splitting the main loop like you did is something that would be needed 
soon or later but I would have prefered other naming for the function (maybe 
like step or stepOneFrame). Also GK have some base class for things like this. 

Also I will let Charlie and/or Erwin take the responsibility of committing this 
to trunk.

Original comment by xavier.thomas.1980@gmail.com on 21 Aug 2010 at 2:31

[GoogleCodeExporter]

Thanks, It is only working for OS X 10.5 higher intel cpu mac.

>Some files are patched just for identing changes.
In patch, A few blank lines is inserted to some sources &  

Samples/Runtime/Main.cpp modification is nothing. 
First I changed the runtime/main.cpp to iphone support,
Later this source is splited to iphonedemo/main.cpp.

Just ignore that.

> I would have prefered other naming for the function
Sure, no problems. I think also step or stepOneFrame is better choice.

Original comment by harkon...@gmail.com on 21 Aug 2010 at 3:18

[GoogleCodeExporter]

My local copy is way past 513 - is it at all possible to update this patch for 
the current version. At that point, I can test this against the iPhone 3G, 
iPhone 3GS, and iPad (haven't yet got an iPhone4).

Original comment by BenT.Sol...@gmail.com on 22 Aug 2010 at 3:37

[GoogleCodeExporter]

This patch is applied to last trunk r527 &
plugin_cg build error is fixed on os x. (error: can't found config.h)

Original comment by harkon...@gmail.com on 22 Aug 2010 at 6:24

Attachments:

• iphone_build_r527.diff

[GoogleCodeExporter]

OK, the build is not working - failing to link the application. Looking for 
libraries in the "Debug-iphonesimulator" directory when CMake/XCode seem only 
to have created a "Debug" directory. Does this require running the sed script 
on other xproj files?

Original comment by BenT.Sol...@gmail.com on 22 Aug 2010 at 11:13

[GoogleCodeExporter]

If your XCode create Debug directory, not Debug-iphonesimulator, 
maybe you create OS X project, not iphone project.

OS X project don't need to run fix_linker_paths.sh script.

Original comment by harkon...@gmail.com on 22 Aug 2010 at 12:14

[GoogleCodeExporter]

It shows up in Xcode as an iPhone project, i.e. it has a simulator/device 
listed in the combo and the active executable shows "iPhone Simulator 4.0" 
beside ii.

Looking at the xproj file in a text editor shows that the 
CONFIGURATION_BUILD_DIR for the Debug configs ends in "/Debug;". I'm not a sed 
expert but the lines in "edit_linker_path.sed" seem to only replace lines that 
end in a "/" character (i.e. the lines ending in a semi-colon are ignored).

Original comment by BenT.Sol...@gmail.com on 22 Aug 2010 at 1:29

[GoogleCodeExporter]

A quick test shows that while the non-altered directories in Xcode exist as 
described, changing them to the same 
$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME) combination as used in the other sed 
replacement lines causes issues in loading the project file.

This is a project file creation / alteration issue which I don't have enough 
knowledge to solve (never dug into the Xcode project file format before).

Original comment by BenT.Sol...@gmail.com on 22 Aug 2010 at 1:57

[GoogleCodeExporter]

Apparently if all the code is C++ (No Objective-C) Then  it should be possible 
to allow cross compilation for all platforms.

http://www.pjtrix.com/blawg/2009/07/21/iphone-development-on-windows-linux-with-
open-source-tools/

I will try to take a look for Linux cross compilation. For windows however this 
require to build with gcc while AFIAK Gamekit windows build system is MSVC 
based.

Original comment by xavier.thomas.1980@gmail.com on 22 Aug 2010 at 5:34

[GoogleCodeExporter]

Also I am curious regarding the new Apple developer agreement.
Is it already in application?
If so them does an Gamekit based application have any chances of being accepted 
in the Apple store?

This would require:
-Compiling without Scripting support (prohibited by the new dev agreement)
-That Ogre and Gamekit code uses only Apple documented API.

Original comment by xavier.thomas.1980@gmail.com on 22 Aug 2010 at 5:46

[GoogleCodeExporter]

What is your XCode & CMake Version?
Please, post your Xcode Project file before alter by sed.

You should try to other edit_linker_paths.sed from ogre3d origional file.
but, It is not working for me.

http://bitbucket.org/sinbad/ogre/src/tip/SDK/iPhone/edit_linker_paths.sed
--
s/build\/\([a-zA-Z]*\)\/Debug/build\/\1\/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NA
ME)/g
s/build\/\([a-zA-Z]*\)\/Release/build\/\1\/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_
NAME)/g
s/build\/\([a-zA-Z]*\)\/RelWithDebInfo/build\/\1\/Release$(EFFECTIVE_PLATFORM_NA
ME)/g
s/build\/\([a-zA-Z]*\)\/MinSizeRel/build\/\1\/Release$(EFFECTIVE_PLATFORM_NAME)/
g

Original comment by harkon...@gmail.com on 22 Aug 2010 at 5:46

[GoogleCodeExporter]

Apple's strange developer agreement is against some multiplatform framework 
, especially the Adobe Flash.

Unity3D use only c# scripts for developing game, but it  has no problem on 
Apple store, currently.

Original comment by harkon...@gmail.com on 22 Aug 2010 at 6:27

[GoogleCodeExporter]

Harkon - have attached the project file to this reply, please take a look. 
Search for CONFIGURATION_BUILD_DIR and you'll see the problem lines. The sed 
doesn't seem to work for these and manually changing them gives me a load error 
trying to open the project.

Xavier - the developer agreement clause you are talking about is (in practice) 
just something to prevent alternative platforms getting a hold on the iPhone - 
most specifically Flash. When they first brought out the offending addition to 
their dev agreement, the developers went into an uproar - not the least because 
the biggest selling games (including those advertised by Apple themselves in 
their TV & conference videos) use scripting languages - Lua in particular.

In response to this, Apple quietly slipped in a new clause in their last update 
to the agreement allowing the use of interpreted languages so long as they 
aren't a platform API, you don't download new code to run, and you get 
agreement from Apple for it. In other words, they reserve the right to break 
the "no interpreted languages" rule whenever they want to. Kind of proving the 
fact that they were simply ensuring that Flash doesn't get a foothold in the 
iPhone (destroying their control over the nickel & dime games in AppStore).

Original comment by BenT.Sol...@gmail.com on 23 Aug 2010 at 1:02

Attachments:

• project.pbxproj

[GoogleCodeExporter]

@Bent.Solutions

Your Xcode project file's LDFLAGS is saved to one single line.
Maybe, attached sed scripts can't handle this.

   OTHER_LDFLAGS = "-framework Foundation -framework CoreGraphics -framework QuartzCore -framework UIKit -Wl,-search_paths_first -headerpad_max_install_names /Users/btolputt/BenTDev/iPhoneGameKit/Build/Engine/Debug/libOgreKitCore.a ...";

What is your CMake Version? Try, use CMake 2.8.0.
I got a problem with CMake 2.8.1, when I building ogre3d.

--
My Xcode project file's LDFLAGS is saved to multiple lines like this.

OTHER_LDFLAGS = (
                    "-framework",
                    Foundation,
                    "-framework",
                    CoreGraphics,
                    "-framework",
                    QuartzCore,
                    "-framework",
                    UIKit,
                    "-Wl,-search_paths_first",
                    "-headerpad_max_install_names",
                    "/Users/harkon/work/lib/gamekit/src-build-i/Engine/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)/libOgreKitCore.a",

Original comment by harkon...@gmail.com on 23 Aug 2010 at 3:16

[GoogleCodeExporter]

Indeed, I am using using CMake 2.8.1

Am downloading versions 2.8.0 & 2.8.2 to see if I get better results with them.

Original comment by BenT.Sol...@gmail.com on 23 Aug 2010 at 5:09

[GoogleCodeExporter]

OK, have a manual solution which I am sure more capable "sed skilled" people 
can work into an automated solution. The project file generated by 2.8.0 does 
indeed fix one problem, but not another which I will outline. In any event, I 
have a solution for CMake 2.8.2 as well (latest CMake) so we can stay with the 
latest stable build of the tool.

Problem One (CMake 2.8.1+):
--------------------------

There are lines in the generated project file that are as follows - 

CONFIGURATION_BUILD_DIR = /gamekit_src/Build/lib/Debug;

Note two important details. Firstly the Debug section of the line has no 
trailing "/" character (needed for the current sed) and just as importantly, 
that there are no quotes around the path. Changing it to the following (and 
doing the same for Release, MinSizeRel, and RelWithDebInfo equivalents) fixes 
the project:

CONFIGURATION_BUILD_DIR = 
"/gamekit_src/Build/lib/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)/";

The two important points - we now surround the path with quotes and the 
"/Debug/" match needs to be "/Debug;"

Problem Two (all CMake versions)
--------------------------

This involves an extraneous CFLAG/CPPFLAG which makes no sense in when 
developing for iPhone. Trying a device build with the fixed projects crashes 
with a complaint about an invalid parameter "-msse". Obviously this is an 
optimisation for Intel architectures that makes no sense to the ARM based 
iPhone (works on the simulator fine given it is compiled to x86 machine code) .

Replace all instances of the following line with nothing in the project file 
and it works

"-msse",

Original comment by BenT.Sol...@gmail.com on 23 Aug 2010 at 6:45

[GoogleCodeExporter]

Well, fixed aside from some "branch out of range" errors (i.e. code jumps too 
high for ARM chips) that are an optimisation issue rather than a project 
conversion one.

Looking at what I can do to fix that now...

Original comment by BenT.Sol...@gmail.com on 23 Aug 2010 at 7:00

[GoogleCodeExporter]

And the "Disable Thumb Compile" worked to remove the branch errors - so we have 
a fix as soon as someone can sed-ify the manual fixes I mentioned above. 

Original comment by BenT.Sol...@gmail.com on 23 Aug 2010 at 7:26

[GoogleCodeExporter]

It is good to "Disable Thumb Compile" by default, thumb mode seems very slow 
for CPU intensive stuff (such as physics simulation).

It should be fine to get a gamekit App approved, as long as your application 
doesn't executes new scripts downloaded by the user, bypassing Apple approval. 
Just restrict the use of .blend files to the one included by the App. I was 
thinking of creating a free .blend viewer for iPhone/iPad that can download 
.blend files, but without running scripts, only using animation and physics 
simulation. Please don't beat me to this :)

Gamekit is only using public APIs as far as I know, no private APIs. If this is 
really an issue we could look at using Oolong Engine 
(http://oolongengine.googlecode.com) for rendering instead of Ogre.

Original comment by erwin.coumans on 23 Aug 2010 at 8:32

[GoogleCodeExporter]

By the way, it would be nice to have a source code download available that 
includes a working XCode project for iPhone/iPad that "just works" similar to 
the MSVC projectfiles, using relative paths.

In other words, you can use cmake with the relative path option, apply the 
fixes, and upload a source archive in the gamekit downloads section.

Original comment by erwin.coumans on 23 Aug 2010 at 8:36

[GoogleCodeExporter]

a) Not intending to release an application like that Erwin, so go right ahead :)
b) Shouldn't need to worry about using the Oolong Engine. Lua is not a part of 
Ogre but a part of GameKit. Simply commenting out the ability to add/use 
scripts from the blend file would give you the more complete Ogre rendering 
without worrying about the scripting.
c) I'll upload project files, if desired, as soon as the sed scripts are fixed. 
Going through the project files again removing the problems line by line is a 
pain!

Original comment by BenT.Sol...@gmail.com on 23 Aug 2010 at 8:54

[GoogleCodeExporter]

(b) Lua scripting has been accepted by Apple so far (like Unity), as long as 
you don't (allow to) download new scripts to the application afterwards (that 
are not tested by Apple).

See for example the open source SIO engine at sio2interactive dot com. It has 
Lua as a feature and many games have been shipped using SIO/Lua.

Original comment by erwin.coumans on 24 Aug 2010 at 12:09

[GoogleCodeExporter]

That is what I was getting at, erwin :) I make a (partial) living working on 
iPhone applications, so am aware of the offending clause of the Apple iPhone 
Dev Agreement and the exceptions (both legit & deliberately ignored by Apple) 
that exist. Basically, Apple are doing two things with the clause:
1) Stop alternate "platforms" taking a hold on the iPhone (namely Flash)
2) Stop applications "approved" by Apple from doing non-approved behaviour 
(which for Apple is a nebulous & vaguely defined concept).

Basically, being able to open a blend and run it's internal scripts is a major 
block to getting Apple approval of the application. However, so long as the 
scripts IN THE BLEND are never loaded into the interpreter - the app should be 
fine. So you could, for example, have Lua script in the application for 
navigating the blend or similar - just nothing from the blend file itself.

Original comment by BenT.Sol...@gmail.com on 24 Aug 2010 at 12:27

[GoogleCodeExporter]

Executing scripts in a .blend files is fine, as long as that .blend file was 
part of the App install. DOWNLOADING .blend files AND executing scripts is 
forbidden.

OK?

Original comment by erwin.coumans on 24 Aug 2010 at 2:16

[GoogleCodeExporter]

CMake 2.8.2 (maybe also 2.8.1) is don't need to run the 'fix_linker_paths.sh' 
sed script.
Just, generate xcodeproject by CMake & build. That's all.

Original comment by harkon...@gmail.com on 24 Aug 2010 at 5:59

[GoogleCodeExporter]

"Executing scripts in a .blend files is fine, as long as that .blend file was 
part of the App install. DOWNLOADING .blend files AND executing scripts is 
forbidden."

Yes. It is no different really to the other game frameworks in wide usage in 
the AppStore. So long as the script is read-only and "compiled into" the 
application as a resource - it /should/ be fine. I say "should" because 
technically one needs to get Apple's express permission to run an interpreter 
but this is one of those fuzzy clauses they only ever enforce when you make 
waves.

Original comment by BenT.Sol...@gmail.com on 24 Aug 2010 at 11:32

[GoogleCodeExporter]

"CMake 2.8.2 (maybe also 2.8.1) is don't need to run the 'fix_linker_paths.sh' 
sed script.
Just, generate xcodeproject by CMake & build. That's all."

Yes... and no. Yes, it works out of the box, but it makes the mistake of 
keeping everything in the same directories regardless of whether you are 
compiling for the device or simulator (which seems to confuse the compiler 
sometimes). The method the sed scripts used (which happens to be the "default" 
method for projects created BY Xcode), is that it appends the target platform 
after the current config.

So a straight up use of CMake 2.8.2 creates a single "Debug" directory whereas 
a native (or sed-ified CMake) Xcode project will give me 
"Debug-iphonesimulator" and "Debug-iphone" directories so the library outputs 
are not confused.

Original comment by BenT.Sol...@gmail.com on 24 Aug 2010 at 11:51

[GoogleCodeExporter]

I will look at the CMake document to seperate build platform.

Temporary, CMake 2.8.0 higher user can generate two xcodeprojects, one is 
simulator project, the others is device project. (ex, ../build-simulator 
../build-device)

---------

gkSyncObj.cpp bug fixed file is attaced.

class gkSyncObjPrivate
    ~Private()
    {
        m_lock = [[NSLock alloc] init];
    }
-->
    ~Private()
    {
        [m_lock release];
    }

Original comment by harkon...@gmail.com on 26 Aug 2010 at 7:39

Attachments:

• iphone_build_r527_2.diff

[GoogleCodeExporter]

Hi Harkon,

This is great stuff! 

I think we can have an issue with gkSyncObj implementation for IPhone/IPad 
(using NSLock class): Apple documentation for NSLock class says that lock 
message and unlock message shall be called from the same thread. See 
http://developer.apple.com/iphone/library/documentation/Cocoa/Reference/Foundati
on/Classes/NSLock_Class/Reference/Reference.html

The idea behind gkSyncObj is to be called from different threads... 

I am still learning about iOS API but maybe NSConditionLock class will be a 
better candidate for this situation... (what do you think?)

I am really interested in committing this to the main trunk (Hopefully soon I 
will have time to do that...) Can you submit a patch for the current revision 
r544?

Thanks,
Nestor.

Original comment by silveira.nestor@gmail.com on 26 Aug 2010 at 11:20

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thanks, I attached gamekit r552 patch files. but, I can't have enough time for 
testing.

changed:
 NSLock -> NSConditionLock 
 gkEngine : initRun/runOnce/uninitOnce -> initializeStepLoop/stepOneFrame/finalizeStepLoop
 if you use CMake 2.8.1 or higher then CMake don't copy fix_linker_paths.sh to your build directory.
 CMake debug message is removed.

Original comment by harkon...@gmail.com on 27 Aug 2010 at 12:06

Attachments:

• iphone_patch_r552.zip

[GoogleCodeExporter]

Comments on the above patch:
  - Compiles on simulator, still fails on device compile due to "-msse" parameter in Xcode project (see Comment 17 for fix)
  - Runs in simulator, but unlike previous version - no textures are displayed.
  - I cannot recall if the previous version did this or not, but the aspect ratio of the view is off too (forces a start in landscape mode, but shows in portrait width on right hand side of window).

So it is almost there, but not quite done.

Original comment by BenT.Sol...@gmail.com on 27 Aug 2010 at 1:14

[GoogleCodeExporter]

Thanks reporting, BenT.Solutions.

I will check reporting issues, now.

Original comment by harkon...@gmail.com on 27 Aug 2010 at 6:17

[GoogleCodeExporter]

Some issues is fixed.

- ogre3d related libs (ogremain, rendersystem_gles, plugin_particlefx) '-mess' 
compile option is removed when iphone build.
- samples/CMakeLists.txt is fixed. (previous, r552 patch delete lua_runtime 
sample)
- NSConditonLock -> NSRecursiveLock (It seem that don't have limitation like 
NSLock, but I'm not sure.)
- Test blender file is changed to momo_ogre_i.blend (copy from Samples/Runtime)
 : it looks like, touch event handling don't working, correctly. 
- Texture problem is fixed, but aspect ratio has still problem.

Original comment by harkon...@gmail.com on 27 Aug 2010 at 11:06

Attachments:

• iphone_patch_r552_2.zip
• momo_ogre_i.png

[GoogleCodeExporter]

I am not able to fully test this patch, so expect that the changes I've made 
break things.

We can work out of the trunk on getting the issues solved.

I've moved the added include path in 
OgreLite/PlugIns/CgProgramManager/CmakeLists.txt and 
OgreLite/PlugIns/ParticleFX/CmakeLists.txt  to OgreLite/CMakLists.txt.

To prevent accidental overwrites when the Ogre source is updated from time to 
time.

I did not patch the gkSyncObj files, in the chance the most recent update is 
the solution to the potential issue. Instead enabled OGREKIT_USE_COCOA.

I removed hidden .DS_Store files.

I've also disabled support for compiling OpenGLES on any platform except Apple.

For the orientation problem, a define 
OGRE_CONFIG_ENABLE_VIEWPORT_ORIENTATIONMODE
has been enabled in your patch.

This may compile in extra functions into ogre allowing a place to specify the 
default / current orientation. I will investigate further to see what this is 
about.

Thanks for working on this!

Original comment by snailr...@gmail.com on 27 Aug 2010 at 11:46

[GoogleCodeExporter]

Thanks for update the trunk.

I tested build the trunk r555 for iphone(simulator)/mac osx, both working fine.
& r554 gkSycnObj update working well for iphone.

OGRE_CONFIG_ENABLE_VIEWPORT_ORIENTATIONMODE option(on/off) don't affect for 
viewport orientation.
I'm not sure what it is.

--

I uploaded r555 mac osx build, here.

http://cid-89dea03610c07a34.office.live.com/self.aspx/.Public/gamekit/gamekit-r5
55-mac-osx.zip

Original comment by harkon...@gmail.com on 28 Aug 2010 at 2:56

[GoogleCodeExporter]

No problem,

I discovered while investigating the definition that the viewport has a 
setOrientationMode method.

I enabled it here.
http://code.google.com/p/gamekit/source/detail?r=556

If this is to limiting, It can be setup to something like:
activeScene->setViewportOrientation( PROTRAIT , LANDSCAPE, etc )

Right now it's set only once while instancing the scene. 

Original comment by snailr...@gmail.com on 28 Aug 2010 at 10:15

[GoogleCodeExporter]

changed:
 - touch event handling is fixed.
 - view orientation is chanaged. (ogre3d/gamekit viewport orientation  is not match.) 
 - momo can run by touch/mouse event in momo_ogre_i.blend.
 - iphonedemo app is exit when it is suspend by home button.

I upload the iphonedemo capture video, here.
- http://www.youtube.com/watch?v=yihVTst2j3Q

Original comment by harkon...@gmail.com on 29 Aug 2010 at 1:16

Attachments:

• iphone_patch_r565.diff
• IPhoneDemo.zip

[GoogleCodeExporter]

Nice, I've added the patch.

In the video the movement seems choppy / delayed is that due to the video 
capture ?

Original comment by snailr...@gmail.com on 29 Aug 2010 at 1:56

[GoogleCodeExporter]

It's caused by video capturing & camera movemvent, both.

If the camera movement Lua code will be little changed  in momo_ogre_i.blend, 
it seems to be better.

Original comment by harkon...@gmail.com on 29 Aug 2010 at 10:17

[GoogleCodeExporter]

Compiling the latest CMake generated Xcode project for iPhone results in build 
problems all over the place. Something is amiss with the patch as checked in.

Original comment by BenT.Sol...@gmail.com on 30 Aug 2010 at 2:13

[GoogleCodeExporter]

Do you check OGREKIT_USE_COCOA CMake option?

I have no problem to build r568.

Please, Post your error messages.

Original comment by harkon...@gmail.com on 30 Aug 2010 at 4:48

[GoogleCodeExporter]

Ah, the USE_COCOA option was the needed element. Builds and runs fine now (i.e. 
I can rotate the camera around momo, even if he doesn't move or jump yet).

Given the range of options, we're going to need to put together a set of per 
platform build instructions soon.

Original comment by BenT.Sol...@gmail.com on 30 Aug 2010 at 10:03

[GoogleCodeExporter]

More detailed instructions would be good to have.

Initially, If it does not work out of the box then it's an error on our part.
I believe the OGREKIT_USE_COCOA option is an optional feature.

harkon.kr,

Do you think it would beneficial to add a 'gkTouch' class in gkInput.h ?
(It could be bound to Lua and accessed from the blend.)

It seems to me, having a specialized gkTouch device may help some.

Original comment by snailr...@gmail.com on 30 Aug 2010 at 12:43

[GoogleCodeExporter]

OGREKIT_USE_COCOA is an option for OSX but it should be enabled for iOS. 
So far we use Carbon for OSX but we can also use Cocoa. Carbon is not an option 
for iOS.

Original comment by silveira.nestor@gmail.com on 30 Aug 2010 at 1:25

[GoogleCodeExporter]

I agree, enable cocoa by default for OSX and iOS.

Original comment by erwin.coumans on 30 Aug 2010 at 2:03

[GoogleCodeExporter]

Two points;
  - the OGREKIT_BUILD_COCOA is easy to miss (and wasn't required before). I believe we should make it necessary for both iOS & OSX. It doesn't hurt the OSX build but, as shown above, stops the build without an easy answer for someone not involved in the iPhone development.

  - I don't have a problem with the gkTouch being made available (in fact would have hacked one in myself at one point if it wasn't). It should have a comment in the header at very east indicating it is only for touch enabled devices though.

Original comment by BenT.Sol...@gmail.com on 30 Aug 2010 at 9:54

[GoogleCodeExporter]

CMake changed:
 - Force use OGREKIT_USE_COCOA for iphone build

If gkTouch is added, it will be usefull for iphone.

Original comment by harkon...@gmail.com on 30 Aug 2010 at 11:34

Attachments:

• r569_force_use_cocoa_for_iphone.diff

[GoogleCodeExporter]

If one of you would be willing to add gkTouch support, I can get it bound to 
Lua and in the trunk for testing.

It's fine if neither of you have the time, I can eventually get it going.

Original comment by snailr...@gmail.com on 31 Aug 2010 at 11:39