Menu

Show posts

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

Show posts Menu

Messages - jaywat

#31
Announcements / Re: V8 beta
2010-Aug-25
Ok. I'm a bit confused. So GLB_ON_PAUSE executes its code, then returns to your main code? But, certainly to be consistent cross platform, you should definitely not do a SHOWSCREEN anywhere (an iPhone app is killed off if it attempts to draw to screen when it doesnt have focus) ... so I'll have to implement a completely seperate 'lostfocus' routine in addition to my 'normal' pause routine, because that of course shows the 'paused-click to continue' type stuff and SHOWSCREENs.

But the thing is, in my experience, if you have ANY kind of loop WITHOUT a showscreen, that can kill your app too.... so my original question remains... what do I *do* while paused, even if I'm going to do it outside those subs, even if I want to do nothing but wait for the app to resume so I can display stuff again?

For example. Here's some really simple test code as a basic framework to include losing and regaining focus... except it crashes (app becomes non-responsive under Windows)... it never resumes from pause (and of course I can't step through it to debug!). So what should I be doing instead?

Just to clarify my point about a loop crashing if no showscreen... IF you add SHOWSCREEN to the lostFocusLoop in this code, it no longer crashes under Windows... except that's no good to me at all on an iPhone, because that WILL crash it!

Code (glbasic) Select


GLOBAL a%
GLOBAL b%
GLOBAL hasLostFocus%

mainLoop:

WHILE TRUE
IF hasLostFocus = FALSE
INC a%
PRINT a%,0,0
PRINT b%,0,20
SHOWSCREEN
ELSEIF hasLostFocus = TRUE
GOTO lostFocusLoop
ENDIF
WEND

lostFocusLoop:

WHILE hasLostFocus = TRUE
INC b%
WEND

GOTO mainLoop

SUB GLB_ON_RESUME:
hasLostFocus% = FALSE
ENDSUB

SUB GLB_ON_PAUSE:
hasLostFocus% = TRUE
ENDSUB
#32
Announcements / Re: V8 beta
2010-Aug-24
Quote from: MrTAToad on 2010-Aug-24
As far as I can tell, it looks like the program will stay in a suspension loop once the pause routine has finished.  It might be best to treat these like ON_QUIT and not do any graphics or such like once called.

I would agree this makes sense for GLB_ON_PAUSE, but I would have thought the point of GLB_ON_RESUME was that the program has resumed execution now, and therefore it would be entirely reasonable to display a 'click to resume' screen or something. I mean, ok, I can set a 'hasResumed' flag in GLB_ON_RESUME and jump to a pause screen from elsewhere in the code, but still, it seems that really, GLB_ON_RESUME actually HASNT resumed when it fires, or surely a SHOWSCREEN wouldnt have such dire consequences for your app?

The reason for doing the code example I did is because it's most close to what I actually want to do. That is: on an iPhone, I want to support PAUSE and RESUME from multi-tasking. Which, by the looks of it, for a straight PAUSE/RESUME, I literally wouldn't need to execute any code, other than save the game state.

Why even do that? Well, what if they put it into pause (ie, multi-tasking bar) and then never resume the app, but kill it instead? I can't save if they never resume. So I want to save on pause, and IF there's a savestate file, reload ONLY when the app is restarted afresh, NOT on RESUME. Although since GLB_ON_RESUME is called when the app is started fresh, I explicitly have to code round that.

That's not to mention that iPhone seems to treat ANY exit as a pause, rather than a quit, if the device is multi-tasking capable.

I think I still *could* do right now, assuming it works on iPhone. Just got to be extremely careful about how I code it to not do any of the things that will crash the app!
#33
I've posted extensively on my experiences of using GLB_ON_PAUSE and GLB_ON_RESUME in the newly released 8.078 in the announcement thread here, complete with test code that highlights some of the problems I've discovered.

I think there are definitely some issues at the moment, and at the very least we need some clarification of what is or isn't acceptable to put in these new subs.
#34
Announcements / Re: V8 beta
2010-Aug-24
Editing my post about 6th or 7th time...

Kitty, I've been testing GLB_ON_PAUSE and GLB_ON_RESUME which you implemented per my bug report here.

First: unlike GLB_ON_QUIT, typing the sub name in lowercase isn't automatically being converted to upper case and recognised, but assuming you put them in upper case, they're being recognised.

Also, these subs don't get called when in debug mode. Is that by design for some reason?

Now, my main issue is, what am I supposed to PUT in GLB_ON_PAUSE?

Here's why I'm asking: With my test code on windows, I successfully put it into pause, but then the app would absolutely not come out of pause. So much so, that using task manager to shut it wouldn't. I managed to shut GLBasic Editor, but the app was still open! No amount of convincing task manager would close it, all it did was bring the app window back up, albeit the title still said <paused>. Worse still, it limited my mouse movement to some little corner of the screen. In the end, I had to reboot my pc!

Now, I *think* I may know why...

in my GLB_ON_PAUSE, after writing a timestamp to a log file, I did:

WHILE TRUE

HIBERNATE

WEND

Because I figured I had to *do* something while paused... but as we know, using SHOWSCREEN while the app is a background task on iPhone kills the app stone dead. But I forgot that if you write a while loop with no showscreen, it tends to kill the app (didn't know if you knew that? always happens to me). And that's why I think my app killed itself so badly - it was paused, but crashed, and could neither continue execution nor be made to exit. Mind you, it'd really help if it could be made that if I screw up the code that badly it didnt require a reboot to continue!

I'm about to try it without a while loop at all. I'll update here in a few minutes or longer if I have to reboot again! :p

EDIT 4: Ok. If you put a while loop in GLB_ON_RESUME *with* showscreen, the app hangs before it ever starts (I wanted to print 'press a key to continue...' or whatever)

So, my test code atm, JUST writing a log file with a time stamp when I pause, when I resume and when I quit is working fine, but it hangs quite nastily if GLB_ON_PAUSE or GLB_ON_RESUME has any kind of loop.


[EDIT 5: Ok, the mouse problem reoccurred when I tried to circumnavigate the problem with using a while loop in GLB_ON_RESUME by using a PRINT, SHOWSCREEN then MOUSEWAIT instead. It seems to create problems. The mouse cursor gets locked to a part of the screen, and at the same time, it exhibits the same crash problem. Basically, SHOWSCREEN in GLB_ON_RESUME is a definite no-no - it causes the app to crash before it even executes the first time, and apparently so is MOUSEWAIT.  Also, GLB_ON_RESUME is being called the instant the app starts (and failing if I have a loop in there).]

I think I can work round that by setting flags and testing the code elsewhere, but (a) some clarification on what you can and cant do with GLB_ON_RESUME and GLB_ON_PAUSE would be nice, and (b) if you can, prevent nasty hang protection if I do something I shouldn't in code!

Does GLB_ON_PAUSE only fire once and halt at the end of code execution within it? therefore I don't need any kind of loop? And after GLB_ON_RESUME, the app would continue from where it left off? If so, in practice, I don't need ANY code, if I just want to pause and resume from where I was? Right?

If that's not how they work, please explain! Thanks.

Even if that is how they work, I think there's a few problems with them atm.

[EDIT... whatever... I've lost count... :

Oh hang on... because of how it's explained in the user manual, I assumed that GLB_ON_RESUME and GLB_ON_PAUSE were only called *IF* AUTOPAUSE TRUE was set... but that's not the case. They're being called ANYWAY. So it may be the combination of AUTOPAUSE and having SHOWSCREEN/MOUSEWAIT that's screwing things up. But I digress... I'll await some responses from Kitty!]

-----

Here's some lame but useful test code, especially since you cannot debug these new SUBs. It includes 3 commented out ways to kill your app (and possibly your pc...), and also conclusively proves that GLB_ON_RESUME is being called BEFORE the app starts the first time through. Do feel free to try with and without AUTOPAUSE TRUE set, too!

Code (glbasic) Select

AUTOPAUSE TRUE
GLOBAL logfile$
GLOBAL pause$
GLOBAL resume$
GLOBAL quit$
GLOBAL time$
GLOBAL hasResumed


logfile$ = PLATFORMINFO$("DOCUMENTS") + "/logfile.dat"

start:

getDetails()

hasResumed = FALSE // if you remove this, you'll see that hasResumed, which is only set TRUE in GLB_ON_RESUME, is true when the app is first executed.
WHILE TRUE
IF hasResumed = TRUE
PRINT "Successfully resumed!",0,0
ENDIF
showDetails()
SHOWSCREEN
WEND


FUNCTION getDetails:

INIOPEN logfile$
pause$ = "PAUSE LOG: " + INIGET$("PAUSE","PAUSE")
resume$ = "RESUME LOG: " + INIGET$("RESUME","RESUME")
quit$ = "QUIT LOG: " + INIGET$("QUIT","QUIT")
INIOPEN ""

ENDFUNCTION


FUNCTION showDetails:

LOCAL logExist

logExist = DOESFILEEXIST(logfile$)

IF logExist = FALSE
PRINT "NO LOG FILE!",0,20
ELSEIF logExist = TRUE
PRINT "LOG FILE FOUND...",0,20
PRINT "Results of last test...",0,40
PRINT pause$,0,70
PRINT resume$,0,100
PRINT quit$,0,130
ENDIF

ENDFUNCTION


SUB GLB_ON_RESUME:

time$ = MID$(PLATFORMINFO$("TIME"),11,-1)
INIOPEN logfile$
INIPUT "RESUME","RESUME","GLB_ON_RESUME @ " + time$
INIOPEN ""

hasResumed = TRUE


// NEVER, EVER DO THIS!!!!
// PRINT "I have successfully resumed from pause!",0,0
// PRINT "Touch to resume...",0,20
// SHOWSCREEN
// MOUSEWAIT



// AND NEVER, EVER DO THIS!!!

//WHILE TRUE
// PRINT "I have successfully resumed from pause!",0,0
// PRINT "Touch to resume...",0,20
// SHOWSCREEN // testing showscreen called WITHIN resume.... nope, that doesnt work!
//WEND

getDetails()

ENDSUB

SUB GLB_ON_PAUSE:

hasResumed = FALSE
time$ = MID$(PLATFORMINFO$("TIME"),11,-1)
INIOPEN logfile$
INIPUT "PAUSE","PAUSE","GLB_ON_PAUSE @ " + time$
INIOPEN ""


// WATCH, WHILE I KILL YOUR APP DEAD...

// WHILE TRUE
// HIBERNATE
// WEND

ENDSUB

SUB GLB_ON_QUIT:

time$ = MID$(PLATFORMINFO$("TIME"),11,-1)
INIOPEN logfile$
INIPUT "QUIT","QUIT","GLB_ON_QUIT @ " + time$
INIOPEN ""

ENDSUB
#35
Looking forward to the update - I've already written a bunch of test code :)

Does it safeguard against doing a showscreen while GLB_ON_PAUSE, or is it a case of 'never use showscreen while paused or your app will crash!'. If the latter, I'd suggest this is made very clear in the user manual.

#36
I have made a bug report here, since this problem affects ALL glbasic apps built for and running under OS4, where they will crash on an iPhone or iPod supporting multi-tasking, which I think makes it a fairly major bug, even if no one else seems very interested.  ;/
#37
I'm making a thread about this here because although I've extensively covered the findings of a days testing in another thread, I didn't want the point or the implication to get lost or diluted.

Simply put, ALL glbasic applications (as far as I can tell) built for iPhone OS4 and deployed for 3.x, which I believe is Apple's requirement for acceptance, will crash on exit on any iPhone or iPod that supports multi-tasking (ie, a very large number of devices). In doing so, GLB_ON_QUIT is never called. The implication of this, of course, is that any state saving or tidying up you try and do on exit never happens.

Under OS4, any device supporting multi-tasking apparently ALWAYS puts the app to the background when you exit, whether you exit normally, or exit to the multi-tasking bar. Glbasic apps, though, seemingly  cant recognise that it's a background task and will try to illegally write to the screen with SHOWSCREEN, and generates an application error, "background gpu access not permitted", which results in the application crashing immediately without executing any further code.

From the Apple documentation:

QuoteDo not make any OpenGL ES calls from your code. You must not create an EAGLContext  object or issue any OpenGL ES drawing commands of any kind. Using these calls will cause your application to be terminated immediately.

This is the same for GLB7 and GLB8. The same code used for testing does indeed quit successfully when compiled and built for OS3 only, but of course that isn't really the point, other than to demonstrate that this is a problem with glbasic and OS4.

I also noted in the other thread that I had tried both with and without 'AUTOPAUSE TRUE' with the same results. I also noted that using HIBERNATE to halt showscreen calls wasnt really an option because it causes the application screen to flash to black every time we update the screen.

Admittedly, testing isn't made easy by the fact I have to send code to Mike to compile for xcode, run on a device I don't have access to,  and then watch the results by screensharing or video ;)

I'd really appreciate if this could be looked at as soon as possible; for us, at least, it's pretty much a 'show stopper'; and that includes our just released app getting an update... not only can we not support pause and resume, but we can't even code our own save and load. And if you haven't had this problem, then thats just because you haven't released an app or update since OS4!
#38
Quote from: Slydog on 2010-Aug-17
New subroutines may need to be added to GLBasic, and/or the existing 'GLB_ON_QUIT' be modified to be called even on being suspended to the background. 
But then you would need a corresponding 'GLB_ON_RESUME' or something. 
Or, I think you can force an app to only quit, and not multi-task, when pressing the button.

I think you are probably right, and I'd really consider this a priority fix request. Firstly, because we have customers are crying out for this functionality in my app.  But mostly because as far as I am aware, when iOS4 for the iPad is released, you will HAVE to build your apps for OS4 as a condition of acceptance. Deploying for OS3 is only allowed now so you can develop for iPad.

I'm actually quite surprised that our apps are getting accepted considering that they're only actually exiting by virtue of the fact they crash (on a multi-tasking capable device).
#39
It seems there might be a more fundamental problem here with glbasic apps on a multi-task capable iPod/iPhone. It's not just down to setting AUTOPAUSE.

The error I mentioned before, that it's trying to write to the screen while it's a background task, happens anyway. This causes the app to error (see the thread I linked) and then immediately terminate when it's brought back to the foreground.

The thing is, it seems a device that DOES have multi-tasking puts an app to the background EVEN if you exit 'normally' with a single tap of the Home button. What this means in practice from all my testing so far is that GLB_ON_QUIT never fires. At all. Ever.

If your device doesnt support multi-tasking, it works like OS3, and therefore GLB_ON_QUIT fires.

Which means that not only can we not support resume, but I can't even write a save state/load state function myself that will work on a newer iOS4 device.

I'm almost inclined to believe that, for some reason I can't fathom, I'm wrong about this... because surely some of you guys have games that utilise GLB_ON_QUIT and you would have been deluged with complaints of saves and stuff not working if that was the case?!

By the way, this is true of glb7 and glb8.

Kitty, do you want me to summarise this in Bug Reports or anything? If what my testing indicates is true, it's quite a big problem!
#40
The error we're getting in xcode debugger is:

sgx error (background gpu access not permitted):
Program received signal: "SIGABRT"

Which sounds to me like it's attempting a showscreen once it's lost focus, and can't.

I tried using HIBERNATE to prevent it doing that in the main loop, since the next thing we're expecting is a user touch, but unfortunately, we get a very noticeable flash to black of the whole screen when using this command, so unless we could solve that issue, it wouldn't even be worth trying.

Not trying to teach anyone to suck eggs, but I wondered if the following thread might help?

http://www.cocos2d-iphone.org/forum/topic/7326

Kitty, if you have skype or something, Mike could show you what's happening on a multi-tasking device by video if it's of use?
#41
Quote from: Kitty Hello on 2010-Aug-16
OK, thanks. Can the iPad do Multitasking in 3.2? I might be able to test that then.

As far as I know, no. Not until iPad gets upgraded to 4
#42
After some testing with multi-tasking on a later generation iPod Touch which supports multi-tasking, we have found that 'autopause true' causes the following behaviour:

IF you switch between our glbasic app and another running app, and switch back to it, it works. Our game continues where it left off.

However, if you switch from our app to another app and CLOSE that other app then switch back to our app, the app immediately quits.

Which, presumably, means that this is precisely what it would do when put on hold to receive a call on an iPhone, because you would exit the phone app on finishing the call. We're currently trying to get this tested on an iPhone, and I'll update our findings if we are able.
#43
Sorry if this has been asked before - couldn't find an answer anywhere.

We've had it pointed out that our game does not support resume on an iPhone (after a call interrupts a game or whatever), and that this is an essential feature.

It's not something I can easily test, unfortunately, so I'd like to know how the iphone deals with this, and how glb interprets that. Does the app simply loses focus and therefore 'autopause true' would solve this problem? Or does it essentially exit the app, calling glb_on_quit, and therefore I'd need to implement a save state and reload everything?

And while I'm asking, is multi-tasking on iOS4 the same or different? ie, if someone double-taps and starts a different app, does it lose focus? can i make my glb app 'os4 multi-task capable'?

#44
Our new game, Stacked Sevens, has just hit the iTunes app store for 99 cents. We're hopeful that a Friday 13th release date won't bring us any bad luck :)

I had already posted the details in the appstore thread a few days ago, which I've just updated with our  iTunes store link.

We're very pleased with the game, both in terms of coming up with what we think is a really engaging and original puzzle game, yet feels instantly familiar, and with the overall look and feel. Stacked Sevens is our second release, and our attempt to go a bit more 'mainstream' after our first glb game Hungry Birdz (also on the appstore thread).

We're always interested in feedback, if any of you guys are willing to give it a go.
#45
^ what he said :)