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 / App Game Kit 108 Beta 18

Author
Message
SoftMotion3D
AGK Developer
19
Years of Service
User Offline
Joined: 24th Aug 2005
Location: Calgary,Alberta
Posted: 29th Aug 2013 14:54
it does work

but I was hoping to get the setorientationallowed to work correctly.

I can definitely get it to start in the correct orientation but it still seemed to flip.

Thanks for your help as it looks like I may need to use that method

Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 29th Aug 2013 16:11
SMD_3D Interactive, it is not impossible that the Blackberry and iOS share a common issue.

AGK's understanding of which way the landscape modes go and the iOS understanding were reversed. It became a simple fix of changing a couple of lines in one the the iOS files (and TGC implemented this after I pointed it out a few times).

In the SetOrientationAllowed help page, it defines the landscapes this way:
Quote: "landscape - The landscape orientation when the device is rotated left from its default position.
landscape2 - The landscape orientation when the device is rotated right from its default position.
"


But the way it implemented for iOS somehow had it flipped, or just misunderstood. Orientation 4 was actually the iOS LandscapeLeft and orientation 3 was actually the iOS LandscapeRight.

Try using the other landscape value in your SetOrientationAllowed command and see if it stays stable.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
SolusHunter
13
Years of Service
User Offline
Joined: 18th May 2011
Location: Kent, United Kingdom
Posted: 30th Aug 2013 13:01
I think there is something very wrong with the Game Center commands (T1) in beta 17.

The GameCenterLogin() command doesn't do anything, no popup is displayed for logging in and checking the state with getGameCenterLoggedIn() always returns 0.

GameCenterSetup() has been called prior to using the commands, and getGameCenterExists() returns 1.

AGK 108 (Backed v2)
Windows 8 x64
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 30th Aug 2013 20:48
Well, the GetResumed() command sort of works in Windows. It is triggered when you return to the app after it loses focus.

However, the app continues to run, even after it loses focus, so GetResumed() is not so good for pausing a game.

My WIP is time based, and the timer keeps running when the app loses focus. Then it pauses when returned, but the time is now way higher than it should be.

We need something that catches when a Windows or Mac app is losing focus.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
xGEKKOx
AGK Master
15
Years of Service
User Offline
Joined: 7th Dec 2008
Location: Italy
Posted: 31st Aug 2013 02:28
Well on iOS/Mac is really simple to do. i done it.

Long life to Steve!
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 31st Aug 2013 04:28
xGEKKOX, you are the genious for this stuff. I do not plan to publish in Windows, but would like to publish in Mac. Can you help me with the code for this. Thank you in advance.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Lucas Tiridath
AGK Developer
16
Years of Service
User Offline
Joined: 28th Sep 2008
Location: Kings Langley, UK
Posted: 31st Aug 2013 09:29
Quote: "We need something that catches when a Windows or Mac app is losing focus."

I'm not sure if this is what you need but for Nexus, I modified the Core.cpp file so that the game pauses when it loses focus. I'm sure with a little adaption, you could use this method to catch the pause and do something, but personally I just pause the game and sort everything out afterwards when GetResumed() fires. The modifications I made were as follows.

1. Add

under globals for core

2. In the WM_ACTIVATE case, replace with the following code


3. Set the line with App.Loop() to


I hope that helps.

Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 31st Aug 2013 16:44
Lucas, does that catch it as soon as it loses focus?

It might be what I am looking for, or at least close.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
xGEKKOx
AGK Master
15
Years of Service
User Offline
Joined: 7th Dec 2008
Location: Italy
Posted: 31st Aug 2013 16:56
Of course Lady.
I done this kind of code because Apple reject an app if you close a window and you need to click 2 times on the window below to get focused.

Is really simple.

In the same way you can make focus or focus from background a window with
[[NSApp mainWindow] makeKeyWindow];

Anyway, if you give a look to the NSApp and NSWindow documentation, you can see that you can do very much things. In fact in this case we don't need to touch the windows as GL window, but just get it as NSApp mainWIndow.
You can move it on front, back, change dimension, etc.

Long life to Steve!
Lucas Tiridath
AGK Developer
16
Years of Service
User Offline
Joined: 28th Sep 2008
Location: Kings Langley, UK
Posted: 31st Aug 2013 18:41
Quote: "Lucas, does that catch it as soon as it loses focus?"

Well as far as I can tell, the WM_ACTIVATE event fires as soon as the window loses focus (or regains it). I should note that I'm working with a fullscreen app so you should test it on a windowed one to be sure, but I'm pretty sure it will work. As a result, the gamePaused boolean is flipped and App.Loop() wont be called again until the focus is restored. You can obviously modify this to handle an event when gamePaused is flipped instead, I just found it easier to suspect App.Loop().

=PRoF=
21
Years of Service
User Offline
Joined: 17th Mar 2003
Location: Milton Keynes, UK
Posted: 1st Sep 2013 18:03 Edited at: 1st Sep 2013 19:30
Eek, nothing like publishing an app to discover weaknesses and bugs.

Apparently the EditBox doesn't work on Samsung's with XT9 predictive text input. (Reported by a user with a Galaxy Ace, and verified by me on a Galaxy Y, could be other makes/models but unable to test that right now. Can anyone else confirm?)

I wrote Ninja Name Generator with Beta 18 and created the APK using the online APK compiler tool.

>Edit<
Here is a code snippet to test it with...


Snippet tested on Galaxy Y using the Android Player and the same problem exists. It works if you turn the dictionary off, but if you enable it, you can no longer input text.

Ched80
14
Years of Service
User Offline
Joined: 18th Sep 2010
Location: Peterborough, UK
Posted: 1st Sep 2013 20:20
Is anyone else witnessing some weirdness with the touch commands in Win8?

I'll be a bit more specific.

The trouble is actually when running the game in windowed mode (i.e. not full screen). The touches register, but not in the same location as they do when the game runs full screen. It seems the co-ordinates don't quite translate when in windowed mode.

MarcoBruti
13
Years of Service
User Offline
Joined: 20th Nov 2011
Location: Caput Mundi
Posted: 3rd Sep 2013 19:24
as far as you know, is Beta18 the last beta for AGKv1? Will it be transformed into stable release?
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 3rd Sep 2013 19:33
Quote: "as far as you know, is Beta18 the last beta for AGKv1?"

I certainly hope not, since some things don't work quite right.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Digital Awakening
AGK Developer
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Sweden
Posted: 3rd Sep 2013 20:51
Not all bugs will be fixed in 108 though. 109 has been mentioned, but that's for later as Paul need to focus on v2.

baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 3rd Sep 2013 22:30
The impression I get is that once all the more important bugs are fixed in V1 then it will be released officially, then Paul will start work on V2 as a separate entity.

I'm pretty sure it won't take long as most (if not all) of the more important bugs seem to be fixed anyway...

"Everything should be made as simple as possible, but not simpler."
=PRoF=
21
Years of Service
User Offline
Joined: 17th Mar 2003
Location: Milton Keynes, UK
Posted: 5th Sep 2013 19:51
Hmm, after a little testing, it seems only 2 of the devices tested with the Predictive text/edit box issue have problems, A Samsung Galaxy Ace and a Samsung Galaxy Y, both running Android 2.3.n (Gingerbread) and I assume the same version of XT9 dictionary.

It looks to me as though it is a problem with AGK's edit boxes and Gingerbread devices, but I'd like some confirmation before I post a bug report.

Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 5th Sep 2013 20:41
I have no trouble with the edit boxes on my Philips GoGear Connect 3.2 with Android 2.3.3 (the '3.2' refers to screen size).

But then it doesn't try to do any predictive text. The basic text entry/edit works fine.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
=PRoF=
21
Years of Service
User Offline
Joined: 17th Mar 2003
Location: Milton Keynes, UK
Posted: 5th Sep 2013 20:59 Edited at: 5th Sep 2013 21:12
@Ancient Lady - The problem goes away when you turn off the predictive text. You can usually toggle it on/off from the menu that appears when you press the settings button on the On Screen Keyboard. (It was off on my Galaxy Y by default, so I didn't notice the bug prior to publishing my app).

>Edit<
Just to clarify..
This is a definite bug with Agk edit boxes. They work fine with predictive text off, but don't work with it on.

This has been tested and verified on a Samsung Galaxy Y and a Samsung Galaxy Ace (Both using same os and XT9 dictionary)

It has been tested and not found on my Tab 2 7.0, A Galaxy S3 mini, and my friends Sony Experia (All running Android 4.n)

I was wondering what other devices it affected before submitting a bug report

Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 5th Sep 2013 21:37
There are no settings anywhere on the Philips GoGear that even hints at predictive text. I can turn on/off sound/vibrate and lots of other stuff. But nothing with predictive text.

I tested in my Nexus 7 (Android 4.2.2), with auto correction on and with suggestions on and I couldn't get it to offer me anything when I was typing in EditBox fields.

Can you post a simple test that shows the issue and maybe we can get others to try on their devices?

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Paul Johnston
TGC Developer
22
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 6th Sep 2013 01:38
I can replicate the predictive text bug but I can't see a way to fix it. The keyboard is not sending any key press events when predictive text is on and I can't see a way to turn it off just for AppGameKit apps.
=PRoF=
21
Years of Service
User Offline
Joined: 17th Mar 2003
Location: Milton Keynes, UK
Posted: 6th Sep 2013 11:33
@Paul Johnston:
That is slightly disappointing, is there no way for you to collect the words it suggests? I have little or no knowledge of how these things actually work.

JimHawkins
15
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 6th Sep 2013 12:57
There's probably a way to switch the (awful) predictive text off.

-- Jim - When is there going to be a release?
baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 6th Sep 2013 13:28
If it weren't for predictive text the internet would be slightly less amusing...

"Everything should be made as simple as possible, but not simpler."

Login to post a reply

Server time is: 2024-11-24 19:31:51
Your offset time is: 2024-11-24 19:31:51