iOS System Callback

Jared_Maddox · March 28, 2012, 2:49am

Message-ID: <4F71817E.9030807 at ngus.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

It also implements all important iOS events as SDL
events:

I sort of wonder if it’s a good idea expose the functionality by events
as well as it implies it is expected to work OK where in many situations
it won’t. It also means the same functionality is exposed in two
different ways; this may be confusing.

At the same time, there may be apps where it makes sense to separate
time-critical code & non-time-critical code. Can’t say that I know of
any, though (my backburner project likely won’t deal with the
time-critical bits correctly EVER, so… ). Can anyone think of any
cases where it would be useful to have both callbacks & events?> Date: Tue, 27 Mar 2012 09:59:42 +0100

From: Tim Angus
To: SDL Development List
Subject: Re: [SDL] iOS System Callback (attn: Piotr Drapich) (fwd)
On 27/03/2012 08:19, sdl at union.pl wrote:

Jeremy_Jurksztowicz · March 28, 2012, 3:47am

Your use of the words ‘time-critical’ hit the nail on the head.
Theoretically…

Perhaps some system might implement such events as signal handlers, which
would add a new synchronization element to handling them. In such cases
clients might not want to enter the murky waters of correct signal handling
and opt to wait for the nice message to be handled in a normal context on
the main thread.

You asked for an example, so I made one up

I feel as though we should avoid over-tailoring this patch to iOS, but I
still strongly suggest the callback mechanism, as it’s the only way to keep
the library out of the way of clients that want to get down to the metal. I
understand the confusion that might arise from having two delivery
mechanisms, but remember that the library already provides alternate ways
of doing the same thing (such as LoadWAV vs using rwops).

My 2 pennies.On Tue, Mar 27, 2012 at 10:49 PM, Jared Maddox wrote:

Date: Tue, 27 Mar 2012 09:59:42 +0100
From: Tim Angus
To: SDL Development List
Subject: Re: [SDL] iOS System Callback (attn: Piotr Drapich) (fwd)
Message-ID: <4F71817E.9030807 at ngus.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 27/03/2012 08:19, sdl at union.pl wrote:

It also implements all important iOS events as SDL
events:

I sort of wonder if it’s a good idea expose the functionality by events
as well as it implies it is expected to work OK where in many situations
it won’t. It also means the same functionality is exposed in two
different ways; this may be confusing.

At the same time, there may be apps where it makes sense to separate
time-critical code & non-time-critical code. Can’t say that I know of
any, though (my backburner project likely won’t deal with the
time-critical bits correctly EVER, so… ). Can anyone think of any
cases where it would be useful to have both callbacks & events?

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Brian_Barnes · March 28, 2012, 7:17pm

Let’s take these one at a time:

Jared wrote:

At the same time, there may be apps where it makes sense to separate
time-critical code& non-time-critical code. Can’t say that I know of
any, though (my backburner project likely won’t deal with the
time-critical bits correctly EVER, so… ). Can anyone think of any
cases where it would be useful to have both callbacks& events?

Jeremy wrote:

Your use of the words ‘time-critical’ hit the nail on the head.
Theoretically…

Perhaps some system might implement such events as signal handlers, which
would add a new synchronization element to handling them. In such cases
clients might not want to enter the murky waters of correct signal handling
and opt to wait for the nice message to be handled in a normal context on
the main thread.

You asked for an example, so I made one up

I feel as though we should avoid over-tailoring this patch to iOS, but I
still strongly suggest the callback mechanism, as it’s the only way to keep
the library out of the way of clients that want to get down to the metal. I
understand the confusion that might arise from having two delivery
mechanisms, but remember that the library already provides alternate ways
of doing the same thing (such as LoadWAV vs using rwops).

The bottom line is there’s no other way to do this. Apple requires
that this stuff be handled IN the callback. And more important than
that, after the callback exits, your code no longer receives any time!

You can’t handle it by polling later. You code is halted. So it has
to be in the callback.

These type of callbacks are, by their very nature, very system
independent. Ones of android, or any future system (windows phone, etc)
aren’t going to be necessarily the same. Instead of creating a
confusing call that says “on X it does Y on Z it does W” kind of thing,
make the calls specific to the OS that is catching them.

Vittorio wrote:

Finally, there other ways, like the one I mentioned, to respond to any
event you like, just by subclassing the SDL_UikitAppDelegate and
override the methods you are interested in.

But the point of SDL is to hide the implementation details and make
things as cross platform as possible. Actually overriding internal
structures and objects in a library is not the best way to go about
this. The callback is simple, clean, and best of all, future proof.

[>] Brian

RodrigoCard · March 29, 2012, 12:07am

Jared Maddox wrote:>

Date: Tue, 27 Mar 2012 09:59:42 +0100
From: Tim Angus
To: SDL Development List
Subject: Re: [SDL] iOS System Callback (attn: Piotr Drapich) (fwd)
Message-ID: <4F71817E.9030807 at ngus.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 27/03/2012 08:19, sdl at union.pl wrote:

It also implements all important iOS events as SDL
events:

I sort of wonder if it’s a good idea expose the functionality by events
as well as it implies it is expected to work OK where in many situations
it won’t. It also means the same functionality is exposed in two
different ways; this may be confusing.

At the same time, there may be apps where it makes sense to separate
time-critical code & non-time-critical code. Can’t say that I know of
any, though (my backburner project likely won’t deal with the
time-critical bits correctly EVER, so… ). Can anyone think of any
cases where it would be useful to have both callbacks & events?

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Handling it ALSO as an event could be useful.
For example, I could pause the game or prevent drawing the next frame (until the assest are reloaded, in case you dump all the textures in the willenterbackgorund ) when iOS returns control to the mainloop.

The main loop must be aware that the callback was called, posting these events as sdl events looks correct.

Jared_Maddox · March 29, 2012, 3:32am

Message-ID: <4F7363E0.70304 at charter.net>
Content-Type: text/plain; charset=“ISO-8859-1”; format=flowed

Let’s take these one at a time:

Jared wrote:

At the same time, there may be apps where it makes sense to separate
time-critical code& non-time-critical code. Can’t say that I know of
any, though (my backburner project likely won’t deal with the
time-critical bits correctly EVER, so… ). Can anyone think of any
cases where it would be useful to have both callbacks& events?

Jeremy wrote:

Your use of the words ‘time-critical’ hit the nail on the head.
Theoretically…

Perhaps some system might implement such events as signal handlers, which
would add a new synchronization element to handling them. In such cases
clients might not want to enter the murky waters of correct signal
handling
and opt to wait for the nice message to be handled in a normal context on
the main thread.

You asked for an example, so I made one up

I feel as though we should avoid over-tailoring this patch to iOS, but I
still strongly suggest the callback mechanism, as it’s the only way to
keep
the library out of the way of clients that want to get down to the metal.
I
understand the confusion that might arise from having two delivery
mechanisms, but remember that the library already provides alternate ways
of doing the same thing (such as LoadWAV vs using rwops).

The bottom line is there’s no other way to do this. Apple requires
that this stuff be handled IN the callback. And more important than
that, after the callback exits, your code no longer receives any time!

As far as my comment goes, it was about duplicating the callback into
the event queue. I have no problem with callbacks.

You can’t handle it by polling later. You code is halted. So it has
to be in the callback.

Remember how I mentioned time-critical vs non-time-critical? My
’backburner’ project is adding SDL support to a pre-existing virtual
machine. This virtual machine allows the programmer to act as if the
virtual machine never shuts down (time just magically passes faster
than normal, all connections fail, etc.). If I spend the effort to
adapt this to iOS (which is unlikely, since I don’t have one of the
devices) then I’ll obviously need to put code into one of the
callbacks to implement this…

However, the code running on the virtual machine should ALSO be
informed of this (example: so that it can figure out if it needs to
reload textures), and that realistically can (AND SHOULD) be relegated
to events.

Thus, two types of reaction to callbacks:

time-critical code that needs to run INSIDE the callback, and
non-time-critical code that can run anywhere as long as it eventually runs.

As for me asking whether anyone can come up with a use-case? I don’t
think I’ll be using this, so I don’t feel that I can JUSTIFY the
developer effort with my example. It may be informative, but I could
just as easily implement the events myself, and I probably won’t be
using the callbacks for this project regardless.

These type of callbacks are, by their very nature, very system
independent. Ones of android, or any future system (windows phone, etc)
aren’t going to be necessarily the same. Instead of creating a
confusing call that says “on X it does Y on Z it does W” kind of thing,
make the calls specific to the OS that is catching them.

I think you mean system-dependant. At any rate, I don’t know where
you’re going with this?

Vittorio wrote:

Finally, there other ways, like the one I mentioned, to respond to any
event you like, just by subclassing the SDL_UikitAppDelegate and
override the methods you are interested in.

But the point of SDL is to hide the implementation details and make
things as cross platform as possible. Actually overriding internal
structures and objects in a library is not the best way to go about
this. The callback is simple, clean, and best of all, future proof.

I heartily agree, callbacks are the correct way to do this.> Date: Wed, 28 Mar 2012 15:17:52 -0400

From: Brian Barnes
To: sdl at lists.libsdl.org
Subject: Re: [SDL] iOS System Callback

Date: Wed, 28 Mar 2012 17:07:25 -0700
From: “RodrigoCard”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] iOS System Callback
Message-ID: <1332979645.m2f.32436 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

Jared Maddox wrote:

Date: Tue, 27 Mar 2012 09:59:42 +0100
From: Tim Angus
To: SDL Development List
Subject: Re: [SDL] iOS System Callback (attn: Piotr Drapich) (fwd)
Message-ID: <4F71817E.9030807 at ngus.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 27/03/2012 08:19, sdl at union.pl wrote:

It also implements all important iOS events as SDL
events:

I sort of wonder if it’s a good idea expose the functionality by events
as well as it implies it is expected to work OK where in many situations
it won’t. It also means the same functionality is exposed in two
different ways; this may be confusing.

At the same time, there may be apps where it makes sense to separate
time-critical code & non-time-critical code. Can’t say that I know of
any, though (my backburner project likely won’t deal with the
time-critical bits correctly EVER, so… ). Can anyone think of any
cases where it would be useful to have both callbacks & events?

Handling it ALSO as an event could be useful.
For example, I could pause the game or prevent drawing the next frame (until
the assest are reloaded, in case you dump all the textures in the
willenterbackgorund ) when iOS returns control to the mainloop.

The main loop must be aware that the callback was called, posting these
events as sdl events looks correct.

So this makes sense to someone else, too? That’s good.

Vittorio_Giovara · March 29, 2012, 3:07pm

In my opinion, you are missing the “Simple” in “Simple Directmedia Library”…
If you need to do something so complex that forces you to

set up callbacks;
respond in quasi real time;
handle a variable number of events
you might as well just subclass the main delegate instead of
completely revolutionising the SDL chain.

Beware that I hardly believe the proposed implementation is future
proof, in fact as you know the events that need a fast action might
change with every ios release (like it happened from 3.x to 4.x).
I’m sure that subclassing+ovverriding can be adopted for android as well.

I’m not discreting the patch or the patch’s author, I’m just worried
about the possible implications and feature duplication.
Best,
VittorioOn Thu, Mar 29, 2012 at 5:32 AM, Jared Maddox wrote:

Date: Wed, 28 Mar 2012 15:17:52 -0400
From: Brian Barnes
To: sdl at lists.libsdl.org
Subject: Re: [SDL] iOS System Callback
Message-ID: <4F7363E0.70304 at charter.net>
Content-Type: text/plain; charset=“ISO-8859-1”; format=flowed

Vittorio wrote:

Finally, there other ways, like the one I mentioned, to respond to any
event you like, just by subclassing the SDL_UikitAppDelegate and
override the methods you are interested in.

But the point of SDL is to hide the implementation details and make
things as cross platform as possible. ?Actually overriding internal
structures and objects in a library is not the best way to go about
this. ?The callback is simple, clean, and best of all, future proof.

I heartily agree, callbacks are the correct way to do this.

Brian_Barnes · March 29, 2012, 6:23pm

Jared wrote:

As far as my comment goes, it was about duplicating the callback into
the event queue. I have no problem with callbacks.

Yes, I understand that, what I’m trying to tell you is that it just won’t work. You will NOT get some of these messages in the event queue; your program will be halted at that point. What you will get is the worse possible solution: player hits button, you get one event, code is halted, then you get (in a row) the “enter background” and “exit background” AFTER you have exited the background. This is bad and will only serve to make the events useless.

You can’t handle it by polling later. You code is halted. So it has
to be in the callback.

Remember how I mentioned time-critical vs non-time-critical? My
’backburner’ project is adding SDL support to a pre-existing virtual
machine. This virtual machine allows the programmer to act as if the
virtual machine never shuts down (time just magically passes faster
than normal, all connections fail, etc.). If I spend the effort to
adapt this to iOS (which is unlikely, since I don’t have one of the
devices) then I’ll obviously need to put code into one of the
callbacks to implement this…

However, the code running on the virtual machine should ALSO be
informed of this (example: so that it can figure out if it needs to
reload textures), and that realistically can (AND SHOULD) be relegated
to events.

Thus, two types of reaction to callbacks:

time-critical code that needs to run INSIDE the callback, and

non-time-critical code that can run anywhere as long as it eventually runs.

As for me asking whether anyone can come up with a use-case? I don’t
think I’ll be using this, so I don’t feel that I can JUSTIFY the
developer effort with my example. It may be informative, but I could
just as easily implement the events myself, and I probably won’t be
using the callbacks for this project regardless.

There’s nothing stopping you dropping a “minizimed” or “maximized” event on the queue. Again, you’re avoiding the giant elephant in the room, which is that your code is halted! You can’t timely send these messages. This is just how iOS works. No usage case is going to change how the OS works.

Vittorio wrote:

In my opinion, you are missing the “Simple” in “Simple Directmedia Library”…
If you need to do something so complex that forces you to

set up callbacks;

respond in quasi real time;

handle a variable number of events
you might as well just subclass the main delegate instead of
completely revolutionising the SDL chain.

Beware that I hardly believe the proposed implementation is future
proof, in fact as you know the events that need a fast action might
change with every ios release (like it happened from 3.x to 4.x).
I’m sure that subclassing+ovverriding can be adopted for android as well.

I’m not discreting the patch or the patch’s author, I’m just worried
about the possible implications and feature duplication.

You can never create anything if you are worried about APIs changing. They will, and there’s nothing you can do about it. Overriding is not a good ideal in a library! The concept of libraries is that they are black boxes. I should note that the big change in iOS (when background processing was added) was the ADDITION of new events. An override would have the exact same problem.

And “Simple” is find, but “works” is better. If this is the way it’s required to do by the OS, there’s no way around it. You have to respond to these in real time.

OK, the last thing I want this to do is become some dumb fight on the level of things that end up being minutia. There are things that are very easy to compromise on, but we’re going to be running around in circles until somebody with the authority decides to let something get in the trunk I think this patch is a good starting place. Let’s see if we can get it in and then we can move forward with some development and see how well it works. I’m willing to do all the heavy lifting on a pretty complex large piece of code (that is cross platform OS X/PC/iOS) and make sure it all works.

[>] Brian

Gabriel_Jacobo · March 29, 2012, 6:46pm

You can never create anything if you are worried about APIs changing. ?They will, and there’s nothing you can do about it. ?Overriding is not a good ideal in a library! ?The concept of libraries is that they are black boxes. ?I should note that the big change in iOS (when background processing was added) was the ADDITION of new events. ?An override would have the exact same problem.

I think overriding the delegate, if possible, is the best solution as
you keep the changes limited to the platform that’s got the problem,
and you leave up to the developer what solution to implement. There’s
plenty of examples of black box libraries where you have to override
things to make it work, the iOS framework being the first that comes
to mind!
We can also consider adding an example implementation of these
overrides to help new users get quickly up to speed, or modify the
current delegate to error out if you haven’t overriden the required
methods, etc.
I do agree that it would be nice to hear what Sam or Ryan think about this!–
Gabriel.

Brian_Barnes · March 29, 2012, 7:33pm

Gabriel wrote:

I think overriding the delegate, if possible, is the best solution as
you keep the changes limited to the platform that’s got the problem,
and you leave up to the developer what solution to implement. There’s
plenty of examples of black box libraries where you have to override
things to make it work, the iOS framework being the first that comes
to mind!
We can also consider adding an example implementation of these
overrides to help new users get quickly up to speed, or modify the
current delegate to error out if you haven’t overriden the required
methods, etc.
I do agree that it would be nice to hear what Sam or Ryan think about this!

If your code is all cross platform C code, then no, it’s a bad idea, and especially a bad idea for a library that’s front end is C.

The iOS Frameworks are tied directly into your code; the SDL system sits in between and is supposed to hide those details. It’s expected in an object oriented system. It’s not expected in a C library.

In my mind, the real beauty of SDL is that it allows you to write cross platform code. Here, there’s no “layer”.

I think one of the big stumbling blocks for some is this: “changes limited to the platform that’s got the problem”. It’s not a problem, it’s a very different platform then SDL is normally used to. And what’s worse, it’s going to be the future. OS X and Windows both seem to be going that way, and you know eventually the any other OS will go that way. Always on, never quit, send to background, etc. All that is going to have to be dealt with on time.

The fact is, eventually, and not far down the road, SDL is going to require this kind of system. If we have to override for every different implementation type, then we aren’t really preserving anything cross platform.

[>] Brian

Jared_Maddox · March 30, 2012, 3:23am

Message-ID:
<CABLWnS9b9zBXF261gCZmAkNP1d9K09PX+6YW_KV_QcwDghK7Og at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

In my opinion, you are missing the “Simple” in “Simple Directmedia
Library”…
If you need to do something so complex that forces you to

set up callbacks;

respond in quasi real time;

handle a variable number of events
you might as well just subclass the main delegate instead of
completely revolutionising the SDL chain.

Beware that I hardly believe the proposed implementation is future
proof, in fact as you know the events that need a fast action might
change with every ios release (like it happened from 3.x to 4.x).
I’m sure that subclassing+ovverriding can be adopted for android as well.

The only way that I can think of that this might future-proof your
application is if you provide implementations for ALL events in this
manner. If you do THAT, then there is NO reason to use SDL, because
you’re already doing almost everything that it does.> Date: Thu, 29 Mar 2012 17:07:24 +0200

From: Vittorio Giovara <vitto.giova at yahoo.it>
To: SDL Development List
Subject: Re: [SDL] iOS System Callback

Date: Thu, 29 Mar 2012 14:23:45 -0400
From: Brian Barnes
To: sdl at lists.libsdl.org
Subject: Re: [SDL] iOS System Callback
Message-ID:
Content-Type: text/plain; charset=us-ascii

Jared wrote:

As far as my comment goes, it was about duplicating the callback into
the event queue. I have no problem with callbacks.

Yes, I understand that, what I’m trying to tell you is that it just won’t
work. You will NOT get some of these messages in the event queue; your
program will be halted at that point. What you will get is the worse
possible solution: player hits button, you get one event, code is halted,
then you get (in a row) the “enter background” and “exit background” AFTER
you have exited the background. This is bad and will only serve to make the
events useless.

There’s nothing stopping you dropping a “minizimed” or “maximized” event on
the queue. Again, you’re avoiding the giant elephant in the room, which is
that your code is halted! You can’t timely send these messages. This is
just how iOS works. No usage case is going to change how the OS works.

Ah, I understand now. I had thought that you didn’t understand my
post, but it was the other way around. Thus, I apologize for the delay
in telling you this:

I HAVE considered this before, in reference to the very project that I
mentioned (technically it was related to PWM messages, but the timing
issue was the same). When I say ‘non-time-critical’ I mean it. It
doesn’t matter if it runs after execution resumes, because you’re just
informing the code of something that happened, nothing more. My
conclusion was the same as now: the event makes sense, because the
user of the event gets to read the documentation and decide if they
care about it.

Remember, SDL is calling your handler from within it’s handler, it can
do whatever temporary archiving that it needs to (though I assume that
it currently favors “don’t need to”), so these events have no reason
to just vanish (in fact, you suggest otherwise yourself). Further, it
doesn’t matter if the messages are timely, because that’s what the
callback itself is for in the first place! As I said twice now,
time-critical vs. non-time-critical. Time-critical needs the callback,
non-time-critical just needs to know that it happened at all. When
non-time-critical code finds out doesn’t matter.

Now, is it perhaps a little silly to have two events for this? Sure,
but that’s an implementation detail.

Vittorio wrote:

In my opinion, you are missing the “Simple” in “Simple Directmedia
Library”…
If you need to do something so complex that forces you to

set up callbacks;

respond in quasi real time;

handle a variable number of events
you might as well just subclass the main delegate instead of
completely revolutionising the SDL chain.

Beware that I hardly believe the proposed implementation is future
proof, in fact as you know the events that need a fast action might
change with every ios release (like it happened from 3.x to 4.x).
I’m sure that subclassing+ovverriding can be adopted for android as well.

I’m not discreting the patch or the patch’s author, I’m just worried
about the possible implications and feature duplication.

You can never create anything if you are worried about APIs changing. They
will, and there’s nothing you can do about it. Overriding is not a good
ideal in a library! The concept of libraries is that they are black boxes.
I should note that the big change in iOS (when background processing was
added) was the ADDITION of new events. An override would have the exact
same problem.

Agreed.

And “Simple” is find, but “works” is better. If this is the way it’s
required to do by the OS, there’s no way around it. You have to respond
to these in real time.

Also, if (just as an example) someone decided to port SDL as a
micro-kernel interface to graphics hardware, this callback system
could be used to make hardware-interrupts easier to deal with. Same
thing would go with any other callback system that used unusual
function styles (e.g. lots of MS Windows functions, so probably
WindowsRT); by handling those things itself & providing a callback
interface where relevant, SDL makes it much easier to deal with those
systems.

Date: Thu, 29 Mar 2012 15:46:35 -0300
From: Gabriel Jacobo
To: SDL Development List
Subject: Re: [SDL] iOS System Callback
Message-ID:
<CAKDfes=ZiBCdjWFSPkKb2bkhNYgTUugxF7_JFboKrjorbpf5yA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

I think overriding the delegate, if possible, is the best solution as
you keep the changes limited to the platform that’s got the problem,
and you leave up to the developer what solution to implement. There’s
plenty of examples of black box libraries where you have to override
things to make it work, the iOS framework being the first that comes
to mind!

That sounds REALLY badly designed. Interfaces to other systems should
fully adapt what they’re interfacing to into their own idioms. SDL
interfaces to OS systems, and should thus fully adapt those parts of
iOS that it actually touches (in some cases this might not actually be
realistic, but this is not one of those cases).

We can also consider adding an example implementation of these
overrides to help new users get quickly up to speed, or modify the
current delegate to error out if you haven’t overriden the required
methods, etc.

The first just increases the boilerplate that developers have to
write, the second is obnoxious (especially if they just don’t care,
e.g. a clock application).

Gabriel_Jacobo · March 30, 2012, 12:43pm

I think overriding the delegate, if possible, is the best solution as
you keep the changes limited to the platform that’s got the problem,
and you leave up to the developer what solution to implement. There’s
plenty of examples of black box libraries where you have to override
things to make it work, the iOS framework being the first that comes
to mind!

That sounds REALLY badly designed. Interfaces to other systems should
fully adapt what they’re interfacing to into their own idioms. SDL
interfaces to OS systems, and should thus fully adapt those parts of
iOS that it actually touches (in some cases this might not actually be
realistic, but this is not one of those cases).

It may very well be bad design, but as everything in real life it is
(at least in my opinion) a compromise, a good balance between solving
what currently is an iOS only issue (despite what the future may
bring, currently it is a single platform issue) and keeping it
restricted to the platform with the problem.

We can also consider adding an example implementation of these
overrides to help new users get quickly up to speed, or modify the
current delegate to error out if you haven’t overriden the required
methods, etc.

The first just increases the boilerplate that developers have to
write, the second is obnoxious (especially if they just don’t care,
e.g. a clock application).

I don’t see how a particular application simplicity is of relevance
here. Currently for the Android platform you have to jump through
several minor hoops to set the project up just to show one pixel or
build the next Minecraft, a complex project like SDL will never be
click and play in all the cases, specially considering the broad range
of supported platforms which don’t share a design philosophy.–
Gabriel.

Gabriel_Jacobo · March 30, 2012, 12:49pm

2012/3/29 Brian Barnes :

OK, the last thing I want this to do is become some dumb fight on the level of things that end up being minutia. ?There are things that are very easy to compromise on, but we’re going to be running around in circles until somebody with the authority decides to let something get in the trunk ?I think this patch is a good starting place. ?Let’s see if we can get it in and then we can move forward with some development and see how well it works. ?I’m willing to do all the heavy lifting on a pretty complex large piece of code (that is cross platform OS X/PC/iOS) and make sure it all works.

[>] Brian

I’m sure Sam will send a message on about this eventually, I hope I’m
not going out of line here posting this, but I chatted with him about
this issue yesterday:

Sam: I’m actually okay with it.There actually is a system specific
message callback system. SDL_SYSWM And you can set a callback hook
that gets called inline. But it’s kind of clunky for the kind of stuff
you’re dealing with here.
Sam: I’m also okay with the delegate idea. It’s cleaner for sure, but
not extensible to other operating systems. Honestly, I’d like to see
how it works out and get feedback from people on which they like best.

So there you have it! I think that if you clean the patch up, upload
it on the tracker or an unofficial repository ready to use for people
to try it there’s a good chance the patch will get accepted.–
Gabriel.

Forest_Hale · March 30, 2012, 9:36pm

For my part I vote for required callback functions provided by the app on the specific platforms that need them - I.E. fail to compile on iOS if the app does not provide a function named
SDL_iOSEvent_WillTerminate and similar functions. This is the only way I see to avoid this being a minefield for new developers on iOS who may not be aware of all the standard requirements and the
current state of things (if the API changes later, we’ll see new required functions, this is a nice reminder of changes that are necessary).

The iOS SDK is a moving target, and the best way to get programmers in line is to have compile errors on outdated code.On 03/30/2012 05:49 AM, Gabriel Jacobo wrote:

2012/3/29 Brian Barnes :

OK, the last thing I want this to do is become some dumb fight on the level of things that end up being minutia. There are things that are very easy to compromise on, but we’re going to be running around in circles until somebody with the authority decides to let something get in the trunk I think this patch is a good starting place. Let’s see if we can get it in and then we can move forward with some development and see how well it works. I’m willing to do all the heavy lifting on a pretty complex large piece of code (that is cross platform OS X/PC/iOS) and make sure it all works.

[>] Brian

I’m sure Sam will send a message on about this eventually, I hope I’m
not going out of line here posting this, but I chatted with him about
this issue yesterday:

Sam: I’m actually okay with it.There actually is a system specific
message callback system. SDL_SYSWM And you can set a callback hook
that gets called inline. But it’s kind of clunky for the kind of stuff
you’re dealing with here.
Sam: I’m also okay with the delegate idea. It’s cleaner for sure, but
not extensible to other operating systems. Honestly, I’d like to see
how it works out and get feedback from people on which they like best.

So there you have it! I think that if you clean the patch up, upload
it on the tracker or an unofficial repository ready to use for people
to try it there’s a good chance the patch will get accepted.

–
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

Tim_Angus · March 30, 2012, 9:38pm

I agree with this. I certainly think it’s confusing to have events that will almost never be useful or correct.On Fri, 30 Mar 2012, 22:36:06 BST, Forest Hale wrote:

For my part I vote for required callback functions provided by the app
on the specific platforms that need them - I.E. fail to compile on iOS
if the app does not provide a function named SDL_iOSEvent_WillTerminate
and similar functions.? This is the only way I see to avoid this being a
minefield for new developers on iOS who may not be aware of all the
standard requirements and the current state of things (if the API
changes later, we’ll see new required functions, this is a nice reminder
of changes that are necessary).

The iOS SDK is a moving target, and the best way to get programmers in
line is to have compile errors on outdated code.

On 03/30/2012 05:49 AM, Gabriel Jacobo wrote:

2012/3/29 Brian Barnes :

OK, the last thing I want this to do is become some dumb fight on
the level of things that end up being minutia.? There are things
that are very easy to compromise on, but we’re going to be running
around in circles until somebody with the authority decides to let
something get in the trunk :)? I think this patch is a good starting
place.? Let’s see if we can get it in and then we can move forward
with some development and see how well it works.? I’m willing to do
all the heavy lifting on a pretty complex large piece of code (that
is cross platform OS X/PC/iOS) and make sure it all works.

[>] Brian

I’m sure Sam will send a message on about this eventually, I hope I’m
not going out of line here posting this, but I chatted with him about
this issue yesterday:

Sam:? I’m actually okay with it.There actually is a system specific
message callback system. SDL_SYSWM And you can set a callback hook
that gets called inline. But it’s kind of clunky for the kind of stuff
you’re dealing with here.
Sam:? I’m also okay with the delegate idea. It’s cleaner for sure, but
not extensible to other operating systems. Honestly, I’d like to see
how it works out and get feedback from people on which they like best.

So there you have it! I think that if you clean the patch up, upload
it on the tracker or an unofficial repository ready to use for people
to try it there’s a good chance the patch will get accepted.

–
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

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Rainer_Deyke · March 31, 2012, 9:00am

I completely agree with this. I see two ways to reconcile the
cross-platform nature of SDL with the requirements of iOS:

The complicated way. Use setlongjmp trickery to temporarily pass
control back to the app’s event loop from the callback until the event
is handled. It’s messy and difficult on the SDL side, but it allows the
user to completely ignore the special requirements of the iOS platform.
The simple way. Add a single API for synchronous callback events,
and require it for all platforms. User code is made a bit more
complicated, but remains platform independent.On 2012-03-29 21:33, Brian Barnes wrote:

If your code is all cross platform C code, then no, it’s a bad idea,
and especially a bad idea for a library that’s front end is C.

The iOS Frameworks are tied directly into your code; the SDL system
sits in between and is supposed to hide those details. It’s expected
in an object oriented system. It’s not expected in a C library.

In my mind, the real beauty of SDL is that it allows you to write
cross platform code. Here, there’s no “layer”.

The fact is, eventually, and not far down the road, SDL is going to
require this kind of system. If we have to override for every
different implementation type, then we aren’t really preserving
anything cross platform.

–
Rainer Deyke (rainerd at eldwood.com)

Brian_Barnes · March 31, 2012, 3:48pm

Forest Hale wrote:

For my part I vote for required callback functions provided by the app on the specific platforms that need them - I.E. fail to compile on iOS if the app does not provide a function named
SDL_iOSEvent_WillTerminate and similar functions. This is the only way I see to avoid this being a minefield for new developers on iOS who may not be aware of all the standard requirements and the
current state of things (if the API changes later, we’ll see new required functions, this is a nice reminder of changes that are necessary).

The iOS SDK is a moving target, and the best way to get programmers in line is to have compile errors on outdated code.

I’m not opposed to this, either. I just want something to get into the trunk ASAP so I can begin testing with it, as I’m hoping to put out my first dim3 iOS game in a couple months.

The only things that, too me, are necessary, is

they have to be callbacks
Unneeded event pumps are removed from the code (without this, #1 is nearly impossible to handle)

The way above is actually how I tested it now by hacking these into the static library, but that’s in a very quick and dirty way and certainly not something patch worthy. It wouldn’t actually have to be anything but calling these functions without a stub; iOS requires the libraries (at this point, as far as I remember) to be static libraries anyway.

Should I work up a patch?

[>] Brian

Brian_Barnes · March 31, 2012, 5:02pm

I created a patch.

http://www.klinksoftware.com/download/iOSCallback.zip

This contains 3 files. The patch itself, and the two changed .m files if anybody wants to just apply it that way (both in video/uikit). This was done off the trunk from about a day ago (I doubt these files have changed.)

This ASSUMES you are compiling a static library, which right now is your only option, and it requires that these functions exist. The functions are:

void SDL_iOSEvent_WillTerminate(void);
void SDL_iOSEvent_DidReceiveMemoryWarning(void);
void SDL_iOSEvent_WillResignActive(void);
void SDL_iOSEvent_DidBecomeActive(void);
void SDL_iOSEvent_DidEnterBackground(void);
void SDL_iOSEvent_WillEnterForeground(void);

Currently, I get a crash every 3rd or so time. I will be tracking this; it’s obviously some threaded or race condition, and I have some ideals. For now, I’m assuming it’s my code.

I left in there the call that adds a minimize/maximize event onto the event stack. I ignore these on iOS, so somebody else will have to fight over include/not-include.

NOTE: I REMOVED a pump events from swap buffer. ANY pump events outside of event polling code is going to be asking for trouble. So using this REQUIRES that you pump events yourself (or poll events, whatever.) This is something you should probably be doing anyway. There could be more, and it could be the source of my crash, but I won’t know until I can investigate further.

The patch itself (don’t use this, use the one in the zip):

diff -r 6bb657898f55 src/video/uikit/SDL_uikitappdelegate.m
— a/src/video/uikit/SDL_uikitappdelegate.m Tue Feb 28 21:58:36 2012 -0500
+++ b/src/video/uikit/SDL_uikitappdelegate.m Sat Mar 31 12:54:02 2012 -0400
@@ -36,6 +36,15 @@
#undef main
#endif

+// these events must be defined in the client code
+// this assumes a static library
+extern void SDL_iOSEvent_WillTerminate(void);
+extern void SDL_iOSEvent_DidReceiveMemoryWarning(void);
+extern void SDL_iOSEvent_WillResignActive(void);
+extern void SDL_iOSEvent_DidBecomeActive(void);
+extern void SDL_iOSEvent_DidEnterBackground(void);
+extern void SDL_iOSEvent_WillEnterForeground(void);+
extern int SDL_main(int argc, char *argv[]);
static int forward_argc;
static char **forward_argv;
@@ -123,16 +132,16 @@

(void)applicationWillTerminate:(UIApplication *)application
{
SDL_SendQuit();

/* hack to prevent automatic termination.  See SDL_uikitevents.m for details */

longjmp(*(jump_env()), 1);

SDL_iOSEvent_WillTerminate();
+}

± (void)applicationDidReceiveMemoryWarning:(UIApplication *)application
+{

SDL_iOSEvent_DidReceiveMemoryWarning();
}

(void) applicationWillResignActive:(UIApplication*)application
{
//NSLog(@"%@", NSStringFromSelector(_cmd));
// Send every window on every screen a MINIMIZED event.
SDL_VideoDevice *_this = SDL_GetVideoDevice();
if (!_this) {
return;
@@ -143,13 +152,14 @@
SDL_SendWindowEvent(window, SDL_WINDOWEVENT_FOCUS_LOST, 0, 0);
SDL_SendWindowEvent(window, SDL_WINDOWEVENT_MINIMIZED, 0, 0);
}

SDL_iOSEvent_WillResignActive();
}

(void) applicationDidBecomeActive:(UIApplication*)application
{
//NSLog(@"%@", NSStringFromSelector(_cmd));
// Send every window on every screen a RESTORED event.

SDL_iOSEvent_DidBecomeActive();
SDL_VideoDevice *_this = SDL_GetVideoDevice();
if (!_this) {
return;
@@ -162,6 +172,16 @@
}
}

± (void) applicationDidEnterBackground:(UIApplication*)application
+{

SDL_iOSEvent_DidEnterBackground();
+}

± (void) applicationWillEnterForeground:(UIApplication*)application
+{

SDL_iOSEvent_WillEnterForeground();
+}

@end

#endif /* SDL_VIDEO_DRIVER_UIKIT */
diff -r 6bb657898f55 src/video/uikit/SDL_uikitopengles.m
— a/src/video/uikit/SDL_uikitopengles.m Tue Feb 28 21:58:36 2012 -0500
+++ b/src/video/uikit/SDL_uikitopengles.m Sat Mar 31 12:54:02 2012 -0400
@@ -95,7 +95,7 @@
[data->uiwindow makeKeyAndVisible];

 /* we need to let the event cycle run, or the OS won't update the OpenGL view! */

SDL_PumpEvents();
+// SDL_PumpEvents();

}

[>] Brian

Brian_Barnes · March 31, 2012, 7:22pm

Rainer Deyke email just alerted me that I forgot a bit of this patch (which is not important at this point) – all the long jump stuff can be removed if we go this way.

I should note that I’m not married to either way; I could care less if it’s a callback mechanism or the patch I just put up (which I only put up to hopefully get something moving.) As long as it fits the requirements, i.e., it’s a callback, then everything is fine with me.

The patch code I put up is a bit simpler than registering callbacks, but restrictive in static libs only (which is already a requirement.)

[>] Brian

Jeremy_Jurksztowicz · March 31, 2012, 9:40pm

Please no long jumps! This doesn’t play well with C++ stack unwinding and
will lead to memory leaks and/or state mess-ups.On Sat, Mar 31, 2012 at 3:22 PM, Brian Barnes wrote:

Rainer Deyke email just alerted me that I forgot a bit of this patch
(which is not important at this point) – all the long jump stuff can be
removed if we go this way.

I should note that I’m not married to either way; I could care less if
it’s a callback mechanism or the patch I just put up (which I only put up
to hopefully get something moving.) As long as it fits the requirements,
i.e., it’s a callback, then everything is fine with me.

The patch code I put up is a bit simpler than registering callbacks, but
restrictive in static libs only (which is already a requirement.)

[>] Brian

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Forest_Hale · March 31, 2012, 10:24pm

I’m liking this patch so far but haven’t had a chance to test it, it’s hard for it to be a regression as currently in my project I’m not even handling these events yet, so I’m wide open on the how,
but I am firmly in the “must be callbacks” crowd for simplicity sake

And longjmp is vile stuff, everything in SDL2 that relies on it terrifies me :)On 03/31/2012 12:22 PM, Brian Barnes wrote:

Rainer Deyke email just alerted me that I forgot a bit of this patch (which is not important at this point) – all the long jump stuff can be removed if we go this way.

I should note that I’m not married to either way; I could care less if it’s a callback mechanism or the patch I just put up (which I only put up to hopefully get something moving.) As long as it fits the requirements, i.e., it’s a callback, then everything is fine with me.

The patch code I put up is a bit simpler than registering callbacks, but restrictive in static libs only (which is already a requirement.)

[>] Brian

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
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