The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

For those that listened in last time I talked about my SDL-using
engine's ray tracing API, here's a demonstration or the latest:

http://www.youtube.com/watch?v=m6t-qHjE1gU

And second, as we are getting closer and closer to an SDL2 release, have
we gotten any father on how the iOS (and Android) required callback
events are going to be handled? I haven't been able to move up (or
test) newer SDL2 because of this, and I really want to do that (my
engine cross compiles on OS X, win32, linux, and iOS, which is why
having all this in one place is great for me.)

Again, for me, I don't mind 6 or so new events (active, about to become
active, un-active, about to go un-active, quit, low memory) and using
the event filter to capture them during callback. We should probably
have those events NEVER land on the event stack (otherwise people will
call them from the event stack and that'll cause all sorts of crazy
problems -- this would have to be noted in the docs.)

That way actually leaves most of the code intact (regression testing and
all) and if noted properly in the docs, should work.

[>] Brian

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Looking good, Brian!


On Wed, May 15, 2013 at 9:24 AM, Brian Barnes wrote:

I think it was applied a few months back. Have you looked at the repo
code, and attempted to use the event hooks?


I think that the route that was settled on was that the callback would
decide whether the event was placed on the stack or not. As it is, the
callbacks are used differently than the event stack, so unless you've
built an emulation of the callback system that you've filled with an
identical set of handlers, it honestly shouldn't be a problem. At most
you should need some platform-detect macros or variables to shift
around where you do what.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Jared wrote:


Not that I know of or from what I can see in the code. This whole
discussion came about because some people thought that what was in there
was enough, not realizing the requirements of the OS.

Sam also mentioned that it was one of the outstanding things a little
while back, so that's why I'm here again :)


I didn't make that clear enough, sorry. What I meant is these new
classes of events should never make it back to the stack regardless if
you pick them up or not, because doing them out-of-call will cause
really hard to diagnose crashes and for sure break your app. Idiot
proofing the API, basically, and it should be noted in the docs.

I might as well throw out my two cents again. Let's have another EVENT
type, say "SDL_APPLICATIONEVENT", with sub-events ACTIVE,
BECOMING_ACTIVE, DEACTIVATE, GOING_TO_DEACTIVATE, LOW_MEMORY, and QUIT.
These ONLY are seen through the eventfilter mechanism. Note that
things like LOW_MEMORY and QUIT can happen WHEN your app is stalled and
is receiving NO CPU time at all (this is why these are important to
happen in callbacks, the others are required to be completed before
returning.) There's also some completely crazy longjmp code to handle
the quit in the iOS version that can be removed.

There was also one other problem that I forgot -- there was something
synch-wise that needed to be removed as it made the calling time of
these callbacks potentially dangerous on iOS, I'd have to go back over
what I did earlier.

This same system should work for Android, and I'd assume any other
similar system.

[>] Brian
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Technically speaking, the event filter system is enough (or at least
should be), but the events are most certainly needed as well.


Odd, I remember someone mentioning that they've already been using
SDL2 for Android for a while, which would imply that major stuff like
this does actually work. For example, Timodor was working on some
partially related stuff just a few days ago. Still, I didn't see them
when I looked in the repo just now. Odd.


Uh, no, I picked up your meaning perfectly well, and was shooting it
down. "Idiot proofing" is a very direct translation of "Crippling".
Anyone who actually makes this mistake would very quickly shoot
themselves in the foot, and there are few ways to learn faster than by
shooting yourself in the foot.

If the programmer doesn't know how to do it right, then their users
will very quickly force them to learn.

For a point AGAINST, consider this: someone decides to create a
scripting-language binding for SDL. They don't get to decide how the
scripting language works because it already exists, they just get to
connect it. They discover that they can handle all of the at-call-time
issues in the scripting engine, but they later need to pass the events
along to the script so that it can update it's state to reflect the
changes that ALREADY happened. Do you want to stick the programmer
with marshaling the OS events to whichever thread, while maintaining
synchronization with the primary SDL event stack, or would it be
better to just let the callback say "stick this event on the stack"?
Remember, the callback and the event loop are very dissimilar. As long
as the requirements of those events are listed with the event's
documentation, everything has been done that responsibly CAN be done.


I believe that at one point it was said that the mapping between iOS
and Android isn't 100% for time-critical events. Regardless, this is
really platform-dependent stuff, so if the events don't exist yet,
then they should be namespaced for the relevant operating system.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Jared Maddox wrote:


They are. I am using it for iOS, as others! We've all just had to
patch it to handle these events ... and all the patches are different.
I could care less about the approach, I just want a single one in the
code so I can throw away the patch, this keeps me from upgrading.


APIs and libraries need to tread the line between (1) not crashing and
(2) providing people with the necessary resources. They should never
(3) be designed to allow for every edge case. All error on the side of
not crashing instead of edge cases; that's the kind of stuff that leads
to wildly large and hard to maintain API base. If the programmer has to
do extra work, then so be it.

But, again, this discussion threatens to get off the rails This is
just a suggestion, it doesn't matter to me one way or another, so I have
no problems with it getting back to the event stack.


As far as I've seen, and I was involved in the other long range
discussion, they are actually pretty similar. It doesn't mean that it
will be for future OSes (and winphone is in question), but I think, by
nature of SDL, we should strive to commonize as much as possible. We
will need to do the same task -- save and restore state and deal with
memory clean up, and quit basically. Again, a suggestion. I'm willing
to accept any solution, we just NEED one.

[>] Brian
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Yep, the new events are in:http://hg.libsdl.org/SDL/rev/11612d544fcd



Please let me know if there are any issues with them!



On Wed, May 15, 2013 at 6:24 AM, Brian Barnes wrote:

Here's my first report, very quick testing.

OS X: SDL_SetRelativeMouseMode doesn't hide the mouse cursor, but that's the only problem I found (so far)
win32: Won't be able to look at until monday
iOS: All the callbacks seem to be working properly, and I like the rework of the finger code, removing all the strange scaling attributes and just going with normalized coordinates. That was always weird!

NOW: What is up with OpenGL in landscape on iOS? Something has changed. My code before had to handle rotating the openGL view, and this ALL seems to be happening automatically somewhere in SDL. I guess this is a good thing (it was annoying to have to rotate all this), but that's a drastic change from what came before. What is it doing? Or have I gone crazy here and am seeing things?

[>] Brian
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Windows testing: (I assume this is relative mouse mode, again) The
cursor is properly hidden, but the first click suddenly warps the mouse
to the center of my screen. It never does that again, and everything
works fine.

[>] Brian
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Can you report that as a bug to bugzilla?http://bugzilla.libsdl.org/


Thanks!



On Mon, May 20, 2013 at 7:34 AM, Brian Barnes wrote:

Sam wrote:


Sorry, I always forget that step. I've added 2 bugs:

1860 - Relate mouse movement on OS X doesn't hide cursor
1861 - Relate mouse movement on windows jumps the cursor to the center on the first mouse click (1836 is a similar report for OS X, but I don't see the bug there, it's possible the way I'm handling some additional things in OS X mitigates that for me.)

Can somebody quickly explain whatever change happened that automatically handles iOS landscape rotation? Is it during the texture transfer? I'm wondering what parts of my code I need to deal with, and if this is the final version of how that code will function for SDL 2.x.

[>] Brian

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

This is the final version of the iOS code (for now)We're letting the OS handle the view transformation so it should just work behind the scenes for you.


If you create a resizable window, then SDL will allow the user to rotate the application to whichever orientation they like.  If you create a non-resizable window, then SDL will lock the orientation to the aspect ratio you've picked.


Cheers!



On Tue, May 21, 2013 at 9:31 PM, Brian Barnes wrote: