I have been doing a lot of testing with my app.
Here is my setup.
I run Mountain Lion. As an Apple developer I wanted to install iOS7 and the associated Xcode beta - therefore I am running iOS 7 Beta 3 on my iPhone 5 and iPad 3. I am running Xcode5-DP3.
I cannot use Xcode 4 to compile any more as the iOS7 devices are too new for it and are not recognised.
I wanted to use GLBASIC 10.283 to compile my Game.
First some background info.
I have my game Rock Crush compiled and on the App store for few years now - last update earlier this year.
When I first installled iOS7 - betas 1 and 2 - I ran this App store version of Rock Crush to see how it ran.
It had a major issue in that I pan sound far left and far right in my game - when the man moved left to right all was ok - moving right to left - I failed to hear him walk.
I did a lot of research - eventually noticing that when I plugged in a set of stereo headphones this issue cleared up.
I concluded that there was a problem in the first beta that game sound was using the left channel audio instead of mixing it down for the iphone and ipad internal speaker. strangely music playback didnt have this issue.
Anyway, I reported this bug to Apple and it got sorted in Beta 3.
I can now run my app store version of the game on iOS 7 devices with no problem.
The problem begins when I want to do a new version!
I will keep this short.
I compile with version 10.283 and then into Xcode 5.
The app runs with what looks like a green rectangle in the upper right hand corner and the screen is reported by the app at the wrong size.
For example, this code:
GETSCREENSIZE XRes,YRes // Get Screen size as defined in Project Settings.
comes back with a YRes 40 pixels short on both the iPad and iPhone.
This pushes the bottom off the app off the device screen. There is a horrible green rectangle at the top right and a feint white line on the last pixel line of the screen along the bottom. All ugly.
I did a quick fix and added 40 pixels back on for my rescaling codes benefit but the result was even worse - same lines and green by the way.
I then put on 11.414 beta and got once I was able to compile it (*I had a few issues but thats not for here), i got the same results - screenshot attached.
I am doing all this now as I need to know this will still work in a month or so's time - at the moment I am stuck as I cannot fix this myself.
I have done a lot of hours of testing but the problem here lies in GLBASIC or within Apples SDK.
I suppose what I am trying to say is I need someone more qualified to work out if this affects all apps or if it is a bug that needs reported to Apple.
To my mind- if ROCK CRUSH compiled for ios6 works on ios7 which it does - there shouldnt really be these issues compiling it for IOS7.
Comments very welcome.
One last thing.. Please bear in mind this occurs on both GLBASIC 10 and 11 betas. Xcode 5 is in beta. iOS 7 is in beta...
Here is an iPhone5 screenshot - note I have edited this in photoshop and added myself a purple coloured border top and bottom - to show up clearer the exact problem along the bottom row of the app. Notice how the green rectangle is now red on the iPhone.
None of my device backgrounds are those colours by the way.
I had added the 40 pixels on to this version so it reported 640 in the app by the way - but its like the whole screen is still offset from the top despite the app itself using 0 as the offset.
Strange... :S
Can you test in iPad if the orientation of the green rectangle changes depending on the devices's orientation at the time you launch the game?
For example:
Close your game forcing it from the "multitasking" menu
Put your iPad in portrait (you have to see your screen and icons in portrait)
Launch your game
Observe if the rectangle orientation or position changes
Close your game forcing it from the "multitasking" menu
Put your iPad in landscape (you have to see your screen and icons in landscape)
Launch your game
Observe if the rectangle orientation or position changes
Also, could you try to launch my keyboard wrapper and see if the rectangle changes its position???
Like here: http://www.glbasic.com/forum/index.php?topic=6706.msg54083#msg54083 (http://www.glbasic.com/forum/index.php?topic=6706.msg54083#msg54083)
Tell us what happens, please :)
Hi there. I will report back as soon as Apple brings their dev website back up and I can restore my devices to iOS7 again! I got so fed up I removed iOS7 to get some work done on the game update.
Hi. I have installed iOS 7 Beta 4 which came out Monday. I compiled same app using new Xcode 5 beta 4 that came out same day.
Results are in attached screenshots - the core of the problem seems to be that the iPad for example is reporting its screen height (when landscape for example) at exactly 40 pixels out - this is the size of the status bar on retina ipad.
Id imagine that figure to be 20 on iPad 1 and iPad 2.
The green blob is still there which is like a remnant of the battery meter.
In short although I have checked all the xcode settings are set to hide the status bar - the app does not seem able to do this properly on iOS 7 for some reason.
Tomorrow when I have more time I will again attempt to force the app to use the correct screen dimensions and report back what happens. I notice that this time the game screen is smaller both on x and y - which is correct considering it is getting fed wrong height info.
I will also do the tests you wanted above and report back as well.
[The game was compiled using the current release version of GLBASIC not the new v11 beta here.]
Ok Sorry for delay there.
Here is latest screenshots on ipad3. I am using the latest ios7 beta 5 from Monday. XCode same is Xcode 5 preview 5. GLBasic is 10.283.
I have typed in the INFO command in my game to show what size of screen the app thinks it is running on - always been correct until ios7!!
Anwyay, as you can see in the first screenshot the y res is 40 pixels short again and is showing what looks like the status bar or part of it.
my code to get the screen size is :
GETSCREENSIZE XRes,YRes // Get Screen size as defined in Project Settings.
nothing strange there. My rescale code then rescales the graphics accordingly. The first screenshot shows the y value is 40 pixels short.
To try and force a fix again, I used the following code:
XRes = 2048
YRes = 1536
which are the correct iPAD retina dimensions.
Again, the second screenshot shows the results... Despite forcing the app to use this size, the status bar is again pushing down the screen of the bottom - in effect there is nothing I can do from withing GLBASIC itself to sort this.
It could be iCade code related... not sure..
Comments welcome. Going to try latest GLBASIC beta next.
In reply to DaCarSoft:
Can you test in iPad if the orientation of the green rectangle changes depending on the devices's orientation at the time you launch the game?
For example:
Close your game forcing it from the "multitasking" menu
Put your iPad in portrait (you have to see your screen and icons in portrait)
Launch your game
Observe if the rectangle orientation or position changes
I have tested and here is a screenshot when launched in portrait mode.
Again, looks like a 40 pixel area at the top of the screen - with the green bar again. Once again there is a feint line along the bottom pixel row of the screen also.
Hard to see in this screenshot but it is there! shows up better with a black background.
Also, to answer the second part of DaCarSoft's question:
Also, could you try to launch my keyboard wrapper and see if the rectangle changes its position???
Like here: http://www.glbasic.com/forum/index.php?topic=6706.msg54083#msg54083
Tell us what happens, please
ok. I have compiled your library and source code demo under ios7.
Screenshots below of the portrait and landscape results..
Glad to say it was a clean project and the results where the same as the corruption I am seeing on Rock Crush.
Again, it may be hard to see but on both versions there is that feint 1 pixel line at the bottom of the screen.
hope that helps..
PS. nice work ;-)
Important: Further investigations tonight...
I managed to get my iDevices to be recognised at last by the older XCode 4.6.3
It used to say the connected device uses too new an iOS version to use with this version of Xcode.
I discovered if I used the devices for development first with Xcode 5.0 Preview 5 in the Organiser window, then shut down Xcode 5 and started Xcode 4 again, it finally gave me a green light on my iDevices.
I compiled and ran my game and it ran exactly as it did on iOS 6.x
These so called issues I have been highlighting here therefore, aren't iOS7 per se, they are actually issues or bugs in Xcode 5.0
I will report these issues to Apple so they can look into them.
Well, it is beta!
True.. problem is - is it a bug or a feature?
Its starting to look like a change in behaviour..
I'll keep my eye on it..
Definitively I have to test that thing under iOS 7.
Also, it is interesting to see if Apple will reply to your post about that bug.
If I have some news I will post here.
Thanks for testing, I wanted to see if that symbol could move or dissapear when using native iOS controls.
Finally, I solved it!
I have tested it and it is not a bug of Xcode or iOS... It is a change in the way that you need to hide the status bar for an application under Xcode 5.
The easy solution to solve it, for Xcode 5 is to add a parameter for the info.plist of the project by adding:
View controller-based status bar appearance Boolean NO
You can add it directly by creating a new value or copying and paste similar values from Xcode.
You can also add the parameter with a text editor:
<key>UIViewControllerBasedStatusBarAppearance</key>
<false/>
DaCarSoft - I love you and want to have your babies!! :blink: :blink: :blink: :-* :-* :-* :-* ;/ ;/ ;/ :) :) :) <3 <3
Seriously - one line in a .plist file?
Awesome work my friend!!!
Thank You for figuring this out - makes perfect sense to how everything was behaving!
Will test myself shortly but you have nailed it I reckon!
I take it this will roll into the next GLBASIC 11 beta? :-[
Just to report back.
I have compiled my app on Xcode 5, Ipad 2 running final IOS 7 and using the above settings does indeed fix the issue of the screen being off by 40 pixels. :nw: :nw: :nw: :nw: :nw:
However there is still a corrupt white line across the screen that moves depending on how I tilt the device. I know this is in fact the supposed hidden iCADE input window. :giveup:
I am running GLBASIC 10.283 here.. and its still an issue.
I will try the latest V11 beta shortly again.. :blink:
I just tried the latest V11 beta as of 26th Sept 2013.
I still have a few issues.
1/. There is still one single feint line "Below" what my app thinks is the bottom line of its display area - looks like 2 pixels or so below - I am GUESSING this is the hidden window for the ICADE code. Could it be this window needs the new view controller property DaCarSoft discovered set also?
2/. I have an iPad 3. In the "iphone" project properties in by GLBASIC project - the screen size is drop set to 1024x768. I tried manually setting it to 2048X1536 but my app didn't detect that actual resolution just 1024x768?
3/. This one is kind of different to the two above but basically when including a .mm file containing EXTERN "C" code - XCODE 5 is going nuts about it despite it being marked as OBJECTIVE C ++ code for that file in the Xcode project?
I have moved the file into iphone/Lib where it normally goes but it won't compile without lots of syntax errors. My current workaround is to remove library completely and butcher my code to not use the library for now - anyone got any experience compiling on Xcode 5?
Again, I don't have this problem with GLBASIC 10 - just 11. I realise this one is probably some XCODE setting but can I find it?
the iCade issue got newer fixed again. Only v11.171 got that fixed. So please fix that again, is so long time it awile and its another annoying ting.
So its seen it have been take some time after 11.414?
iPad 2 does not have retina screen.
sorry meant ipad 3 not ipad 2
try set the resolution to 9999x9998. Here its seen works fine with iPad 3, iOS 6 and xCode 5.
Im normally compile mm and m to the Classes folder and add them to the project. Not in the Lib folder, which should only contain the 3 *.a files (easier to mainstream, due the project overwrite bug).
The only most major issue for me is still the dummy iCade issue, which repeared again after that 11.171 version. While its a easy fix, its have not done anything like that.
Im do hope Gernot a day could reupload that beta version (so we can uses both v11.171 and the latest version), which is still the best version for iOS until then.
I will try that thanks.
Argh...
here is a screenshot of my .mm file and its location under Classes as you say.. Why does Xcode still not like it? Any ideas?
I tried the latest beta and it still has the feint iCade line across the bottom of the screen.
I also changed project settings to 9999x9998 but strangely my app still reports running resolution as 1024x768 on latest beta.
I am confused.. Wish these few remaining iOS issues could be fixed in GLBASIC as at the moment I can't get anything into the App store like this..
That looks like you need to #include "string.h" and try and find what values YES and NO are...
It looks like the mm file isn't complete for some reason...
Strange that I haven't edited this file for months and it compiled fine with ios6 - I was thinking a project file setting for architecture or something?
I just remembered that the generated project from glbasic 10 compiles fine on xcode 5 - its just the generated project files from the new v11 beta that I get this problem with.
you need to include anything you uses.
etc using ui thing, you should do a
#import <UIKit/UIKit.h>
Also have you checked icons, if the retina icons exists? xcode uses different resoulution, so you need around 8 icons to suit anything.
But howover im only uses Glbasic v11.171, not a newer version. That version fixed most bugs, include iCade (and got my iPad Retina pretty nice with xCode 5).
If im remove all other platforms than that, its only 41mb zippet. Hence im are happy to upload that version, which only contain the iOS platform (because 11.414 works fine for rest important platforms). But im do need a permission from Gernot first.
PS. The project it overwrite is being in Compiler\platform\iPhone\XCode. Eventuelly most issues and wrappers could been done fixed there really (anything got copied). Im have not touched it throught.
Emmm... Sorry because of my late reply...
First of all... Thanks MrPlant for your comments...
The iCade issues in last betas should be fixed in next version, I re-sent to Gernot a little piece of code that was lost in last beta versions.
Also, I just found some time to fix some bugs related with orientation under iOS 7, I will send all my code to Gernot to fix it in short, after a little bit more testing.
At the other side, errors related to .mm files could be because of last Beta 11 versions also, I found that the file iphone_prefix.pch (or a name similar) was lost in the Xcode project generated by GLBasic.
It is possible to add that file to your Xcode project manually by copying it from an old GLBasic project (from version 10, for example).
Also, it is possible to paste the code from the "prefix header" file (.pch) in the .mm file directly... Hope this helps... I'm replying from my iPhone now, but if you need I can explain the solution to that problem later, when I can have my laptop near...
I'm compiling ok for my iPad 4 at full retina resolution without problems and I will send all my work to Gernot as soon as I can.
Thats great news DaCarSoft!!!
Initial tests on 11.559 are this is an amazing release! A step in the right direction.
I can set project settings at 2048x1536 and it runs at that res on the ipad3 - which is what I want.
The dreaded icade lines are GONE!!!!
I fixed my .mm file (my fault). Had lost an include line as someone pointed out above.
Only thing I have noticed Gernaut is that you should add
View controller-based status bar appearance Boolean NO
<key>UIViewControllerBasedStatusBarAppearance</key>
<false/>
To the generated projects plist file so that the status bar is hidden by default which at the moment it isn't and as a result is shifting down the graphics onscreen with a horrible green or red battery bar shown.
Once this setting is added - it all looks good on mobile so far!
thanks.
Quote from: mrplant on 2013-Oct-12
...
Only thing I have noticed Gernaut is that you should add
...
:offtopic:
Jug gernault? :D (sorry could not hold myself ;))
But its nice its so close as its possible now, the most important issue, the icade is gone again. The eventuelly orientation issue is not very important at all, even its would been nice.
That battery bug as well another one need to been adressed as well: The project overwriting issue, which can been very annoying. Its should only been happens if the folder does not exists (same goes for Android project really).... This could been eventuelly a option of course.
I sent Gernot some code a couple of days ago, to fix the bug that MrPlant confirmed is solved, related to the bar and the battery symbol. The other code that I sent him also fixes some orientation issues related to the orientation of iOS elements like the new control center, the multitasking icons, or notification panel when the user rotates the device...
I think that these changes will help transparently to show wrappers like Facebook to be showed in the correct position and orientation, all without wrappers or special code.
With these changes, I think GLBasic will be perfect for iOS development, avoiding all kind of possible problems with Apple policies for App Store.
When the changes will be implemented by Gernot, I will publish a wrapper to obtain the orientation of the device under iOS without have to calculate from GLBasic's code using rhe accelerometer values.
May be that will be needed to test all these changes by all people here :P
Great work Dacarsoft! :good:
Yes Great Work DaCarSoft..
My comments were unashamedly about iOS only not other platforms and were pointed at the iCade and corruption issues.
The orientation changes sound very interesting..
Back to testing now - to make sure iPad 1 and iPhone models get the correct resolutions sent to them at launch.
XCode still shows about 114 'Warnings' when I compile by project relating to depreciated compiler changes... I don't expect that will be sorted anytime soon - I suppose warnings aren't nearly as bad as errors!!
I wish I could remember the reason why these warnings appear - architecture related wasn't it?
mightbeen some arm6 issues? They can been save to been ignored. Just been in mind. iOS v4.3 is minimum Apple supports today and you can't support older device anymore.
The reason you need to support IPhone 5 now for iPhone apps, which require a newer Xcode, which don't supports arm6.
Yep .
CPU_SUBTYPE_ARM_ALL subtype is depreciated ' are all the 100 plus 'warnings'..
Doesn't seem serious or anything just wondered the reason.
greedy mouse still got accepted by apple using Xcode 5 and iOS 7 icons. So still no worry about them
Well, I have not all the info, maybe Gernot is the best person to solve this question, but I think that it is related to the compiler and the platform/processor where compiler is focusing...
It's to say: we need to compile for iOS versions greater than iOS 3 or 3.2 and we have to use Xcode for that purpose, setting the deployment target to iOS > 3 (6 probably, now), but the real SDK, the GLBasic compiler, is targetting to ARM instructions that can be supported by iOS 3 when "precompiles" the GLBasic program (the libPROGRAM.a file)... These instructions are supported by the newer processors, because of that all works... But Xcode warnings say that your instructions are focusing to a processor and iOS version deprecated...
Today, this is not a problem, almost until Apple changes totally its processors breaking backwards compatibility... :S
Makes sense... Thanks.
Trying to validate my app on Xcode 5- it says the app references non-public selectors in Payload buttonDown: buttonUp:
Seems keyboard routine related..?
Is that complaining about a library call not in the official iOS SDK? Nothing objective-c wise in my app does that...
Maybe its just a follow on error from the 3 above it I haven't mentioned here?
???
Are you using my keyboard wrapper? It should not fire that error... I'm not using unofficial calls... Anyway, my keyboard wrapper does not appears correctly under iOS 7, I have to update the code to show Textboxes correctly.
I will try to investigate and test that, but, are you using some other kind of wrapper? That ButtonDown/ButtonUp could be iCade related... But it is early to say something...
What libraries/frameworks are you using???
ARGHHHHH!!!! It is iCade related, again...
I suppose that the errors appears at validation time when you tries to prepare the package of your App for send it to Apple.
It does not let you continue??? What steps exactly are you doing??? I want to replicate that...
Thanks
yes the iCade window issue have been fixed, but im do got the same warning too when using the validating.
Howover if im try to submit it, its did upload its with no problems, but got the warning after submitting again
References using non-public might got rejected by Apple, so you need pass that validation.
OS. My guess is properrty buttonUp and buttonDown is now a reserved variable for Game Controllers (iOS7) support, which this game does not supporting. So its possible a false positive. But better to get that fixed.
Yep fraid to say I've been trying to get my app validated for the past two days - spent hours until I have came to the conclusion there isn't much I can do myself about it..
I am not using any wrappers or external files - just a standard GLBasic program compiling for the iOS platform.
The main error I get is a general error that my app.plist file cannot be processed - I used application loader to see what happened with that and got more details I posted earlier. Bottom line I cannot validate my app for submission.
XCode just comes up with this error - and no matter what I do I can't get past it. It then says app failed verification.
This is a very annoying general error - in that it doesn't say anything about what is wrong as such - as I said, using application loader instead of XCode 5 to upload the app gives more info - but I posted that info earlier. At the moment unable to upload or validate a new version of Rock Crush to Apple. Argh...
I think it is a false positive...
I renamed some functions and sent all my code again to Gernot, I have not an iCade, but I will try to test it with a bluetooth keyboard.
I think Gernot will include my code in short, in the next beta it should be corrected.
EDIT: I just tested with "INPUT" and a bluetooth keyboard and it works fine. The bug should be fixed.
sounds good. I just wasn't sure if this error was myself not filling in my app settings correctly in XCOde or if it was something beyond that.. in GLBASIC itself?
I just edited my post of before...
It is GLBasic itself. It appears that some code for the iCade/keyboard have the same names that some Apple hidden functions. I just have tested it with a bluetooth keyboard and the iCade appears to work OK after renaming some variables and functions.
All should be ok now, when Gernot will include my modifications.
Fantastic!!! :good:
I wish there was a new beta.. My app still stuck waiting for upload since Oct 15th... :nw:
I sent my files to Gernot, including my new fixes for iCade related bugs when compiling under Xcode 5...
I still haven't a reply from him. I suppose he is busy.
Did you received my private message? It was about try to test a couple of things to workaround that problem.
he diddent fix that in v12? Yes there is a new beta and he have called its v12 now and in the future the update function should work again and enabled. Im have not tested this issue got fixed in this version.
EDIT:
v12.001 have fixed this issue, and both iCade and validation is fixed. He might just forget to answear you this time. So just grab that version.
Could be to busy fixing things to reply :)
Oh my god... :O I had no idea about a V12 version !!! :blink: I was searching in the forums and I did not found anything...
Gernot just told me about it, also... I'm downloading the installer using the same link as previous versions to see if that is the new V12 installer...
I will try to test it to see if the validation bug under Xcode 5 is solved.
my game is on review (v1.5) since yesterday, but its was only one day in the queue, which have surpriced me. Greedy Mouse v1.5 uses v12 and see what happens. There was no validating issues.
Spacefractal: May be that you are not compiling with Xcode 5??? Hmmmm :blink:
It appears that Xcode 5 is the problem... When you uses it, the validation appears to fail because of the supposed illegal use of Apple's private APIs...
im uses the newest xcode 5.0 and did not see any validation issue in v12. Howover the review time is quite longer than normal, howover 'm rejected it due little concern about I'm did removed the android variable, cause inapp not working, but look when home. I'm need to make sure it's can't compile when the variable exists.
Great this looks promising - I shall test out this new 12.001 tonight as I have an app stuck waiting on validating as well under Xcode 5 (11 Beta). :nw:
Tell us the final results!!!
Remember to erase the "distribution" folder before compiling to let V12 refresh the library files!
Fingers crossed!
The game got accepted with using v12 and Xcode 5, so all important issues is fixed.
The game is howover on developer release hold, so not a apple issue :-)
Great news!!! :good: