Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Ozden79

#16
I've recently updated one of our games which I compiled against 4.0 but set the deploy target to 3.0. It got reviewed and accepted.

You don't need to support the features of IOS4 but your deployment target cannot be below 3.0 which is a rejection reason.
#18
For example, you use LOADSPRITE to load an image to an index you selected from a file. To free it, just use LOADSPRITE "",MyIndex...

That mechanic works for other items as well...
#19
Alright, figured it out, valid architectures were bıth v6 and v7 so removing v7 did the trick.

Thanks for the tip trucidare  :)

Özden
#20
OpenFeint version is 2.4.5 and I tried with 2.4.10 as well which is the same. Architecture is selected as Armv6 already and the other option is Armv7.

Özden
#21
Hello There,

I upgraded to SDK4 and now when I try to compile one of my games I get this error related with OpenFeint library :


Ld build/iPhone.build/Release-iphoneos/iPhone.build/Objects-normal/armv7/FastBall normal armv7
cd /Users/ozdenirmak/Desktop/XCode/GLBasic
setenv IPHONEOS_DEPLOYMENT_TARGET 2.2.1
setenv PATH "/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++-4.2 -arch armv7 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.0.sdk -L/Users/ozdenirmak/Desktop/XCode/GLBasic/build/Release-iphoneos -L/Users/ozdenirmak/Desktop/XCode/GLBasic/Lib -F/Users/ozdenirmak/Desktop/XCode/GLBasic/build/Release-iphoneos -filelist /Users/ozdenirmak/Desktop/XCode/GLBasic/build/iPhone.build/Release-iphoneos/iPhone.build/Objects-normal/armv7/FastBall.LinkFileList -dead_strip -lstdc++ -miphoneos-version-min=2.2.1 -framework Foundation -weak_framework UIKit -framework OpenGLES -framework QuartzCore -framework AudioToolbox -framework CoreLocation -framework OpenAL -lGLBasiciPhone-egl -lpng-gf -lPROGRAM -framework MediaPlayer -framework CoreGraphics -framework QuartzCore -framework Security -framework SystemConfiguration -lsqlite3.0 -framework CFNetwork -weak_framework MapKit -lz.1.2.3 -llibOpenFeint -o /Users/ozdenirmak/Desktop/XCode/GLBasic/build/iPhone.build/Release-iphoneos/iPhone.build/Objects-normal/armv7/FastBall

Undefined symbols:
  "___save_vfp_d8_d15_regs", referenced from:
      _GLB_OF_HighScore in liblibOpenFeint.a(GLBExports.o)
  "___restore_vfp_d8_d15_regs", referenced from:
      _GLB_OF_HighScore in liblibOpenFeint.a(GLBExports.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status

Any ideas Gernot or Trucidare?

Özden
#22
Congratulations, you are at "New & Noteworthy" section... ;)
#23
Looks stunning Francisco, good luck... :good:
#24
Hello Gernot,

Yes, we know it's C/C++ code we compile but in the TOS it's mentioned that things should be written in the mentioned languages originally and there should be no middleware to interact the IPhone API. In here, we use GLBasic commands which might be count as middleware. This statement is so elastic that even IPhone centric frameworks like Cocos2D might be interpreted in a way as middleware if wanted if you ask me.

It's also interesting that I've checked every major IPhone development kit solution forums to see what they say about that and the funny thing is that most of them think they'll be ok :), only some which use C# think that converting that part to Objective-C would solve it, which I still think won't help. 

Ãâ€"zden
#25
I would also love to hear Gernot's thoughts on this issue?

The TOS can be interpreted so elastic that even some strict IPhone/Objective-C frameworks, such as Cocos2D, can be count as middle layer as they prevent the users to directly work with OpenGL for graphics, etc. and put a layer to achieve things that are not available out of the box in the IPhone API itself.

Also in the current state of the generated files, there is even no need to check the function calls, etc. as the file names directly tells that they are created in something called "GLBasic" :).
#26
Hello There,

I've a question regarding the implementation of ITunes music. I can launch the music selection dialog and user can select the available tracks in his device and after the dialog close I want it to start playing right away. As far as I see, this is achieved using another method to start playing, is there anything can be done about this?

Also, after showing the music selection dialog, subsequent calls does not bring it up anymore, is this normal?

Thanks,

Ãâ€"zden
#27
Quote from: MikeHart on 2010-Apr-09
I just emailed to Apple to see what their official word on this is.

QuoteI still think that we are not in a bad condition, at worst, we'll get the libs in source code form and compile right inside the XCode, that's all.

But it is still not originally written in their languages. That's the point.

The thing in here is that C/C++ is mentioned as one of the official languages and GLBasic libraries are C/C++ codes and at the end, you compile a C/C++ code in XCode to run on IPhone. There can't be any evidence whether you pushed a MAC keyboard while writing these codes or not, am I wrong? It might be only that instead of separate libs, we might need to compile all GLBasic IPhone specific code into our executables.

In any other case, I think nobody can use even any framework (box2D, etc. just an example might not be the correct one) in source form as it might be written in Windows and the sources merged in a MAC with a real application.
#28
I've been following monotouch forums about this and people are confused a lot as well. It seems that Adobe's action on creating their compiler and even some further things such as code signing in Windows environment pissed off Apple a lot. I still think that we are not in a bad condition, at worst, we'll get the libs in source code form and compile right inside the XCode, that's all. 
#29
GLBasic compiles in C/C++ under the hood, which means your codes are actually converted to C/C++ syntax when you start compiling, I don't think this will be any problem...
#30
Great, thanks...