iOS port

[vlag]

After https://github.com/christopho/solarus/issues/196 and https://github.com/christopho/solarus/issues/262 , the iOS port should be very easy.

The only point is that iPhone and iPad don't have physical button. We have to choose how to map every action, knowing that we can use

• the touchscreen, which behaves like a one button mouse.
• relative touchscreen moves.
• the gyroscope, which behaves pretty much like a 3 axis joystick (after quick verification, it is not supported by SDL, but is very easy and fast to implement using Foundation framework http://developer.apple.com/library/ios/#documentation/CoreMotion/Reference/CMMotionManager_Class/Reference/Reference.html , example here : https://dl.dropboxusercontent.com/u/31755496/iOSInterface.mm )
• a clickable HUD (implies to move it to the bottom of the screen, and maybe to split the screen to have a game display part and HUD part)
• virtual buttons
• some more solutions which I didn't think about right now ;)

Any idea ?

[oclero]

And it will be the same questions for an Android port :)

[christopho]

No, the Android port already works. We are just waiting for @sam101 to release it but he is on holiday right now ;)

[vlag]

The Android port currently uses virtual buttons (and physical ones that iPhone does not have), but I think it will be quite more convenient to use haptic features too if/when they will be supported, don't you ?

In my opinion, the ideal solution would be to have a clickable HUD at the bottom of the screen (in dedicated area or not), be able to move the hero when touching the game area (without virtual buttons), and also with the gyroscope (and be able to deactivate this last behavior from the pause menu), but it is maybe too much work for what it is, especially to rearrange the Option menu :p

I think you wish to keep the SDL2 port and mouse support mastership (if not, I'll start a fork ;) ), but I can add haptic feature myself once it will be done. Anyway, I can provide some testing version with all suggested configuration when it will be time to do ;)

[christopho]

I don't know much about Android, iOS and mobile devices in general. What are "haptic features" and what is the difference with virtual buttons?

[christopho]

@sam101, can you explain how controls work in the Android port? For me it is like magic. Thanks

[slepetit42]

Hello everyone,

Actually, the virtual controls simply work because they are part of the SDL Android port, they are treated as real keys by (to avoid any changes in the engine source code).

I'll work on the update of the port when I'll be back from my holidays. As for the haptic feedback, I'd like to see what you mean by that :) Le 6 août 2013 15:09, "Christopho" notifications@github.com a écrit :

@sam101 https://github.com/sam101, can you explain how controls work in the Android port? For me it is like magic. Thanks

— Reply to this email directly or view it on GitHubhttps://github.com/christopho/solarus/issues/263#issuecomment-22177204 .

[vlag]

Hi.

Arf sorry for the "haptic features", I amalgam everytimes ... By this, I meant "every (physical) input events which are not mouse or keyboard related, on mobile platform" ;)

So it concern the gyroscope, and the touchscreen if we use SDL_TouchFingerEvent instead of SDL_MouseMotionEvent (even if they work in much the same way)

[christopho]

With the SDL 2 port, I will add Lua mouse events and touch events to the engine. But I won't change ZSDX or ZSXD. These games are finished.

[vlag]

No problem for me, but it means that ZSDX and ZSXD won't be playable on iOS platform, except if someone fork them (I possibly can do it anyway).

Maybe add a basic support for touch feature (only) on these games, and remove the Option Menu on iOS platform would be an acceptable intermediate solution ?

[vlag]

First test with the sdl2 branch and zsdx on iOS : https://dl.dropboxusercontent.com/u/31755496/zsdx-ios1.png https://dl.dropboxusercontent.com/u/31755496/zsdx-ios2.png

Should I add XCode projects to the git repo ?

[kimsama]

It would be great to see solaraus is running on iOS. :-)

-Kim

sent from iphone

1. 10. 9. 오전 7:47 vlag notifications@github.com 작성:

First tests with the sdl2 branch on iOS : https://dl.dropboxusercontent.com/u/31755496/zsdx-ios1.png https://dl.dropboxusercontent.com/u/31755496/zsdx-ios2.png

Should I add XCode projects to the git repo ?

— Reply to this email directly or view it on GitHub.

[vlag]

The two fullscreen modes now fully works on iOS :) https://dl.dropboxusercontent.com/u/31755496/zsdx-ios3.png

I added XCode projects, tell me if I should revert.

It now remains only to implement touch features to be able to play :)

[christopho]

I'm okay to add mouse and touchscreen support to the engine and to the Lua API in Solarus 1.2: https://github.com/christopho/solarus/issues/196. @vlag Can you explain how you would see the gameplay of ZSDX/ZSXD with touchscreen features? There are no physical buttons at all? In particular, how will the user

• move the hero?
• use the sword?
• lift a bush, cut a bush, talk to a character, open a door, etc?
• use items (the bow, the boomerang, etc)?
• pause the game?

[vlag]

Yep, no physical button except the home button... Something like what I said in my second post should be the ideal solution on iOS :

Edited citation : "In my opinion, the ideal solution would be to have a clickable HUD at the bottom of the screen (in dedicated area or not, and maybe split buttons into a left and right group to make them easily accessible), be able to move the hero when touching the game area (8 directions without virtual buttons), and also with the gyroscope (and be able to deactivate this last behavior from the pause menu), but it is maybe too much work for what it is, especially to rearrange the Option menu :p"

If we choose this option, we'll need an extra sol.game.get_platform() function in addition to mouse/touch features to be able to make different behavior between the iPad and the iPhone (for instance) version of a same quest.

[slepetit42]

Hello everyone,

I think it would indeed be great to have some kind of mouse/touchscreen support for mobile devices: it's the only way we could remove the android buttons which are hardwired into the SDL android port (and we have little control over them). Also, it would allow us to have a consistent gameplay on all touchscreen-enabled platforms.

[christopho]

Ok. But what about the sword? Clicking the sword icon of the HUD is not acceptable because you wouldn't be able to both move your player and attack in a short time.

How to lift a bush, talk to a character, open a door, etc? By clicking the bush/character/door or the action icon?

[slepetit42]

Why couldn't we use the same kind of user input than in PH/ST (we can also use multitouch gestures like for the sword I think) ?

2013/10/10 Christopho notifications@github.com

Ok. But what about the sword? Clicking the sword icon of the HUD is not acceptable because you wouldn't be able to both move your player and attack in a short time.

How to lift a bush, talk to a character, open a door, etc? By clicking the bush/character/door or the action icon?

— Reply to this email directly or view it on GitHubhttps://github.com/christopho/solarus/issues/263#issuecomment-26051178 .

[christopho]

So if you click a bush, do you want to lift it or to cut it with the sword?

[vlag]

I didn't play PH and ST, but I guess using multitouch to handle the clickable HUD like physical buttons should be the easiest and most logical way.

You can use one finger to move the hero by touching the game area, and another finger to hold the sword icon or press it repeatedly to attack. Maybe clicking an entities on the game area can result in moving the hero + do the default action too.

[slepetit42]

maybe we just need to rethink the HUD ? To be on the bottom-right part of the screen (for at least the sword/item buttons), I don't know. Maybe we should have a look at what Nintendo is doing for the latest 3DS Zelda (although the 3DS is still using a resistive screen)

2013/10/10 vlag notifications@github.com

I didn't play PH and ST, but I guess using multitouch to handle the clickable HUD like physical buttons should be the easiest and most logical way.

You can use one finger to move the hero by touching the game area, and another finger to hold the sword icon or press it repeatedly to attack. Maybe clicking an entities on the game area can result in moving the hero

• do the default action too.

— Reply to this email directly or view it on GitHubhttps://github.com/christopho/solarus/issues/263#issuecomment-26056398 .

[christopho]

Ok. The gameplay will not be trivial to design, but it seems feasible indeed.

[christopho]

Please remove your xcode project from the repository, because it takes too much space (1.3 MB). Thanks

[vlag]

Little preview for the sample_quest : https://dl.dropboxusercontent.com/u/31755496/samplequest-ios1.png (fullscreen_normal) https://dl.dropboxusercontent.com/u/31755496/samplequest-ios2.png (fullscreen_scale2x)

The orientation of the iPhone is currently given by SDL_GetClosestDisplayMode() depending on the requested mode's resolution. Should we force an unique orientation, or update the engine to be able to detect the current orientation and set the corresponding display mode if it changes ?

Same question for the normal/scale2x mode : should we forbid windowed modes on iOS and let the user choose by himself between the two fullscreen mode, or force an unique mode ?

[christopho]

Always use the unique orientation.

[vlag]

Hi all,

Three years after, I thought it may be time to release a mobile version of Solarus (at least solarus-run). The current 1.5.0 version compiles and runs fine for iOS except for one or two minor details, and now that the mouse can be used with Lua, I made an exemple of how the gameplay may be on the sample quest.

https://www.youtube.com/watch?v=okesyxJk9T8

The idea is to use the left hand to move the hero and the right hand to hit the hud and trigger the corresponding action.

Feel free to comment :)

[wrightmat]

Looks great! Would you be willing to share your "mouse" movement code?

I've already added a clickable HUD to my game, so theoretically my game would be playable on mobile with the exact code you're demonstrating.

Also, would be willing/able to compile Solarus for iOS so it could run any quest package? I'm not sure if/how that works in the iOS world, but if we could have the compiled engine and just place the quest files either on an SD card or streamed from a website, that would be awesome!

[wrightmat]

@sam101 Any chance we could see an updated Android port with Solarus 1.5? I've tried to play around with compiling my own version, but I know too little about writing Android apps with C++ code :(

[vlag]

No problem, I'll share the lua file tonight when I'll be at home.

About Solarus I'm not sure if I can easily build the GUI, I know that Qt is supposed to run on iOS too but if it's like on OSX, I'm expecting some surprises :) For now I have only built solarus-run, so it can run any quest but we have to distribute the engine with the quest each times. I'll take some time to try.

[christopho]

Yes, the gui is more designed for desktop systems.

[wrightmat]

I didn't necessarily mean needing the GUI, as long as we can include whatever quest we'd like with solarus-run. I assumed this was possible, as that's how Christopho designed it, but I didn't know how iOS worked and if the app would have be recompiled (or hopefully just repackaged) to support another quest - especially if distributing on the App Store, which I believe is the only option.

[christopho]

No need for the launcher GUI indeed. solarus-run distributed with each quest on Android and iOS is perfectly okay.

Supporting several quests with one single copy of the engine is not a priority on mobile devices. The way to do so would be to develop a mobile app equivalent to the Solarus launcher GUI, that would allow the user to download quests. But this feature is not even done yet in the desktop launcher GUI. Not a priority for now.

[vlag]

Here is the branch : https://github.com/vlag/solarus/tree/mouse_control Of course this is a WIP, I just made it works to test on iOS so it's not as clean as it should be :)

About solarus-run you can run any quest you want, you just have to copy yours in the package so it is pretty easy to distribute.

[christopho]

That's a nice start! The mouse API is very experimental, I did not hope it would just work.

The code will need lots of modifications.

• If you add a HUD it should be a HUD menu like in all games, not in a "mouse control" menu. The mouse control menu is something different, it moves the hero with the mouse.
• The HUD menu and the hero mouse control menu should both be attached to the game, not to main.
• Global variables should never be used unless there is a good reason to.
• The sample quest must never contain any Zelda graphics.

And more importantly, there should still be an alternative iOS port with virtual buttons like the Android one. Each game would have the choice to use the port with virtual buttons or the one without. There are a lot of reasons. Moving the hero with the mouse is a huge gameplay change. Old games were released years ago and I can't test them all with a completely new gameplay. There are sequences that require a lot of precision and I have no idea if it would work. Reimplementing all menus (savegames, inventory, dialogs, dungeon minimap, etc) is just not possible. A good port is is port that works for all games. Simply put, finished games are finished and clickable menus are for new games. Also, there are games from other people and we just can't force this new gameplay to all quest makers.

[vlag]

Actually I was just sharing the work, I didn't want to push in the main repo :)

However about what you said, the mouse handling is done on the quest side so each quest maker is free to only use virtual buttons if he prefer like this, or whatever other way to control with the mouse. This doesn't force anyone to use anything, and I also force no one to port their quest on iOS :) For your current games you can use only virtual buttons if you prefer, and one will be free to make a fork in the future and implement another way to control the hero if it's not enough user friendly.

Thanks for your remarks anyway, if you want to integrate the mouse handling in the sample quest I'll be happy to make these changes.

[wrightmat]

Cool stuff, vlag, thanks! The controls are a bit strange for me sometimes, so I'll probably tweak it, but it's a great start! Time to run off an add an option for full mouse/touch controls to my game :)

[christopho]

Yes vlag these changes are welcome in the sample quest!

"Each quest maker is free to only use virtual buttons if he prefer like this" -> I don't understand. How are they "free"? How can they distribute their game on iOS? We need to make a port with virtual buttons for games that don't have mouse gameplay. Including our old games. The job of ports to be as most compatible as possible with existing games, not the contrary.

The iOS port and the playing with a mouse should be two completely different topics.

Again, mouse gameplay can be awesome in some quests, we probably want for future projects, but why take away the iOS port from quest makers that don't want a mouse gameplay?

[vlag]

Ok I think we don't have the same definition of virtual buttons, actually you are talking about implementing a kind of hardcoded virtual buttons at the engine level, that's it ?

"The job of ports to be as most compatible as possible with existing games, not the contrary." To me the (main) job of ports is to behaves the same way on all platform. In this case it is, while it won't if we add virtual buttons by default on mobile platforms. Actually I prefer to declare current quests incompatible with mobile platforms and provide a single lua file (implementing virtual buttons and activate them only on mobile platforms) to add in the quest to be mobile-compatible rather than maintain several version of the same engine. For makers it is not harder than package the iOS quest and much more flexible.

"The iOS port and the playing with a mouse should be two completely different topics." => Completely agree, for me we can consider this issue as closed (just one commit to do before). The virtual buttons subject should be discussed elsewhere.

[christopho]

I cannot disagree more.

The constraint is that existing quest data should work without any change.

"Ok I think we don't have the same definition of virtual buttons, actually you are talking about implementing a kind of hardcoded virtual buttons at the engine level, that's it ?" That's what the Android port does. And it is only the SDL port that provides it, there is no work to do in the engine. It makes sense that the engine provides something to replace the keyboard on systems that have no keyboard.

"To me the (main) job of ports is to behaves the same way on all platform.". What? Then why are you doing the contrary? Being incompatible is the very different behavior to me. The only job of a port is to make software work on a specific system.

"Actually I prefer to declare current quests incompatible with mobile platforms". What is the point of doing a port then? This is the opposite of portability. We just say to people "Your quest cannot be played on iOS"? (by the way, it perfectly works on Android!)

If existing quests don't work on iOS, it is the fault of the too restrictive iOS port, not the fault of the quests.

[vlag]

"That's what the Android port does" => The Android port uses an SDL1.2 hack made because there were no other way to run SDL1.X on Android. Now that SDL2 exists there are no more need to hardcode buttons since we can use touch features natively. It still may be useful to provide a built-in way to replace keyboard but not to activate it by default, to me this is the responsability of quest makers to activate it or not.

"What? Then why are you doing the contrary?" => I don't. Actually old quests are not playable (but runnable) on mobile precisely because the engine works the exact same way on all platforms. It's not being incompatible, it always was since mobile platform don't have physical buttons. Old quests were just not intended to be released on mobile platform, it is normal to me to adapt them. And seriously, copy/paste a file and call a function is not a big deal, quest makers will spend much more time to package than to add the virtual buttons feature.

"What is the point of doing a port then?" => Like you said the point of doing port is to make a binary that behaves the exact same way, not to emulate physical differencies or to force people to use keyboard-like features rather than modern ways to interact with apps.

[christopho]

Users are very happy with the Android version, 3 years later they still thank us regularly.

[christopho]

I opened a separate issue about playing the sample quest with a mouse: https://github.com/christopho/solarus/issues/972

[wrightmat]

Back on this topic- is there an actual iOS port yet? As in a functioning version of the Solarus engine for iOS? If so, where can it be found?

[vlag]

Hum this is the fun part : I have no Apple Developer Account and XCode forbid to compile for generic iOS device in this case, only iOS Simulator :) Basically the result is pretty much the same, except that iOS Simulator runs x64 binaries and iOS arm ones.

I can subscribe for an account and compile an official iOS port if needed, but I want to be sure that I don't do this just for the test. Else if you have OSX, I can provide my (quite dirty) XCode project so you can test on iOS Simulator.

[slepetit42]

(Since iOS 9 / XCode 7.0, you do not need a paid Apple Developer account to run code on your iOS devices)

[vlag]

Ah thanks, good to know :) To distribute the bundle, I guess that the only way is still the AppStore for non-jailbroken devices or can we use iTunes to push it on the phone (can't test, I don't have iPhone :) )?

[vlag]

There is no official release for now but the engine build and runs fine on iOS.