I don’t know if any of the principles here looked at my proposal (I know
everybody is doing this on their limited free time and I thank
everybody, so I don’t mean to sound like I’m pressuring anything.)
If doing an actual patch would help, I can do that, and hopefully see if
that might move things along.
I know it’s a new API and those things aren’t to be taken lightly, but
I’m willing to take a shot at the patch.
I’m actually pretty happy with SDL 1.3. The only thing that stops me
from using it on the OS X/win32 version is relative mouse movement
(unless that fixed and I didn’t check!)
I don’t know if any of the principles here looked at my proposal (I know
everybody is doing this on their limited free time and I thank
everybody, so I don’t mean to sound like I’m pressuring anything.)
I read it, but hadn’t replied; my apologies for that.
In a perfect world, I would like this to become a standard SDL event and
not a callback; is it not reasonable for SDL to catch
-[UIApplicationDelegate applicationWillResignActive] and turn it into an
event? It seems to me that there’s a window between where you get this
message and when -[UIApplicationDelegate applicationDidEnterBackground]
is triggered.
If that’s not possible, a callback isn’t the worst thing in the world,
but I’d like to treat this like any other system event if we can.
I don’t know if any of the principles here looked at my proposal (I
knowOn Thu, 17 Nov 2011 23:01:01 -0500, “Ryan C. Gordon” wrote:
everybody is doing this on their limited free time and I thank
everybody, so I don’t mean to sound like I’m pressuring anything.)
I read it, but hadn’t replied; my apologies for that.
In a perfect world, I would like this to become a standard SDL event and
not a callback; is it not reasonable for SDL to catch
-[UIApplicationDelegate applicationWillResignActive] and turn it into an
event? It seems to me that there’s a window between where you get this
message and when -[UIApplicationDelegate applicationDidEnterBackground]
is triggered.
If that’s not possible, a callback isn’t the worst thing in the world,
but I’d like to treat this like any other system event if we can.
The only thing that I’d definitely favor becoming a callback is the SDL_QUIT delivered on iOS and Android via such weird longjmp trickery.On 11/17/2011 08:07 PM, Vijay Varadan wrote:
+1
On Thu, 17 Nov 2011 23:01:01 -0500, “Ryan C. Gordon” wrote:
I don’t know if any of the principles here looked at my proposal (I
know
everybody is doing this on their limited free time and I thank
everybody, so I don’t mean to sound like I’m pressuring anything.)
I read it, but hadn’t replied; my apologies for that.
In a perfect world, I would like this to become a standard SDL event and
not a callback; is it not reasonable for SDL to catch
-[UIApplicationDelegate applicationWillResignActive] and turn it into an
event? It seems to me that there’s a window between where you get this
message and when -[UIApplicationDelegate applicationDidEnterBackground]
is triggered.
If that’s not possible, a callback isn’t the worst thing in the world,
but I’d like to treat this like any other system event if we can.
–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier
I don’t know if any of the principles here looked at my proposal (I know
everybody is doing this on their limited free time and I thank
everybody, so I don’t mean to sound like I’m pressuring anything.)
I read it, but hadn’t replied; my apologies for that.
In a perfect world, I would like this to become a standard SDL event and
not a callback; is it not reasonable for SDL to catch
-[UIApplicationDelegate applicationWillResignActive] and turn it into an
event? It seems to me that there’s a window between where you get this
message and when -[UIApplicationDelegate applicationDidEnterBackground]
is triggered.
If that’s not possible, a callback isn’t the worst thing in the world,
but I’d like to treat this like any other system event if we can.
That’s not the problem, though depending on there be or always being the right window of time seems like the best way to introduce future crashes in your application if iOS changes.
The problem is your app needs to be dead to the world when it’s suspended. There are specific things you can do, but just running an event loop isn’t one of them as it has no purpose. In SDL, you have to poll for events. When it goes to the background, it needs to stop doing things. It needs to only wake up and go back into an event loop when you get that message, and the only way to do that is a callback.
The same with low memory; iOS will terminate your application if you don’t free memory when you get that, and, again, you shouldn’t be polling or running loops at that time.
BTW, I completely understand the desire to want to keep this in the event queue, but there are fundamental differences in mobile OSes then your regular PC OS.
Hi Brian,
Actually you dont need to do that
Here’s the patch which implements such kind of events - I did them because
I needed them for iOS, but they are generic enough to be used on any other
systems.
The patch implements a new call:
SDL_SetSystemEventHook(SDL_SystemEventHandler handler)
and a new event (SDL_SystemEvent) and 4 event types:
SDL_SYSEVENT_TERMINATE - system wants to terminate app
SDL_SYSEVENT_SUSPEND - system wants to suspend app
SDL_SYSEVENT_RESUME - system wants to resume app
SDL_SYSEVENT_LOWMEMORY - low memory warning
This is exactly what I what I was proposing, and better yet, somebody has already done it Any change this could become part of the core?
Hi,
Would be good In the next couple of weeks I’ll be looking into Android
and if possible I’ll add support for this functionality also for Android.
regards,
PiotrOn Mon, 28 Nov 2011, Brian Barnes wrote:
Piotr wrote:
Hi Brian,
Actually you dont need to do that
Here’s the patch which implements such kind of events - I did them because
I needed them for iOS, but they are generic enough to be used on any other
systems.
The patch implements a new call:
SDL_SetSystemEventHook(SDL_SystemEventHandler handler)
and a new event (SDL_SystemEvent) and 4 event types:
SDL_SYSEVENT_TERMINATE - system wants to terminate app
SDL_SYSEVENT_SUSPEND - system wants to suspend app
SDL_SYSEVENT_RESUME - system wants to resume app
SDL_SYSEVENT_LOWMEMORY - low memory warning
This is exactly what I what I was proposing, and better yet, somebody has already done it Any change this could become part of the core?
Great! Please send me a note when you add Android support and I’ll put it
into the repo.
Thanks!On Wed, Nov 30, 2011 at 3:54 PM, Piotr Drapich wrote:
Hi,
Would be good In the next couple of weeks I’ll be looking into Android
and if possible I’ll add support for this functionality also for Android.
regards,
Piotr
On Mon, 28 Nov 2011, Brian Barnes wrote:
Piotr wrote:
Hi Brian,
Actually you dont need to do that
Here’s the patch which implements such kind of events - I did them
because
I needed them for iOS, but they are generic enough to be used on any
other
systems.
The patch implements a new call:
SDL_SetSystemEventHook(SDL_SystemEventHandler handler)
and a new event (SDL_SystemEvent) and 4 event types:
SDL_SYSEVENT_TERMINATE - system wants to terminate app
SDL_SYSEVENT_SUSPEND - system wants to suspend app
SDL_SYSEVENT_RESUME - system wants to resume app
SDL_SYSEVENT_LOWMEMORY - low memory warning
This is exactly what I what I was proposing, and better yet, somebody
has already done it Any change this could become part of the core?
BTW, relative mouse motion is fixed on OS X, but not on Windows yet.On Wed, Nov 16, 2011 at 10:25 AM, Brian Barnes wrote:
I don’t know if any of the principles here looked at my proposal (I know
everybody is doing this on their limited free time and I thank everybody,
so I don’t mean to sound like I’m pressuring anything.)
If doing an actual patch would help, I can do that, and hopefully see if
that might move things along.
I know it’s a new API and those things aren’t to be taken lightly, but I’m
willing to take a shot at the patch.
I’m actually pretty happy with SDL 1.3. The only thing that stops me from
using it on the OS X/win32 version is relative mouse movement (unless that
fixed and I didn’t check!)
BTW, relative mouse motion is fixed on OS X, but not on Windows yet.
Great! When the windows version hits, I’ll flip the switch in dim3 and retest everything in both iOS/Windows. dim3 should be completely SDL 1.3 the minute I can verify those pieces work correctly, and I’ll be abandoning 1.2. When the iOS patch is finalized, I’ll go back and test that, too, and give you my report.
The only problem with the callback approach is that it has potential
reentrancy issues. Currently SDL jumps through a bunch of hoops to allow
you to control the event loop, instead of providing a callback interface.On Fri, Nov 18, 2011 at 1:57 PM, Brian Barnes wrote:
Ryan wrote:
I don’t know if any of the principles here looked at my proposal (I know
everybody is doing this on their limited free time and I thank
everybody, so I don’t mean to sound like I’m pressuring anything.)
I read it, but hadn’t replied; my apologies for that.
In a perfect world, I would like this to become a standard SDL event and
not a callback; is it not reasonable for SDL to catch
-[UIApplicationDelegate applicationWillResignActive] and turn it into an
event? It seems to me that there’s a window between where you get this
message and when -[UIApplicationDelegate applicationDidEnterBackground]
is triggered.
If that’s not possible, a callback isn’t the worst thing in the world,
but I’d like to treat this like any other system event if we can.
That’s not the problem, though depending on there be or always being the
right window of time seems like the best way to introduce future crashes in
your application if iOS changes.
The problem is your app needs to be dead to the world when it’s suspended.
There are specific things you can do, but just running an event loop isn’t
one of them as it has no purpose. In SDL, you have to poll for events.
When it goes to the background, it needs to stop doing things. It needs
to only wake up and go back into an event loop when you get that message,
and the only way to do that is a callback.
The same with low memory; iOS will terminate your application if you don’t
free memory when you get that, and, again, you shouldn’t be polling or
running loops at that time.
BTW, I completely understand the desire to want to keep this in the event
queue, but there are fundamental differences in mobile OSes then your
regular PC OS.
While suspension notifications on iOS come in two flavours (‘will’ and
’did’) the first of which lends itself to event handling, low memory
situations are time critical, like system interrupts they need to be
handled right away. I don’t see any way of getting around callbacks in this
case.On Thu, Dec 29, 2011 at 9:48 AM, Sam Lantinga wrote:
The only problem with the callback approach is that it has potential
reentrancy issues. Currently SDL jumps through a bunch of hoops to allow
you to control the event loop, instead of providing a callback interface.
On Fri, Nov 18, 2011 at 1:57 PM, Brian Barnes wrote:
Ryan wrote:
I don’t know if any of the principles here looked at my proposal (I
know
everybody is doing this on their limited free time and I thank
everybody, so I don’t mean to sound like I’m pressuring anything.)
I read it, but hadn’t replied; my apologies for that.
In a perfect world, I would like this to become a standard SDL event and
not a callback; is it not reasonable for SDL to catch
-[UIApplicationDelegate applicationWillResignActive] and turn it into an
event? It seems to me that there’s a window between where you get this
message and when -[UIApplicationDelegate applicationDidEnterBackground]
is triggered.
If that’s not possible, a callback isn’t the worst thing in the world,
but I’d like to treat this like any other system event if we can.
That’s not the problem, though depending on there be or always being the
right window of time seems like the best way to introduce future crashes in
your application if iOS changes.
The problem is your app needs to be dead to the world when it’s
suspended. There are specific things you can do, but just running an event
loop isn’t one of them as it has no purpose. In SDL, you have to poll for
events. When it goes to the background, it needs to stop doing things. It
needs to only wake up and go back into an event loop when you get that
message, and the only way to do that is a callback.
The same with low memory; iOS will terminate your application if you
don’t free memory when you get that, and, again, you shouldn’t be polling
or running loops at that time.
BTW, I completely understand the desire to want to keep this in the event
queue, but there are fundamental differences in mobile OSes then your
regular PC OS.
The only problem with the callback approach is that it has potential
reentrancy issues. Currently SDL jumps through a bunch of hoops to allow
you to control the event loop, instead of providing a callback interface.
These are pretty large system events, and I’d suspect the system is waiting for a return, which means there should never be a re-entrancy problem. You’d actually have a worse problem putting it on a queue because you’d be basically be telling the system that “It’s handled” (you’d put it on the queue and return from the system event) when in fact, it’s more than likely it’s not handled.
If you don’t get this done in the right amount of time, your app will crash as attempting to use the GPU in the background is a no-no.
The other big problem, something I pointed out earlier, is that the “memory low” and “wake up” messages need to happen when you app no longer functions. It’s also a big no-no to run an event loop. You have a limited number of background things you can run. You are just wasting battery and what happens when the phone goes to sleep? iOS says only specific things can run, and one of them is NOT the event loop
With the callback, your app is dead to the world (as it should be) taking no CPU time, and only wakes up when it gets a call. A callback is the only way to accomplish that.
First, I’m kinda sleep-deprived, so my wording and logic may be a little wonky.> Date: Wed, 28 Dec 2011 20:48:16 -0500
From: Sam Lantinga
To: SDL Development List
Subject: Re: [SDL] Can I do a patch for iOS system callbacks?
Message-ID:
Content-Type: text/plain; charset=“iso-8859-1”
The only problem with the callback approach is that it has potential
reentrancy issues. Currently SDL jumps through a bunch of hoops to allow
you to control the event loop, instead of providing a callback interface.
Unfortunately, sometimes that doesn’t work (the ‘free memory’ command
mentioned below, for example). I’ve been thinking about using this
sort of thing myself (I’m planning to add GUI support to a virtual
machine so I can use it as a programmable window manager, but PWM
events coming into effect before they can be processed worries me).
Also, sometimes having a separate mechanism can be convenient. With
PWM events, you could use callbacks to run support code (you might
even need to do something like restart sub-systems on some platforms,
though having to restart SDL itself is something that the app would
probably need to hook into directly) immediately after
resumption/restart/etc., so that the event handling code is always
assured that some things are true when it gets run (e.g., my planned
GUI extension can ensure that windows exist and textures are
uploaded). If you then want the message to be perpetuated to the event
system you simply return some particular value from the callback (I’d
say 1, but, whatever makes sense).
Put any API to set callbacks in a special header file called
"advanced_api.h", and programmers should be sufficiently warned that
they’re playing with fire (because, after all, this shouldn’t be a
first choice). The callbacks would be dealt with as a user extension
to the event system (because, really, it’s just another way to control
the event loop). Ideally they would be able to call the event-message
functions, but if not then the wiki would simply need to document that
(again, fire).
Put any API to set callbacks in a special header file called
"advanced_api.h", and programmers should be sufficiently warned that
they’re playing with fire (because, after all, this shouldn’t be a
first choice). The callbacks would be dealt with as a user extension
to the event system (because, really, it’s just another way to control
the event loop). Ideally they would be able to call the event-message
functions, but if not then the wiki would simply need to document that
(again, fire).
I’m asking this from a place of complete ignorance, so excuse me if what I
ask is completely dumb. What’s the problem with handling critical iOS
callbacks directly in the final app, bypassing SDL? In Android thing are
different for sure, for example, I kinda solved the pause/resume problem by
faking it as a window show/hide event. In the app, when the window is
hidden i slow down the event loop to one iteration per second, and you have
to be aware that when resuming you may lose the previous GL context and
have to recreate the textures.
My point is that these callbacks may not be easily generalized to other
platforms, and if they are only required for iOS, it may be simpler for SDL
to pretend that they don’t exist and let the final user handle them in
their own way.–
Gabriel.
The mechanism that delivers the notification is handled by SDL. We need to
subvert SDL’s cocoa scaffolding in order to handle the event. In my case I
apply a little patch to SDL sources before I compile to lib.
You do raise a valid possibility however. We could use each systems native
event distribution, in the case of cocoa, we could post an
@“SDLGotLowMemory” event to a notification center, and only subscribed
listeners would get a ‘callback’. Overall this sits rather poorly with me
however, for reasons of inconsistency and sleepyheadedness :)On Thu, Dec 29, 2011 at 8:38 PM, Gabriel Jacobo wrote:
Put any API to set callbacks in a special header file called
"advanced_api.h", and programmers should be sufficiently warned that
they’re playing with fire (because, after all, this shouldn’t be a
first choice). The callbacks would be dealt with as a user extension
to the event system (because, really, it’s just another way to control
the event loop). Ideally they would be able to call the event-message
functions, but if not then the wiki would simply need to document that
(again, fire).
I’m asking this from a place of complete ignorance, so excuse me if what I
ask is completely dumb. What’s the problem with handling critical iOS
callbacks directly in the final app, bypassing SDL? In Android thing are
different for sure, for example, I kinda solved the pause/resume problem by
faking it as a window show/hide event. In the app, when the window is
hidden i slow down the event loop to one iteration per second, and you have
to be aware that when resuming you may lose the previous GL context and
have to recreate the textures.
My point is that these callbacks may not be easily generalized to other
platforms, and if they are only required for iOS, it may be simpler for SDL
to pretend that they don’t exist and let the final user handle them in
their own way.
