I’m probably a month away from releasing my first iOS game, and I’m
desperate to get something into the trunk. The reason being is the game
will be in my development environment, dim3, which is freeware and open
source and it’ll be harder for other people to compile it themselves if
they have to patch SDL, and it doesn’t really reflect the ethos of being
able to easily replace versions of open source components.
(Sorry about that, I am the last person in the world to try to rush open
source developers as I am one myself but this has been going on for
months now and I started early hoping to get something in.)
So, how about this:
Since SDL_SetEventFilter seems to be something that can be used to get
events in real time, I can rewrite my patch to just add the events to
the regular SDL queue, and then we can use SDL_SetEventFilter to get the
events (I’ll need to test but it should work.)
Whoever wants to add Android events can just do the same.
Developers will have to know what they are doing and not attempt to get
this stuff off the queue.
Like the older patch, it’ll add a new event type: SDL_OSEVENT which will
have another 32 bit value for the specific event.
Could this pass muster to maybe get in the trunk?
[>] Brian
I’m actually okay with the original patch. If the OS requires that an
event be handled in the callback it should probably not go into the queue.
I want to discuss it with Ryan first though. Ryan, what do you think about
his patch?On Fri, Apr 20, 2012 at 2:25 PM, Brian Barnes wrote:
I’m probably a month away from releasing my first iOS game, and I’m
desperate to get something into the trunk. The reason being is the game
will be in my development environment, dim3, which is freeware and open
source and it’ll be harder for other people to compile it themselves if
they have to patch SDL, and it doesn’t really reflect the ethos of being
able to easily replace versions of open source components.
(Sorry about that, I am the last person in the world to try to rush open
source developers as I am one myself but this has been going on for months
now and I started early hoping to get something in.)
So, how about this:
Since SDL_SetEventFilter seems to be something that can be used to get
events in real time, I can rewrite my patch to just add the events to the
regular SDL queue, and then we can use SDL_SetEventFilter to get the events
(I’ll need to test but it should work.)
Whoever wants to add Android events can just do the same.
Developers will have to know what they are doing and not attempt to get
this stuff off the queue.
Like the older patch, it’ll add a new event type: SDL_OSEVENT which will
have another 32 bit value for the specific event.
Could this pass muster to maybe get in the trunk?
[>] Brian
_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Sam wrote:
I’m actually okay with the original patch. If the OS requires that an
event be handled in the callback it should probably not go into the
queue.
I want to discuss it with Ryan first though. Ryan, what do you think
about his patch?
There’s an early patch where this stuff comes directly through it’s own
callback mechanism, that might be the patch you are thinking of, and I’m
OK with that one two.
My patch integrates this stuff with the queue, though, which I only did
under request of some others. Since Event Filter does the same thing I
did, it’s probably the best way to go about it instead of the extra call
I created.
Either patch works fine, and will get the job done. You can either have:
- A patch with a new call (to setup a callback) just for these types of
events
- A patch that works within the existing system but programmers have to
be smart enough to know they need to handle it in the event filter
I’d probably vote for #1. My patch was an attempt to reach something
that might get put through.
http://lists.libsdl.org/pipermail/sdl-libsdl.org/2012-April/084379.html
That’s the email from the guy with the other patch.
It looks good but it’s missing ONE important thing – the UIKit screen
flip has an event pump in it. This must be removed or there will be
problems.
[>] Brian