Touch and Rotation on iOS |
Armin Ronacher
Guest
|
Hi,
Currently after the phone/tab is rotated. This can easily be checked as the right side of the screen after rotating from portrait to landscape stops working entirely. Right now I am not sure why. I was suspecting that the reason is that the SDL_Touch object is not updated after the screen rotated, but this seems to be only part of the problem and only solves the scaling. The fact that the right side does not respond seems to be a different one. The whole touchesBegan:withEvent: method is not called at all for the right screen side after rotation. I tried to see if the problem fixes itself when I reset the frame of the UIView, but it makes it worse as it then also does not draw on the right side. From the docs it seems that the touchesBegin thing might be bubbled up from the view controller, so I am not sure if that is swallowing the event somewhere. Regards, Armin _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||
|
Touch and Rotation on iOS |
Armin Ronacher
Guest
|
Hi,
I just found the problem, but I don't know the solution yet. Basically locationInView does not work in landscape mode, so I will have to find something to replace this with. Regards, Armin _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||
|
Touch and Rotation on iOS |
Armin Ronacher
Guest
|
Hi,
Nope, was not the issue. I still think it has something to with the misaligned UIView. Regards, Armin _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||
|
Touch and Rotation on iOS |
Touch and Rotation on iOS |
Armin Ronacher
Guest
|
Hi,
On 5/6/11 4:34 PM, Gabriele Greco wrote:
happening but not the solution: The UIView is not rotated when the phone is rotated. It stays the way it is so the right part of the screen no longer gets the touch begin event thingy. However the iOS continues to track the finger movements, even if the fingers move outside of the component to avoid user frustation. Now what happens if we update the view rectangle after rotation? For some weird reason the input still does not work and the rendering is then also broken for the right part (or left part if rotated 270 degree). To respond to rotations, you can implement updateFrame in the base view and also [super] the call in the opengl view. The correct rect is on the window, the wrong one is right now on the view. Regards, Armin _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Touch and Rotation on iOS |
Armin Ronacher
Guest
|
Hi,
Alright, the problem is definitively the view. SDL does something horrible there. Things I know so far: 1. SDL totally fucks up the view frame. It disables auto resizing but something still does something in there because the frame of the window ends up being different to the frame of the view. If the frame of the view is "fixed" all becomes worse as now the rendering is equally fucked at that point (right side of screen black). 2. Whowever wrote that rotation code in SDL had something in mind that (no longer?) works as intended. It certainly serves/served a purpose but without documentation it's not quite clear what it does. 3. Even if it work work as expected, the touch code in SDL would still be wrong as it never takes rotations into account. I came up with a horrible hack that fixes this by doing two things 1. Ignore boundaries of views and always returns the only view we have in the hitTest of the window. 2. Update the touch internals on rotations. This is the patch: http://paste.pocoo.org/show/384923/ [for view] http://paste.pocoo.org/raw/384923/ [for donwload] I totally do not recommend to check this in, but at least it's a workaround for the moment. I will have to check the history log to see who came up with the rotation code, maybe something in the log messages reveals the intent. I certainly must be missing something, because from looking at that code it does not make a lot of sense. I can't imaging that a misaligned UIView is the intention. Right now my idea is that the badly placed UIView might be an accident and another mistake sortof fixed that original problem good enough that nobody noticed for a while. I am quite happy to have a look at that code but I would really need the input of the original developer to understand why the code is doing things that way. Regards, Armin _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||
|