Hi!
I updated ALL software: GLB and Xcode to last version available.
I make some test for compile to iOS 5.0 on iPad 1...
All done... BUT, look right corners... ARE ROUNDED!?!?!?! :blink:
Left screen are OK...
Any help are welcome.
TIA, H.
PS Clic on image for zoom/best bug view... remember old mac screens... =D
[attachment deleted by admin]
Hi.
The curves at your extreme corners look like mine a bit.
I've been getting this for months now - strangely enough only on iPad.. Mac and PC builds are fine.
Also strangely, my rounded corners are on the left side. I am floating in a graphic from bottom right to position 0,0 on the screen. Later in my game it goes away.
I just learnt to live with it as nothing I could do would fix it and it only occurred on iPad.
Zoomed in photos attached along with original screen grabs I just took.
The graphics are 1024x768 single layer non transparent png files with pre-rendered edges on them.
This is the code I use to float it in from bottom right to top left of screen.
// SETORIENTATION 3 // Default orientation on iOS for landscape (Button on left).
// Fade in the Title Screen smooothly from bottom right to top left.
LIMITFPS SmoothFPS // Smooth fps rate on!
FOR LoopX = 768 TO 0 STEP -3
UDrawSprite (gTitleScreen,LoopX, LoopX)
// The following code is compiled for iOS Platform only:
?IFDEF IPHONE
IOSAutoOrient() // if running on iOS, check for a screen orientation change and flip as required.
?ENDIF
SHOWSCREEN // Copy whats on Backbuffer to main screen.
NEXT
UDrawSprite (gTitleScreen,0,0)
SHOWSCREEN // Copy whats on Backbuffer to main screen.
If I compile code above in Xcode as iPhone - it runs in a window on the iPad and the corners are fine. Change project settings to iPad however, and the corner problem occurs. Very strange.
[attachment deleted by admin]
hmmm
I no use any SETORIENTATION... only CLEARSCREEN and SETSCREEN.
I think to draw on top layer MY designed four rounded corners like you... to fix this temporally.
O_O You says... very strange bug.
I noticed this in Greedy Mouse as well, iOS add those corners.
I can think its eiter a missing xcode setting or can been done in inline. The most annoyring thing is those corners does not fellow ORIENTATION (which they does not). If they did, then I would not notice them at all. By now I just igonere it.
Also doing its full layer draw is very much overdraw. instead just load one cornor graphics and put them in each cornor to meantime fix it....
Quote from: spacefractal on 2012-Mar-26
I noticed this in Greedy Mouse as well, iOS add those corners.
I can think its eiter a missing xcode setting or can been done in inline. The most annoyring thing is those corners does not fellow ORIENTATION (which they does not). If they did, then I would not notice them at all. By now I just igonere it.
Also doing its full layer draw is very much overdraw. instead just load one cornor graphics and put them in each cornor to meantime fix it....
iOS ADD CORNERS?????
ONLY 2 VERTICALLY???
:blink:
Y paste a solution founded ... (http://stackoverflow.com/questions/5518977/how-does-one-eliminate-the-rounded-corners-on-the-main-window-on-an-ipad-app)
(e.g. the iPod player has square corners at the top; can't tell at the bottom)
You'll need to get used to this: Apple apps will do things your apps can't do. Apple get to use private frameworks, App Store apps don't.
If you don't use the status bar (ie, completely 'full screen') you'll get a 'non rounded' screen. This is pretty simple to do - just hide the status bar from within your code (or, if you want it hidden throughout your app, you can just set it in your info.plist).
I try later!
Looks like Apple wants your graphics to look like its own - whether you like it or not... :P
What I can't understand is sometimes (almost as if randomly), I get the corruption shown here - its like a rounded corner a third of the way along the top.
Again, iPhone is fine - only on the iPad - and my graphics were all designed for the iPad in the first place - there are no rounded corners in my originals...
weird...
[attachment deleted by admin]
Once my main game starts - this problem always goes away... Its very strange.. My Xcode settings are already set to hide status bar.
[attachment deleted by admin]
Im very confused :blink:
Hi!
New test...
(http://lh6.googleusercontent.com/-xgtCehd7HTQ/T3tnCrgovGI/AAAAAAAABz0/Ok7VlaWoNAE/s400/12%252023%253A09%253A30.jpg)
I paste the log of Xcode (colors are mine):
init with frame.
Scaleing available: self.contentScaleFactor = 1.000000
desktop backing: 768 x 1024
mainScreen: 768x1024
slaunch ok
-applicationDidBecomeActive -> unpause
2012-04-03 21:14:11.724 iPhone[6032:707] Application windows are expected to have a root view controller at the end of application launch
timer
rbow
rbow init
Rbow::SetScreen( 1024,768)
get accurate timer - 1st call
flip - 1st call
BGRA ext supported
Texture size limit: 2048
init fbo
2D VP
OGRB init [OK]
Cptn
Network
Input
Window mode
Create DXin
reptr
getexe
cd
set cdir to: /var/mobile/Applications/FFECC524-AEB6-4D8C-A656-95AF33FB22B5/iPhone.app
exepath=curdir= /var/mobile/Applications/FFECC524-AEB6-4D8C-A656-95AF33FB22B5/iPhone.app
AudioStreamBasicDescription: 2 ch, 44100 Hz, 'lpcm' (0x00000C2C) 8.24-bit little-endian signed integer, deinterleaved
Init Finalized
Rbow::SetScreen( 1024,768)
loadeffect - i: 0 eff: 2400
play - i: 0 eff: 2400
Shut down GLB
glb is shut down
exit
Maybe GLB works windowed on iPad?
:blink:
Might be easier to set the "main nib file base name" in the pList file.
Quote from: MrTAToad on 2012-Apr-03
Might be easier to set the "main nib file base name" in the pList file.
Tried adding "main nib file base name" and "main file base name ipad"...
I left blank fields....
Can you paste string fields for this sets???
(https://lh6.googleusercontent.com/-71emhll7R4o/T3tw0wW7FgI/AAAAAAAAB0k/f3OUAMvftj8/IMAGE_CF5F532C-F6EE-43EB-93BF-60C2AE299621.JPG)
I think you are supposed to put in "MainWindow" for the "main nib base file name" section : http://stackoverflow.com/questions/7520971/applications-are-expected-to-have-a-root-view-controller-at-the-end-of-applicati
Quote from: MrTAToad on 2012-Apr-05
I think you are supposed to put in "MainWindow" for the "main nib base file name" section : http://stackoverflow.com/questions/7520971/applications-are-expected-to-have-a-root-view-controller-at-the-end-of-applicati
Hello again...
I added MainWindow on main in base file name.... ROUNDED CORNERS. Only compile/run in Debug mode.
I tried for Release... Xcode compile and runs, but halt app due "MainWindow.nib" file missing.
I created a new Window file into Xcode called MainWindow.xib.
Compile/run works.... BUT
1 Obviously the new window are ON TOP of my app.
2 Maintain ROUNDED corners...
:O
mmmm I need to use SETSCREEN 1024,768,
1 <- Fullscreen?
Im really confused... Im just launch my iPad, the computer and all for the window of my house. (I live on 4 floor) :rant:
EDIT:
Tried SETSCREEN 1024,768,1
FAIL :rant:
EDIT2:
I created a NEW GLB project, just setscreen, drawling across window and text hello world...
The app works horizontally (1024x768).
I ONLY set in info.plist this Field:
Initial Interface Orientation -> Landscape (left home button)
and now the 2 rounded corners are at bottom screen...
Im continue investigating with adding isetorientation...
:|
EDIT3:
Definitelly I think GLB runs on window mode.... I make new Xcode GL and works fine...
I goto to cinema.... Im exaust for now.... :giveup:
For now I use my OWN rounded squares...
;/
[attachment deleted by admin]
I'm surprise that the info didn't fix it :blink:
Hopefully Gernot can figure how to stop curved corners...
Quote from: MrTAToad on 2012-Apr-07
I'm surprise that the info didn't fix it :blink:
Hopefully Gernot can figure how to stop curved corners...
I think GLB run on ipad in windowed mode... you can see xcode log...
Why? I don't know... I started all new xcode projects for iOS using samples included in the SDK from Apple... single page, OpenGL, etc... none have ronded squares...
I tried too compiling for OLD iOS versions such 3.0.... and none...
Are a HOW-TO for starts new project on xcode... and include manually GLB *.a libs???libGLBasiciPhone-egl.a
libpng-gf.a
libPROGRAM.a
ANOTHER BUG DETECTED!
Hi, testing round corners issue on iPad3 with a friend, he shows me about 1px black line on screen!
Maybe all buffer screen are displaced 1px line?
Remember, the rounded squares of this sanpshot are included with me... for "fix" only 2 rounded corners...
Please check 1px displaced screen problem!
(https://lh5.googleusercontent.com/-PZ4eJQFHvYo/T4KKWl6YMMI/AAAAAAAAB2E/OWGbzx65Nk4/12%252009%253A06%253A06.jpg)
TIA, Hark0.
Darn. I have to investigate further. Its a real pain.
Quote from: Kitty Hello on 2012-Apr-09
Darn. I have to investigate further. Its a real pain.
Thanks... by the way.... rounded corners are related to video declaration?
And... a short/step-by-step HOWTO for create/compile the 3
a lib files produced by GLB on xcode?
I no need explanations, just "tap here or clic on add xxxx".... (I investigate for optimize/compile glb with my hands)
;)
TIA, Hark0
I think it's the "hidden" input window for the INKEY$ and iCADE support.
Quote from: Kitty Hello on 2012-Apr-12
I think it's the "hidden" input window for the INKEY$ and iCADE support.
:blink: ?
(I think my english are a bit confuse)
The input window is somehow 1px wide and visible
I checked various apps.
corners is allways shown when the top statusbar is shown, but gone when its not shown. mostly shown when the top statusbar is shown, Few apps even fill all rounded corners.
apps I tested with iCade support (example Mega Worm) did have those corners too, so its must been that about INKEY$ and iCade. So a idea could been disable that INKEY$/iCade support, and let the dev dedicate its required or not (in option setting), and even possible to enable it in the game settings (which I have seen in some apps, which could been this issue).
Howover its would been better if corners fellow the rotation (so the corners is allways on the bottom), which is I think its have extracly the samme problem with Android when surface change.
Howover the best and the easist fix is simple just fill all 4 corners......
Quote from: spacefractal on 2012-Apr-13
I checked various apps.
corners is allways shown when the top statusbar is shown, but gone when its not shown. mostly shown when the top statusbar is shown, Few apps even fill all rounded corners.
apps I tested with iCade support (example Mega Worm) did have those corners too, so its must been that about INKEY$ and iCade. So a idea could been disable that INKEY$/iCade support, and let the dev dedicate its required or not (in option setting), and even possible to enable it in the game settings (which I have seen in some apps, which could been this issue).
Howover its would been better if corners fellow the rotation (so the corners is allways on the bottom), which is I think its have extracly the samme problem with Android when surface change.
Howover the best and the easist fix is simple just fill all 4 corners......
hmmm... The problem are maybe INKEY$ function? It is? O_O
You can view my fix.... my own rounded squares png... :/
yes its can been a hidden input window, which is some odd its can been seen. Not all games require Inkey$ support (as iCade actuelly use), so its could been disabled for those projects not using it (your game seen not need that support anyway example), or could been enable on demand.
The simple fix is use the corner graphics by now. Howover your game would have better without those if you aske me, due the style of your game. But again its better to just intergate it instead.
Quote from: spacefractal on 2012-Apr-14
...Howover your game would have better without those if you aske me, due the style of your game. But again its better to just intergate it instead.
If Hark0 uses a ´border´ similar to the pixelated black in line of his screenshot, I would´t even notice or bother.
its its cant been fixed the proper way, this is of course 100% valid and a nice alternative way (and I could do the same in Greedy Mouse as well). That I just mean its due the black border used in the game. But in the end I dont think its a problem at all anyway :-D. So nothing problem.
Its would still been nice to enable/disable the inkey$/iCade support if not required.
Actually, I use my own XCode project to workaround this problem.
It is a modification from the GLBasic's XCode autogenerated project, to make my project "Universal" cappable. I did it long time ago, from XCode 3.X early days :P
If I compile using my own XCode project, I don't have rounded corners or black lines at bottom (tested under iPad 2 and iPad 3)...
I was trying to found the difference between my project and the GLBasic's generated project without luck :( I can't see any substantial difference related to the rounded corners...
I was testing generating a fresh new GLBasic's project, changing all its XCode parameters without results.
I only can make dissapears the corners and the black line by copying my own (and old) .xcodeproject folder and its info.plist to the new project's folder (the two are renamed, to not have to overwrite anything and avoid problems each time that GLBasic compiles, because I know that some time ago it could overwrite the XCode changes).
Hope this helps to found the bug. Regards.
Can you zip this xcode project, please?
Quote from: Kitty Hello on 2012-Apr-24
Can you zip this xcode project, please?
Sure!!!
Here, I attach the project that I have for testing purposes.
It is renamed different than the original. It has also an info.plist to be capable of importing files under iOS.
There are included some XCode wrappers that I published before in this forums.
Tell me if you have any problem to run or use it...
Regards
[attachment deleted by admin]
Hi (again)...
I just discovered the difference...
I don't know exactly why, but I have an old libGLBasiciPhone-egl.a...
This .a file should come from the times before the iCade support... :P
For me, when I build a new iPhone project, GLBasic is generating a copy of libGLBasiciPhone-egl.a and libpng-gf.a files inside my "XCode" folder, and inside "XCode/Lib" also... But appears that it does not overwrite my old .a libs...
If I overwrite the GLBasic .a lib/framework with the last version, the rounded corners appears :( and I have a lot of problems when I try to change the iOS orientation using my wrappers (contained in the ZIP file, you can test it)... I suppose it is because the iCade View is rotated when I change the iOS orientation.
Test it using my ZIP if you can, to see what I'm trying to explain.
OK it's the iCade then. I'll try to fix it.
Quote from: Kitty Hello on 2012-Apr-26
OK it's the iCade then. I'll try to fix it.
Maybe you can add a
check option in Project/Options screen for iOS.
;)
All you can do is possible for us to disable iCade/Inkey support when its not needed by the games. Corners present for iCade games is a iOS issue.
Another issue also with iCade is its wont respons at all after a GLB_ON_RESUME call, when a app is resumed, but elsewise until that happens its works nice. Here I would do a init call again.
as I previos requested possible to call java functions by a special command, I think its could been done extactly the same trick with disable/enable like this....
And... what about include the iCade support as a wrapper???
May be that these kind of functions (iCade, alerts, keyboards...) must be independent "open source" options... to let programmers maintain easily these kind of hardware/OS dependent parts in GLBasic... almost, when is not sure that these parts are "rock solid" and will work in the same way forever...
I remember that: An upgrade in iOS 4 did mandatory the use of certain visible iOS elements from the "main thread" (alerts for example)...
That OS updates and changes ever brings problems... That could make unusable an App made with GLBasic under some circumstances.
I have long suspected this Hello Kitty!
I remember working on Rock Crush last sept. (around about 19th-21st) when I first started the project research and I mentioned to you initially about iCade support and you added it in - it was around that time - I can certainly narrow it down to that week as I was on holiday at a cottage that week and worked on it - you were releasing almost daily builds of GLBasic at that time- and the day you added iCade support it started showing those weird random corners...
I was pretty convinced even back then thats what it was..
How to sort it would be another matter but I wouldn't have a clue of course ;-)
Even to this day, it appears randomly as corner distortion effect mentioned. This is on iPad and iPhone.
It is annoying but does no harm. I hope there is a way to fix it whilst still keeping in iCade support as it currently works as the implementation from within GLBasic is brilliant I think.
Perhaps as a current workaround - some sort of option to enable.disable iCade support from GLBasic?
The other thing to add is my game Rock Crush is multi platform and I have never ever seen this weird corruption problem appear on my windows or mac computers - just on iOS - so it has to be the iCade code.
Hope that helps you a bit...
Quote from: Hark0 on 2012-Apr-13
Quote from: Kitty Hello on 2012-Apr-12
I think it's the "hidden" input window for the INKEY$ and iCADE support.
:blink: ?
(I think my english are a bit confuse)
in Greedy Mouse you barly notice them anyway and you can allways add them to all 4 corners, then noneone would notice it at all.
Anyway agree we should have some sort of option to disable/enable support of variours ting.
Somesort of value$=GETOPTION$(name$) as well SETOPTION(name$, value$). This command could also invoke the special java function for Android as well other platforms.
To enable/disable an option in GLBasic could solve the problem for programmers that don't need the iCade support... But... the corners will continue appearing when iCade support will be "on"...
I'm sure that it should exist a way to make "invisible" that window under XCode, but if that windows continues there, in any way, it could bring problems for me when I invoke to certain iOS specific functions to rotate my iOS alerts or keyboard, because of the position of the iCade window when iOS rotates the screen or because of a shadow that iOS generates for the iCade view... (or any other new problem that could appear testing in the future...)
I was compiling with an old version of the .a GLBasic framework before, now if I let GLBasic use the last .a versions, my code does not work properly :( but I can't turn off iCade until an update will be published... :'(
Anyone could test it downloading my zip from the previous posts and testing it, overwriting (or not) the .a libs in the XCode folders to see what happens.
For me, may be that an ON/OFF function could solve the problem, I could make a new wrapper to support iCade and avoid these problems, but... It is not easier to use it as a wrapper directly?????
I'm sure that the iCade support was included with the best intentions, but these kind of things could be in conflict with any XCode function that anyone could try to use.
Only to explain me better, and offer more information to solve the problem in the best way:
This is what happens for me since I updated GLBasic to a version that includes the iCade support.
I can't create certain iOS elements freely, without errors or problems...
The first picture is my keyboard wrapper when I show it in landscape, because the iCade view doesn't rotate when I rotate my own iOS created views/controls.
The other picture shows what happens after the keyboard is hidden: The iCade view does not rotate and continues showing the corners and a shadow. Like in this message of "MrPlant" some posts ago:
http://www.glbasic.com/forum/index.php?topic=7867.msg65671#msg65671 (http://www.glbasic.com/forum/index.php?topic=7867.msg65671#msg65671)
Hope this helps.
[attachment deleted by admin]
I gonna think its the same issue with the Android surface rotation issue? Here just with iCade. Howover not a big issue in Greedy Mouse, but I do can see its a annoying bug when UI is used.
So best fix is still possible to disable and enable those speciel version in runtime and you would not notice it. Not all game need iCade anyway, howover I support it in my game (since its a joypad type game).
This is starting to get too complicated for me now.
What can I do? Hide the iCade view? Do you want a pointer to it? Would that help?
Hi...
As i said in my previous posts, I know that the iCade support was did with the best intentions, but I think that to create an iOS view (under XCode) that the users of GLBasic/programmers can not control is very very dangerous...
Not only me, other people are experiencing problems because of the iCade view. Because of this, may be that the best solution will be to remove the iCade view and support/implementation, and offer this support as a wrapper.
I was searching hard, trying to found a solution, and I was looking at the code here:
https://github.com/scarnie/iCade-iOS/tree/master/iCadeTest/iCade (https://github.com/scarnie/iCade-iOS/tree/master/iCadeTest/iCade)
I suppose, reading old posts here in the forums, that you used this code to implement the iCade as a joystick.
Looking at the code, I suppose that may be a way to implement it as a bluetooth keyboard, without any view, but... I don't have a iCade for testing...
With a pointer, I could try to write some code under XCode to remove/control the iCade view, but this is something that all GLBasic programmers will have to do if we want our App free of rounded corners or black lines...
Sincerely (Im so so so so sorry...) but i think that the best way to solve this is remove the iCade from GLBasic and implement iCade is a wrapper for programmers who need it...
:( I say this with the best hopes...
Best regards.
My code is:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
CGRect rect = [[UIScreen mainScreen] applicationFrame];
//Create a full-screen window
window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
[window setBackgroundColor:[UIColor blackColor]];
gpGLB_MainWnd = (void*)window;
// ## iCade View ##
iCadeView = [[iCadeReaderView alloc] initWithFrame:CGRectMake(0,0,1,1)];
[window addSubview:iCadeView];
iCadeView.active = YES;
iCadeView.delegate = self;
gpiCadeView = iCadeView; // store global 'extern "C"' pointer
// ## OpenGL View ##
//Create the OpenGL drawing view and add it to the window
glView = [[EAGLView alloc] initWithFrame:CGRectMake(rect.origin.x, rect.origin.y, rect.size.width, rect.size.height)];
[glView setMultipleTouchEnabled: YES];
[window addSubview:glView];
Does this help?
Yes! I suppose...
Let me test a little...
Do you have an extern pointer like "gpiCadeView" for the "glView"?
EDIT: I suppose that "gpGLB_MainWnd" could be useful.
Also basic should been basic, that also inline calls using them should been keept as minimum, elsewise its would begin to been compliced for more for us. So its can mightbeen not been a 100% fix.
Its seen the iCade windows is not rotate correctly after the costume rotation call (just like Android). Howover if its did resize and its did keep the corners to the corners, then its would been much less notiable and acceptable. Its could been done example under SETORINTATION, so the UI could rotate directly too under that, and also resize the iCade window too here.
That would been the best fix to that.
Also another way yo do is, iCade is treated like a joypad, so possible to disable and init a joypad would been cool too. Also doing that example with ENABLECONTROL(JOYID, BOOLEAN). This would also not break any compatiblle and I could reinit iCade after resume call with ENABLECONTROL(1, TRUE) to reinit it again (if iCade have id 1).
the iCade also offers INKEY$ for bluetooth keyboards.
Hi again.
I just tested it (hardly)...
I can't replicate the fail in my project because I suppose that I can't obtain exactly the same "iCadeReaderView".
I'm using this code for testing (in addition to your "application didFinishLaunchingWithOptions:" from your post, Gernot):
https://github.com/scarnie/iCade-iOS/tree/master/iCadeTest/iCade (https://github.com/scarnie/iCade-iOS/tree/master/iCadeTest/iCade)
After testing it, I don't see any problem in the iCade from Scarnie... It only shows rounded corners because of a nib file included in its info.plist
May be a problem inside the iCadeReaderView controller... or inside the EAGLView code... or a wrong call to "makeKeyAndVisible"...
I suppose there is no bundled "nib" files into the .a GLBasic's framework...
Is there any way that I don't know to access to gpiCadeView pointer?
EDIT: It also appears that the last version of the code from "scarnie" solves a problem related to background/resume...
Spacefractal: I also think that BASIC is BASIC (I love GLBasic) and I also think that should be reduced when it is possible the inline calls... But for supporting certain functions from iOS you need to use XCode if GLBasic does not support it... Because of that I like GLBasic: You can expand it with wrappers... I did wrappers to use the iOS keyboard (supporting Bluetooth keyboards also) and alerts, and I did my "iOSSetOrientation" wrapper because Apple shows in its policies that apps have to support (totally, including the bottom multitasking bar) two or more device orientations... I don't know any app rejected because of this, but these are the Apple policies... I feel more comfortable implementing this.
The iCade appears to cause "visible" problems and I think that iCade is not a device largely sold, I only think that implementation could not be a priority if it brings problems. Or it could be done in other "invisible" way... But I agree with the idea of make the effort to try to have all things working first. ;)
Apple have rejected apps that dosent support both landscape modes on iPad (if its a landscape game), but how you doing that by IOS system call or by software is irrerevent (its depend on app, and often games just using software method, since they not using IU calls).
Gernot could of course do a iOSSetOrientation call to the SETORIENTATION (so eventuelly UI would rotate too), and he might face the iCade issue as the previous screenshot (but easier to fix when he can invoke it). Then we would have a much better iCade support since the corners would now allways on the bottom and resized correctly (again to been done under that command). So all fix could really been done under that command, which I see the bug is really there. Its would been a very small issue if they are gone or not (due they allways on bottom as they should amd UI should not been broken anymore even they still might been shown).
iCade is a very great and well buildt arcade cabinet and I have it and its a highely recommered product and cool to support it when you can and if the game using arcade style controls. If does, you need to support it.
Best is simply disable it by default and let user enable it from the game options (some games require it). Then its would been fine with me.
Apple wants that programmers don't break the usability of their devices.
They want that every app support all their Human Interface Guidelines, it's to say:
The four fingers swipe up/down must be working correctly in your app, according the orientation of the image that user sees... All apps have to support multiple orientations fully working... They suppose that programmers have full access to their tools (XCode, Safari/webkit) to fully support this.
Just the same that if your app requires the use of the Internet, you have to detect when the network is unavailable and you have to notify this fact to the user...
Just the same that you have to make match your 512×512 iTunes Store icon with the 57x57 iPhone icon, the two icons have to be the same image, or very near to be the same...
There is so many rules that do not appear clearly in their HIG, but they are supposed to be obvious, and you have to play their rules...
You can't claim "App X does this but is already in the App store" as an excuse when Apple rejects an app. They will not accept it as a valid justification.
Sorry if I'm going offtopic :P
Quote from: Kitty Hello on 2012-May-08
This is starting to get too complicated for me now.
What can I do? Hide the iCade view? Do you want a pointer to it? Would that help?
EASY!
1 Delete ALL references to iCade in GLB.
2 Make new post on forum-snippeds and paste *.m,*.h, *.* wrapper files needed for iCade.
Other users can paste his own wrapper files for other things like EMail, camera roll, keyboard, alerts, bt devices, etc
=D
Those 4 finger gestures is actually very annoying and they are not on guideline at all (i diddent find that). I guess it's did not work as intended on iPad, due it's interfered too much with 2 player and music based games (they often use 5-6 fingers touchs here).... I disabled quickly due that. So it's don't works with games, but different story with applications of course.
Yes it's offtype now, and all we can is see the setorintation bug to fixed. The bug is all rely in that. It's more important by now.
It is not only a problem related to iOS orientation through wrappers, I suppose:
http://www.glbasic.com/forum/index.php?topic=7867.msg65671#msg65671 (http://www.glbasic.com/forum/index.php?topic=7867.msg65671#msg65671)
There is also people hiding corners doing things like this:
http://www.glbasic.com/forum/index.php?topic=7867.msg66155#msg66155 (http://www.glbasic.com/forum/index.php?topic=7867.msg66155#msg66155)
Or this (I suppose, but this may be not because corners):
http://www.glbasic.com/forum/index.php?topic=8038.msg67427#msg67427 (http://www.glbasic.com/forum/index.php?topic=8038.msg67427#msg67427)
Its the http://www.glbasic.com/forum/index.php?topic=7867.msg65671#msg65671 issue that could been fixed by SETORINTATION, so its doing a iOSSetOrientation call when the command is invoked, and its should also resize the iCade window after that correctly (so you not get the previous issue). That could also fix the nonerespons iCade issue as well when a app is resumed.
When doing that, then the corners should been present on the bottom, and the same is with eventuelly keyboards and other UI calls. I think this is the best to have both worlds so we still can have iCade support without breaking UI calls. Those who want to hide corners could then eventuelly use the http://www.glbasic.com/forum/index.php?topic=7867.msg66155#msg66155 trick after that.
PS. Possible by disable iCade support for advanced users could eventuelly been done by some function in classes/main.m or by a classes/disableicade.m)...
In my tests SETORIENTATION no fix nothing!!!!
:o
I think like @Dacarsoft; the BEST WAY are DELETE all related to iCade in GLB and offers support for iCade with wrappers (*.m, etc files).
(Fix bug corners with images are a TEMPORAL trick... not a PROFESSIONAL SOLUTION.) ;/
Regards! ;)
Quote from: Hark0 on 2012-May-09
In my tests SETORIENTATION no fix nothing!!!!
:o
I think like @Dacarsoft; the BEST WAY are DELETE all related to iCade in GLB and offers support for iCade with wrappers (*.m, etc files).
(Fix bug corners with images are a TEMPORAL trick... not a PROFESSIONAL SOLUTION.) ;/
Regards! ;)
+1
so before going rage and such, so calm down and not going to been upset (its close doing that when you formatting text like that).
So in the nice short time fix, is still fixing SETORIENTATION as I wrote before (the missing iOSSetOrientation call) and rework the wrong rotated iCade window). Should been quite easy to do. Then the issue would been became pretty very very small.
A better long term fix is adding the ENABLEKEYBOARD command for disable/enabling bluetooth keyboards (possible to enable/disable keyboard/iCade supports without wrappers). Here its might take some time me think to get it work correctly on all OS (Android, WebOS and iOS as primary target).
In timeline usage I still think the short time fix is easist first, even its NOT perfect. Its a comprimise.
EDIT: Sorry I removed a post, as I did not want to offensive some people, which was not intendend to do that. Sorry about that.
EDIT 2: The code Gernot posted, could that not just been moved to a launch.m file? Then if people want to disable iCade, they could just comment the iCade relavent code out? I really dont think its break INKEY$ at all.
dacarsoft is currently trying to help me fix this issue. I know the urge and I hope to provide a fix, soon.
Personly i dont care about them as long they displayed correctly in the corner. In Greedy Mouse they are barely not noticeable anyway or thinking about it at all. I think, it's a iOS charm :-)
That why the SETORIENTATION thing, which could also fix the notifaction center issue as well I posted some while ago....
I think that now it is solved, I would like to test harder... ;)
Here are the news:
Rounded corners: FIXED!
iCade related problems with wrappers: FIXED!
iCade problem when entering in background should be fixed also... If anyone have an iCade please tell us how it goes (the fixes still have to be implemented in GLBasic 11, I suppose)
Some other fixes have been done, like repair a problem with the dock/multitasking bar in iPad or importing files from attachments (for example) under iOS (it needs that GLBasic programmers add some params in the info.plist of the project)
;)
I happy for test it. I have a iCade and have that implemented in greedy mouse. I do not have access to beta yet, so what to download for fix?
But very great work!!!
Quote from: DaCarSoft on 2012-May-17
Here are the news:
Rounded corners: FIXED!
iCade related problems with wrappers: FIXED!
iCade problem when entering in background should be fixed also... If anyone have an iCade please tell us how it goes (the fixes still have to be implemented in GLBasic 11, I suppose)
Some other fixes have been done, like repair a problem with the dock/multitasking bar in iPad or importing files from attachments (for example) under iOS (it needs that GLBasic programmers add some params in the info.plist of the project)
;)
BRAVO!
:good:
Quote from: spacefractal on 2012-May-17
I happy for test it. I have a iCade and have that implemented in greedy mouse. I do not have access to beta yet, so what to download for fix?
But very great work!!!
I think that you will need Beta 11 or maybe final GLBasic 11 version, Gernot have to include the changes in it. I suppose Gernot will tell us when will be all OK and how to proceed.
then I want the beta version so I can test this as well Android Surface issues. I have PM but have not got back yet (but I guess its sooner or later).
I got the new iPad recently and today looked around this issue (far now only tesed on the new iPad with full Retina resoulution, and also on iPad 1 too).
If I use portrait mode, then I see the corners, but if I turn to landscape mode using iOSSetOrientation function, then there is no corners. Also I did not even seen any linecross or misplaced iCade Window at all (also I have only tested with early glbasic beta v11.
Include functions.mm (zipped due forum limit) to your xcode project (mm file can been renamed), and you can call the function by this:
SETORIENTATION ORIN
?IFDEF IPHONE
IMPORT "C" int iOSSetOrientation(const char*)
IF ORIN=0 THEN iOSSetOrientation("portraitnormal") // portrait renamed to portraitnormal to prevent calling portraitupsidedown too.
IF ORIN=3 THEN iOSSetOrientation("landscapeleft")
IF ORIN=2 THEN iOSSetOrientation("portraitupsidedown")
IF ORIN=1 THEN iOSSetOrientation("landscaperight")
?ENDIF
Im gonna think this is a nice temporary fix until Gernot release v11 (which also fix the noticeable center issue as well). So if you have a landscape mode game, make sure to use both landscapeleft and landscaperight as well.
PS. I hope DaCarSoft, its was ok I included your function here, which I used from your posted test project. So I wont take credits about this, but all credits to DaCarSoft.
[attachment deleted by admin]
Hi Spacefractal :)
It's OK... thanks for the credits ;)
As I told, I fixed the bug for Gernot, and I think it should be totally fixed when GLBasic 11 will appear.
Using that code to force the screen rotation you would continue having problems like having that line across the screen under certain conditions, I think... I don't remember exactly my results, but I tested it hard :P... I think that sometimes the line could appear again depending on the device orientation when you launches the App or if the user blocks the orientation in certain positions, or changes the device orientation with your App in background mode... I remember some problems with certain XCode wrappers also... but YES, in general, the wrapper for setting the iOS orientation can be used until GLBasic 11 be published :booze:
As least I could not force the line bug here in greedy mouse (even forced with screen lock, that does nothing in the game, but should detect that). Corners was not even shown in landscape mode, only in portrait.
So it's must been happens with contain Xcode as well older iOS combo and resolution set and code?
Greedy Mouse is howover designed to accept any resolution as default, both portrait and landscape.
That's great to hear you helped Gernot fix the iCade support problem, DaCarSoft!
I have been away from these forums for a good few months.
As I understand it, the fix you have come up with still enables GLBasic to support the iCade internally form within GLBasic, reading the joystick values the same as we are at present yes?
Great work guys!
The problem was related to an invisible view/window needed for the iCade to let it work as a keyboard replacement. Before the fix, that window had a couple of visible rounded corners, and could be rotated by iOS erroneously under certain conditions, showing then its borders or corners on the top of the GLBasic's view.
I forced that Window to be totally invisible.
I also made some additional fixes to let iOS bottom/multitasking bar auto-rotate behind the GLBasic application... It's to say: You can rotate the device, press home twice, and see the bottom bar appearing in the correct position according your device orientation... it was always in portrait orientation before... Then, you only have to change your GLBasic's game orientation from within GLBasic's code by reading the accelerometers values... If you want... :P
Depending on the final Gernot's implementation in GLBasic 11, I could publish some code or a library (a simple ".a" file to include into your XCode project) to let GLBasic's programmers to control this orientation changes depending on the user iOS "lock" option or physical "lock" button state to avoid all orientation changes on the device... It's to say: If the user blocks the orientation in portrait or landscape you can block your orientation also to not rotate the screen of your GLBasic's game (only under iOS).
And yes, I have not an iCade device for testing, but it should continue working properly in the same way as now after these fixes ;)
:booze:
if you ask me, you could upload the a library, since I not think the source code is really needed and its property easier to import them for using undtil v11 used.
I have not noticed the taskbar issue.
As I have wrote before I can test that (but I could not invoke the linecross issue here) for iCade, iPad 1 and iPad 3 combo and testing the in Greedy Mouse (which can use that device and in any orientation and resoulution) and give some feedback.
Hi again!
My library needs the fixes into GLBasic 11. We have to wait until GLBasic 11 be published, unfortunately.
Regards.