Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Testing 1075 on Windows, Android, iOS and Mac

Author
Message
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 25th May 2012 00:52
1075 on Windows, Android, iOS and Mac

Well I've tested my Tier1 app and a couple of test Tier1 apps in Windows, on my Mac, iPod Touch, iPad 2 and Vizio Android. The iOS and Android tests were done without using players. Vizio connect to Windows PC via USB and started up from Eclipse. The iOS devices connected via their cable and started up from Xcode.

The beauty of directly connecting for the initial running of an iOS/Android app is that it leaves the entire app on the device and you can run it anywhere without being connected to anything. (I got a great 'ooh! ahh! looks addicting!' reaction showing an early iPod version to someone that way.)

I am happy to report that the GetCurrentDate() and GetCurrentTime() functions are working perfectly on everything.

The ads also worked properly in landscape mode on all devices. Displaying the ad in the lower left and accepting the clicks there as well and going to a browser as appropriate.

Text input (using StartTextInput, GetTextInputCompleted and GetTextInput) worked fine in all orientations. Although, in the Android, when I hit a wrong button and ended up in another app, when I returned to the AppGameKit one, the keyboard was gone and tapping in the input area did not bring it back up. (Sounds like a case for checking for return to focus.) I did not test that on the iOS devices, yet. I'll try that later.

Sadly, trying to execute directly from the AppGameKit IDE still causes problems when you try to close the app.

A couple of things did not work as they had before or as expected.

The game I used for testing is designed to play in one orientation, landscape, and you may not flip it once the game starts. So, within the Tier1 code I execute the command 'SetOrientationAllowed(0,0,1,0)'. In Xcode, for both iPad and iPhone/iPod, I set the 'Supported Device Orientations' to only landscape right. On the Android, I tried both the default value 'fullSensor' and 'landscape' for android:screenOrientation in the AndroidManifest.xml file.

In version 1074, everything worked except the position for the click area on iOS and Android devices.

In version 1075, the results are mixed.

On all but the Android, once we got to the main menu, the game ran perfectly.

On the Android, the accelerometer commands 'GetDirectionX()' and 'GetDirectionY()' were reporting as if the tablet were being held in portait mode. Tilting away from me sent the player flying to the right instead of up. Tilting to the right, sent it going down instead of right.

On the Android, Windows and Mac, the default/splash screen displayed as though it thought it was in portrait mode, sort of. The images are both landscape oriented and they appeared squished in the middle of the display. On the iPad, the initial (default.png) image displayed correctly, but the AGKsplash.png squished up somewhat. On the iPod, it all went perfectly.

So, overall most of the issues I tested appear to be okay.

But there is a big problem with the accelerometer directions when not in normal portrait mode.

Not so good with the initial orientation thinking it is portrait, even when it isn't.

Cheers,
Ancient Lady
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 25th May 2012 01:08
That is an excellent and detailed report. Thank you!

Maybe what we need is a simple test suite to check out the input and aspect ratio issues

-- Jim
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 25th May 2012 01:20
Thank you. I try to be thorough.

It helps having so many toys to play with.

Cheers,
Ancient Lady
Rich Dersheimer
AGK Developer
14
Years of Service
User Offline
Joined: 1st Jul 2009
Location: Inside the box
Posted: 25th May 2012 01:47
Ancient Lady, testing right from Xcode sounds great. When you add some code to your program and the bytecode changes, or add a new resource (image, file, whatever), do you simply put the stuff in the project folder, overwriting any older files? Or do you have to delete it and re-add it to your project?

I'd like to start testing from Xcode myself. I have a similar set of toys, PC, Mac Mini, iPod Touch, iPad 2, Kindle Fire, and an HTC Droid phone. I'm going for a release on iOS first, then I'm going to try and figure out the Android stuff.
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 25th May 2012 02:05
Yup. Just copy the stuff over, add any new resources and rebuild.

Since you have a Mac Mini (like me) and an iPad an iPod, you have almost everything you need. You just need to sign up as an iOS developer with Apple ($99/year), download Xcode 4, and work through the magic stuff.

TGC is working on updating the iOS guide for Xcode 4. If you need the Xcode 4 version, I have one I worked out (and have shared with TGC).

The initial setup for Xcode and Android is a bit of a bear to get through. But only needs to be done once.

And then you get the fun of keeping them up to date with the AppGameKit updates. With the Mac, if you drag/copy a directory into one that already has that name, it completely wipes out anything in it instead of just overwriting. So you have to be careful not to wipe out your projects on the Mac when updating the core AppGameKit stuff.

Happy Programming!

Cheers,
Ancient Lady
DVader
20
Years of Service
User Offline
Joined: 28th Jan 2004
Location:
Posted: 25th May 2012 02:19
Ancient Lady, did your app use offsetviewport at all? If so did the app still click ok? That is one thing that is missed that is causing me issues. In my Obliterator game, I had no issues as the screen doesn't actually move at all.

Rich Dersheimer
AGK Developer
14
Years of Service
User Offline
Joined: 1st Jul 2009
Location: Inside the box
Posted: 25th May 2012 02:43
DVader, my project uses offsetviewport a lot, and in 1074, I have no problems with it.

Ancient Lady, yah, I'm already signed up as a developer, Xcode installed, and I'm using your excellent instructions for Xcode 4!
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 25th May 2012 03:03
DVader, no offsetviewport.

Basic display setup:


Rich Dersheimer, I hope you have fun. I've been getting a kick out of seeing stuff run in so many platforms. I'm glad my instructions have helped.

Cheers,
Ancient Lady
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 25th May 2012 18:15 Edited at: 25th May 2012 18:17
Just to show how the displays are being squished in v1075. They all behaved just fine in v1074.

This is what the default and splash look like as just an image (960x640, iPhone retina):


This is what it looks like on my iPod Touch (correct):


And this is what the main menu looks like (for reference to the iPad version):


On the ipad, the initial (default) image fills the screen and is cut a bit on the right (as would be expected given the ratio difference). The splash screen shows up a bit funny:


But the game display is good (with the black borders above and below as expected given the difference in actual display area versus the game's setup):


Now for the really squishy ones. In all of them, the game display is fine.

In Windows:


On the Mac (I figured out how to make the Mac app window be exactly the right size for my game):


On the android (it's a very shiny surface, so getting a good image was hard):


The name of the game may change. It evolved during development from the original concept. The opening screens will definitely change.

Cheers,
Ancient Lady
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 25th May 2012 18:17 Edited at: 25th May 2012 18:18
Quote: "'GetDirectionX()' and 'GetDirectionY()' were reporting as if the tablet were being held in portait mode"


The accelerometer commands are modified internally so that they will always produce a value relative to your current orientation. For example GetDirectionY will always return the tilt from the top to the bottom of your app, and GetDirectionX will be left to right, whether you are in landscape or portrait.

Quote: "the default/splash screen displayed as though it thought it was in portrait mode"


I'm aware of some issues with the AGKSplash.png but I think we're moving away from this and suggesting the device splash screens like Default.png and adding a splash in user code if you want a separate splash screen.
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 25th May 2012 18:20 Edited at: 25th May 2012 18:23
Quote: "The accelerometer commands are modified internally so that they will always produce a value relative to your current orientation. For example GetDirectionY will always return the tilt from the top to the bottom of your app, and GetDirectionX will be left to right, whether you are in landscape or portrait."


I know that is how it's supposed to work. And it worked fine in every version from 1065 (my first full install) through 1073.

But in 1074, it does not work properly on my Android device in 1074. It works fine on my iPod and iPad.

And my AGKSplash.png file is the same as the default-landscape.png.

Again, this worked fine prior to 1074.

I will be happy when the default splash screen is no longer required to do away with the white flash.

Cheers,
Ancient Lady
DVader
20
Years of Service
User Offline
Joined: 28th Jan 2004
Location:
Posted: 25th May 2012 18:48
Ancient Lady, have you tried using getdirectionangle? I use it with no problems for all directions, even when locking to landscape. I found get direction working on x axis, but seemed locked on the y.
Rich Dersheimer, Odd I have has all sorts of issues with it on android. My app is forced into landscape mode, and also scrolls in all directions using the viewoffset command. In my Obliterator game, I also lock into landscape, but do not scroll the screen at all. That was working okay. I think it is a combination of landscape and offsetting the screen co-ords that has been causing the off ad issues until now.

Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 25th May 2012 19:05
I think I know what may be causing it, previous versions had a calibration.cfg file stored on the sdcard for the accelerometer. Now that we're using native orientations this is no longer needed and would interfere with the new method. If you copy the latest Core.cpp from AGK\IDE\apps\interpreter_android\jni into your app (in fact all the files in that folder should probably be copied every update) then it will no longer check the calibration file.
Impetus73
12
Years of Service
User Offline
Joined: 28th Aug 2011
Location: Volda, Norway
Posted: 25th May 2012 19:19
Poor Paul, struggling to please us all! I wish there were a list of files you changed since last update, so we know what files to copy to existing projects. When you change the manifest file, remember that we have different manifest files for all our project, so it would be nice to know if there are any changes we have to do to them. I guess you change like maybe 30 files of the 6969 files in an AppGameKit installation on small updates. Would be great to get a ZIP file with ONLY the MODIFIED files, that way we would never wonder what files we would have to update.

----------------
AGK user - novice
Did Amiga / AMOS programming in the 90's, just started programming again with AGK.
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 25th May 2012 20:00
Doh! palmtoforehead

My script wasn't right, so it copied the jni files to the wrong place.

I fixed the script, reran, cleaned and rebuilt, uploaded/ran via Eclipse.

No joy, same result.

I had updated the app to display the results of GetDirectionAngle. In windows it gives nice pure results with the arrow keys.

On my iPad it gave consistent results for orientation and angle.

On my Android, it showed values consistent with being in portrait orientation even when in landscape.

As far as I can tell, there is no calibration.cfg file on the sd card.

Sorry it took so long to respond. I still haven't gotten my main work machine able to use Eclipse to connect to the android and had to go to my 'home' machine to test everything.

Cheers,
Ancient Lady
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 25th May 2012 20:20
Quote: "I'm aware of some issues with the AGKSplash.png but I think we're moving away from this and suggesting the device splash screens like Default.png and adding a splash in user code if you want a separate splash screen."


Really?

FANTASTIC news!!!

This is the right way to go TGC!

lots of
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 25th May 2012 20:25
Paul does this mean that the calibration screen at the very start on Android + the calibration data file on the SDcard are now unnecessary?
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 26th May 2012 01:17
Quote: "does this mean that the calibration screen at the very start on Android + the calibration data file on the SDcard are now unnecessary?"


Yes, the only time it was necessary was when the accelerometer was installed upside down, which I've only seen happen in one device. So now I'll just write in exceptions for those devices as and when they appear. And since it won't affect orientation any more it seems better to do it this way.

Quote: "On my Android, it showed values consistent with being in portrait orientation even when in landscape."


And if you use SetOrientationAllowed(1,0,0,0) instead the accelerometer works as expected?
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 26th May 2012 02:34 Edited at: 26th May 2012 02:38
I have not tried changing the SetOrientationAllowed command.

If I have to set it to portrait only, then my landscape only app won't work.

As I've said before, it worked in 1074 without any calibration.

I tried it with SetOrientationAllowed(1,0,0,0) and I get the same behavior playing it in portrait mode. It is strangely still reporting X/Y and angle rotated 90 degrees (that best describes it).

Very strange.

Cheers,
Ancient Lady
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 26th May 2012 03:16 Edited at: 26th May 2012 03:18
Okay, I formatted the sd card on the Android device and created a new program with an different package name.

The program is exactly this:


When I hold the device in portrait mode and start the application, it switches instantly to landscape and will not change and the displayed values are rotated 90 degrees.

Oh, and in between every single test on the Android, I uninstall the old application.

Cheers,
Ancient Lady
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 26th May 2012 03:38
Do you have access to the LogCat output from the device? It will output some debug info when AppGameKit starts, it looks something like this

R: 8, G: 8, B: 8, A: 8, D: 16, W: 0, F: 1, S: 8 (in yellow)
model name (in red)
model name 2 (in red)
Width: 1280 Height: 752 (in yellow)
Screen Long: 1 (in yellow)

There may be other lines in between but those are the lines I'm after. In particular the "Screen Long" value determines whether the device reports itself as a tablet or phone and flips the accelerometer 90 degrees since to make things confusing Android devices have their accelerometer so that Y is up in the native orientation of the device, tablets being landscape, phones being portrait.

Quote: "it worked in 1074 without any calibration"


If there was definitely no calibration.cfg file in /sdcard/AGK or /mnt/sdcard/AGK then that is very strange as the only way I can explain it currently is if the calibration files was feeding it the corrected values.
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 26th May 2012 04:06
I'll look into seeing if I can get to the LogCat output.

I'm 'turning off' my computer brain for the night and indulging in some movies.

I'll work on this in the morning.

Thank you.

Cheers,
Ancient Lady
Alien Menace
AGK Developer
19
Years of Service
User Offline
Joined: 11th Jan 2005
Location: Earth (just visiting)
Posted: 26th May 2012 09:22 Edited at: 26th May 2012 09:23
Hi Ancient Lady,

Have you posted your xcode 4 guide somewhere? I cannot get the ios player built. My build will run fine in the simulator and even run broadcasted code with no warnings or errors, however when I try to install on my iPad3, it pops up then immediately quits. Lots of warnings during the build as well. I had no problem building 1065 but since 1070, I just can not get it to work.

Cheers.

Apps published: 3
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 26th May 2012 18:25 Edited at: 26th May 2012 18:25
It's been posted in a various places, which I don't remember.

One I can find quickly is in the google list:
http://code.google.com/p/agk/issues/detail?id=322&sort=-id

Cheers,
Ancient Lady
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 26th May 2012 20:47
Well, apparently there are lots of apps for reading logcat.

But, since it is my hubby's device, I need to let him pick the one he wants me to install.

Cheers,
Ancient Lady
Rich Dersheimer
AGK Developer
14
Years of Service
User Offline
Joined: 1st Jul 2009
Location: Inside the box
Posted: 26th May 2012 22:09 Edited at: 26th May 2012 22:12
I love the way we're getting these little clues about your game!

And since you showed us yours, I'll show y'all mine...




Still a WIP, but it won't be long now...

Attachments

Login to view attachments
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 27th May 2012 00:00
I got a logcat viewing app installed. Fortunately it lets you pause so that you can look through it.

Unfortunately, I could not find any messages like the ones mentioned.

When I manually flipped the device about, the message 'Screen orientation has changed' appears. But that line and the ones after don't give information about orientation mode. A couple of lines show the new resolution in a sorta way while allocating something. But none of the values related to the actual orientation.

So, I made a fresh app in Tier1 and created a brand new android app from the interpreter_android file (image set for download):


If I establish the device as being in portrait-normal, run something else, exit, leave the device sitting flat and start the test, then it views and reports orientation 1.

Gently tilting to left and it eventually switches to reporting orientation 2 but doesn't actually change orientation. And, it should report orient 3 or 4 for a landscape mode. A sharp tilt to the left actually does change the view to orient 3, but still reporting 2.

Similar not quite right display versus reporting happens when gently tilting or sharply tilting at various angles.

The X/Y/angle values reported sort of correctly for the reported orientation.

I reinstalled 1074, replaced all the appropriate directories in the android setup to make sure everyone using the right stuff, clean and rebuild.

As long as I was gentle, it would show the correct orientation for the viewing orientation and the X/Y/angles were good. 'Gentle' means clean orientation by simple tilt in one direction at a time.

So, the only difference is 1075 vs 1074.

Unfortunately, 1074 doesn't handle the ad touch placement properly, otherwise I'd just stay with that version.

Cheers,
Ancient Lady

Attachments

Login to view attachments
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 27th May 2012 00:02
I found in the java code where the logcat messages mentioned should be generated, but they did not appear in the log when the test app is run. Or at any other time.

Cheers,
Ancient Lady
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 27th May 2012 00:11
1074 still used the emulated & fake orientation.

Moving to real native orientation is the best option. I think it needs more fixing & tweaking to get it perfect, but in the long run its the best option... no more upside down message boxes, etc...
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 27th May 2012 00:19
I agree. But it needs to work.

Cheers,
Ancient Lady
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 27th May 2012 00:22
I think with the help & input of everyone they will get it right in the next update
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 27th May 2012 00:57 Edited at: 27th May 2012 00:58
I have total faith in them.

I think they are actually doing something pretty fantastic getting bits to work across so many platforms.

Way back when, I could do serious custom graphics programming at the bios level on PCs because all PCs had the same bios.

As we got access to more and better, it became harder for everyone to support everything.

EDIT: Last post for the day. I just opened a new bottle of Proseco (and it is a good one!). I am not allowed to drink and phone/text/email/post.

Cheers,
Ancient Lady
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 27th May 2012 04:06
Quote: "I found in the java code where the logcat messages mentioned should be generated, but they did not appear in the log when the test app is run. Or at any other time."


It may be that the AppGameKit player is never quitting and starting back up, which is when the messages are generated, instead it is just going to the background and resuming. Try the power button on the standby screen to restart the app and see if the messages appear on the next run.

Quote: "Gently tilting to left and it eventually switches to reporting orientation 2 but doesn't actually change orientation. And, it should report orient 3 or 4 for a landscape mode. A sharp tilt to the left actually does change the view to orient 3, but still reporting 2."


This is interesting and sounds like the cause, so you're saying the device itself doesn't change orientation even though AppGameKit reports a new orientation value?

Note that the orientation notices in the LogCat output are from Android and only report 1 (landscape) and 2 (portrait) on tablets and may be vice versa for phones.
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 27th May 2012 20:31
I'm executing the application directly on my android without using a player.

And I uninstall/reinstall the app on the android between tests.

And I exit the app by tapping on it and that invokes the 'end' command and the app ending shows up in the log. It shows up as 'Process com.triassicassociates.show_orient (pid xxxx) has died'.

With 1075 there was not a lot of consistency. It would start in orientation 1 and then report orientation 3 with only a slight tilt towards current bottom edge, but the orientation wouldn't actually change. It was hard trying to get consistent bad behavior. But it would not show the expected orientation for how it was held.

With 1074 doing the emulation, the displayed and reported orientation are correct for how the device is held. And the X/Y papers were good.

Cheers,
Ancient Lady
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 28th May 2012 14:48
SetSpriteSnap is not working on 1075 on Windows. did not check other platforms

Reverted to 1074 and the command works fine there.
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 28th May 2012 17:08
bjadams, if you can provide a simple app that would demonstrate the problem, I will try it on the other platforms (Mac, iOS, Android).

Cheers,
Ancient Lady
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 28th May 2012 17:44
I have already posted sprite images in another thread and how they are appearing wrongly:

http://forum.thegamecreators.com/?m=forum_view&t=196688&b=41

this is the right way the images should appear:



On 1074 I had to set SetSpriteSnap on for this to happen.

In 1075 no matter what sprites appear chopped off:

Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 28th May 2012 17:55
I just tested the accelerometer app previously posted on my iPod and iPad2. 1075 worked flawlessly. It reported the correct orientation, the x/y/angle values were correct and it flipped to new orientations correctly.

So, the accelerometer issue appears to be Android specific.

Cheers,
Ancient Lady
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 29th May 2012 01:22 Edited at: 29th May 2012 01:22
Quote: "So, the accelerometer issue appears to be Android specific."


If you use the attached files to replace the ones in your project does it fix the problem? They read the orientation state from the device instead of relying on the accelerometer. I've set it correctly for landscape devices (tablets) but I've guessed the parameters for portrait devices (phones) as I don't have an Android phone to test.

I've also updated the Android beta player in the downloads section if anyone else wants to test it before the next version.

Attachments

Login to view attachments
MikeMax
AGK Academic Backer
12
Years of Service
User Offline
Joined: 13th Dec 2011
Location: Paris
Posted: 29th May 2012 04:25 Edited at: 29th May 2012 04:37
Paul, with your latest beta version (the one uploaded the 28th may), if i start the player in portrait mode, the SetOrientationAllowed( 0, 0, 1, 1 ) force the rotation of the display in landscape mode (correct behavior) but with portrait's ratio (incorrect behavior !)... as if it had been started in portrait mode and manually rotated after... and i have always considered that this command should force the device to "virtually" rotate the device before the first sync and limit the rotation after .. (as it works on iOS player (the command is at the first line of my app).

EDIT : tested on android 3.2 (samsung tablet) and android 2.3 (Samsung phone Galaxy Ace).. Same problem.

Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 29th May 2012 17:03
Quote: "if i start the player in portrait mode, the SetOrientationAllowed( 0, 0, 1, 1 ) force the rotation of the display in landscape mode (correct behavior) but with portrait's ratio (incorrect behavior !)"


Are you using SetVirtualResolution() to some landscape values such as 800,600 to fix the aspect ratio? SetOrientationAllowed by itself will not change the ratio. You could also use SetDisplayAspect(1.5) if you are using percentage coordinates.
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 29th May 2012 17:26
Paul, I'll download the file later and see what happens.

MikeMax's image shows the same kind of behavior I've described.

The images I posted earlier show that the AppGameKit base assumes you must be in portrait mode and doesn't recognize that the device is in landscape mode.

I've tried calling the SetOrientationAllowed(0,0,1,0) as the very first line of code, followed by Sync(). But it doesn't seem to make a difference.

Is there a way to add to the setup.agc file a status about what orientation to start in and allow? This would help on Windows, at any rate. But we need some way for the Mac/Android/iPad ones.

The Android projects use a manifest file that does set some bits related to orientation, but they don't seem to translate well into the finished product.

Cheers,
Ancient Lady
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 29th May 2012 17:46
Okay, my post got lost, let's try again.

Paul, I will try downloading the file later today (I'm doing VPS maintenance right now).

MikeMax's image illustrates the behavior I also see with 1075 (but not 1074).

The AppGameKit base seems to assume you start in Portrait orientation.

We need some way to indicate to the interpreter that it should be starting (or assuming) a specific orientation. Or the ability to force it as soon as the app starts (SetOrientationAllowed as the first line in the Tier1 code does not work to do this).

Cheers,
Ancient Lady
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 29th May 2012 22:30
Quote: "MikeMax's image illustrates the behavior I also see with 1075"


SetVirutalResolution or SetDisplayAspect should solve what you are seeing.
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 29th May 2012 22:58
I added 'SetVirtualResolution(960,640)' and 'SetDisplayAspect(1.5)' as the very first commands in main.agc (before anything else).

Doesn't change the initial display issue as evidenced by the windows and mac squished images previously posted.

I'm going 'home' from my 'office' now. A grueling walk of about 25 feet.

I'll download the file you put up and see what happens on the android. I cannot get Eclipse to recognize it on my 'work' computer, so I test it from my 'home' computer.

Cheers,
Ancient Lady
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 29th May 2012 23:56
Paul, I copied the AGKHelper.java file into the android\IDE\apps\<myapp\src\com\thegamecreators\agk_player directory for my main game and for my orientation tester.

And I copied Core.cpp into the jni directory for each app.

Clean, rebuild, run from Eclipse (and standalone once installed by Eclipse).

For my game, same squished image on start up and the same problem with reported X/Y/angle (90 degrees off).

And the same problems with the orientation tester. It would report orient 3 when in orient 1 and the angles would be okay until the device was actually tilted to orient 3. And, changing the orientation every few seconds, testing angles, eventually caused the program to abort.

Cheers,
Ancient Lady
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 30th May 2012 02:05
Quote: "Clean, rebuild, run from Eclipse (and standalone once installed by Eclipse)."


Including a rebuild with cygwin?

Quote: "same squished image on start up"


If this is with AGKSplash.png I recommend moving the splash screen to the start of your code just after setting the virtual resolution.

Quote: "And the same problems with the orientation tester. It would report orient 3 when in orient 1"


Is this a tablet or phone, and what reference are you using to say it should have been reporting orient 1?

Quote: "eventually caused the program to abort."


Do you have the LogCat from when it crashed?
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 30th May 2012 02:33
1. Specifically cleaning and building in cygwin.

2. Yes, the AGKSplash.png, which is soon to be deprecated, hopefully in the next update that won't require one if you want to do without the white splash. Because, no matter when you put your own image in now, the AppGameKit base still looks for the splash file and delays even when it isn't there.

3. I'm using a tablet. Orientation 1 is supposed to be portrait normal. And when I flipped it to a landscape mode, it reported orientation 2.

4. I didn't think to look at the logcat output. It may not have actually crashed, because I cannot repeat it. I must have tapped the screen while turning it.

Cheers,
Ancient Lady
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 30th May 2012 03:10
It sounds like you may have a device that doesn't follow the android spec with regards to reporting its native orientation and accelerometer settings. The only way to find out would be to perform some tests on the values it is reporting, if you're up for that?

Firstly we need to know the value of g_pIsTablet in Core.cpp, this could be done by adding the following code



Just before App.Loop(); on line 401 of Core.cpp

Secondly we need to print out the raw accelerometer values which can be done from setaccel() in Core.cpp (there are some commented lines for debug output in there already but they are not ideal as they only update about 10 times a second so flash on screen repeatedly). Specifically we need to know whether the Y direction corresponds to holding the device in a portrait or landscape orientation.

With those two things I should be able to see what's going on.
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 30th May 2012 04:55
I'm sorry Paul, I didn't see your post earlier. I am about set to retire for the night (and need to get computers off my brain, hard, but necessary for sleep).

I will work on this first thing in the morning (my time US east coast) and post what I see.

Cheers,
Ancient Lady

Login to post a reply

Server time is: 2024-05-03 13:52:39
Your offset time is: 2024-05-03 13:52:39