[SDL] iOS: need help de-hardcoding SDL 2.0.3 changes in Exult-iOS

[Dominus]

Hi all,

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.

All the SDL 2.0.3 changes are diffed in http://pastebin.com/h8Uq1kPk (the commits to exult-iOS https://github.com/litchie/exult-ios/commit/f167ef1, https://github.com/litchie/exult-ios/commit/77e1edeea1e70379d001e24ba86d7afc16ec2b2c, https://github.com/litchie/exult-ios/commit/5084a227295a020d455b2247adaf5b03ba27a17b)

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)

I've partially managed to at least create a subclass for SDLUIKITDelegate but still needed to keep the change in SDL_uikitwindow.m - see https://github.com/litchie/exult-ios/commit/84c773210c7cc60581b6e3a70e7606261481332f

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.

[Alex Szpakowski]

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.

Post by Dominus
Hi all,
last year Exult (http://exult.sf.net <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. <https://github.com/litchie/exult-ios.>
All the SDL 2.0.3 changes are diffed in http://pastebin.com/h8Uq1kPk <http://pastebin.com/h8Uq1kPk> (the commits to exult-iOS https://github.com/litchie/exult-ios/commit/f167ef1, <https://github.com/litchie/exult-ios/commit/f167ef1,>https://github.com/litchie/exult-ios/commit/77e1edeea1e70379d001e24ba86d7afc16ec2b2c, <https://github.com/litchie/exult-ios/commit/77e1edeea1e70379d001e24ba86d7afc16ec2b2c,> https://github.com/litchie/exult-ios/commit/5084a227295a020d455b2247adaf5b03ba27a17b <https://github.com/litchie/exult-ios/commit/5084a227295a020d455b2247adaf5b03ba27a17b>)
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)
I've partially managed to at least create a subclass for SDLUIKITDelegate but still needed to keep the change in SDL_uikitwindow.m - see https://github.com/litchie/exult-ios/commit/84c773210c7cc60581b6e3a70e7606261481332f <https://github.com/litchie/exult-ios/commit/84c773210c7cc60581b6e3a70e7606261481332f>
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 mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org <http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org>

[DLudwig]

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?

-- David L.

[Dominus]

Post by DLudwig
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.

[m***@gmail.com]

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

Post by DLudwig
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.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[ollika]

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.

[Dominus]

Many thanks to all your replies. I'll try and follow your suggestions. I hope I can get it to work!