last year Exult (http://exult.sf.net) was ported to iOS. The porter changed stuff in SDL 2.0.3 source code to make Exult display and to use correct touch coordinates properly - repository at https://github.com/litchie/exult-ios.
Now I’m trying my hands at de-hardcoding these changes but are not getting far. The goal was to be able to make SDL2 a drop-in only lib instead of hardcoding all this and then being stuck when a new version of SDL2 is released with useful changes (e.g. the recent change for the mouseclick event)
Can anyone help me a bit? I know that’s a big request especially since I’m not very experienced. But I really could need help to resolve at least the need for the SDL_uikitwindow.m change.
SDL_GetWindowWMInfo can give you a struct containing the underlying UIWindow* created by SDL_CreateWindow on iOS (check out SDL_syswm.h).
I highly recommend using SDL 2.0.4 or later for iOS - much of the platform backend code has been rewritten since 2.0.3, and many parts of it didn?t work on modern iOS versions prior to the rewrites.> On Sep 26, 2016, at 10:15 AM, Dominus wrote:
Now I’m trying my hands at de-hardcoding these changes but are not getting far. The goal was to be able to make SDL2 a drop-in only lib instead of hardcoding all this and then being stuck when a new version of SDL2 is released with useful changes (e.g. the recent change for the mouseclick event)
Can anyone help me a bit? I know that’s a big request especially since I’m not very experienced. But I really could need help to resolve at least the need for the SDL_uikitwindow.m change.
What happens when you try dropping in a stock copy of SDL2? Does it build?
I know it’s a lot of code but I am at my (very limited already) wits end
When I drop current SDL2 mercurial, the game is rendered correctly but touch and screen coordinates are way off (if you quarter the iOS landscape, it seems that the touch input “assumes” the actual game screen is in the upper left quarter).
Also the on screen controls that are handled by the SDLUIKITDelegate subclass are not rendered.
Can not look at the code from here, but: Do you have a retina display? Maybe you multiply the normalized touch coordinates with the wrong value then?–
Martin Gerhardy http://www.caveproductions.org
Am 27.09.2016 um 20:41 schrieb Dominus :
DLudwig wrote:
That’s a fair bit of code to look through.
What happens when you try dropping in a stock copy of SDL2? Does it build?
I know it’s a lot of code but I am at my (very limited already) wits end
When I drop current SDL2 mercurial, the game is rendered correctly but touch and screen coordinates are way off (if you quarter the iOS landscape, it seems that the touch input “assumes” the actual game screen is in the upper left quarter).
Also the on screen controls that are handled by the SDLUIKITDelegate subclass are not rendered.
Sounds like the the wrong coordinates could be caused by the resolution being scaled by iOS. If You are not using the SDL_WINDOW_ALLOW_HIGHDPI flag, the app will not use the full native resolution on many iOS devices. I.e. it will only render only a quarter of the pixels and scale width and height with 2 (or something else depending on device).
I’m not sure but SDL_MOUSEBUTTONDOWN etc. might give the coordinates as actual screen pixels and not as the rendered “logical” pixels. So maybe you need to scale them to get the pixel locations you want. What I do on iOS instead, is use the actual SDL_FINGERDOWN etc. events and ignore any mouse events where (event.button.which == SDL_TOUCH_MOUSEID). Those events are generated for compatibility to fake mouse events on touch devices. At least that way I’m getting correct coordinates also on touch devices.
However, when using SDL_FINGERDOWN etc. you will get coordinates as values that range from 0.0 to 1.0 (if I remember correctly). If you need the value in “logical” pixels, you need to scale with width and height values you get from SDL_GL_GetDrawableSize.
Disclaimer: I haven’t looked at your code and probably don’t remember all the details from the top of my head.
