godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
90.34k stars 21.06k forks source link

iOS Safari supported platform? #26554

Closed robgraeber closed 3 years ago

robgraeber commented 5 years ago

Godot version: Godot 3.1 beta 10

OS/device including version: Latest iOS 12

Issue description: Hey all this is more of a question of which platforms are supported by Godot 3.1. I noticed with GLES2 that html5 exporting is working with Desktop Safari and probably Edge. But I haven't been able to get a project to work with iOS Safari.

Also are there any plans to improve the .wasm file size? It's about 25mb ungzipped for a base project while Unity3d is able to get its equivlant package down to ~3-4 mb ungzipped.

Steps to reproduce: I tested it with Dodge The Creeps and it works on Desktop Safari but loads forever on iOS Safari. If you're interesting in debugging, I can hook up my phone for console logs.

Minimal reproduction project: Dodge The Creeps exported with HTML5 and GLES2.

Calinou commented 5 years ago

Also are there any plans to improve the .wasm file size? It's about 25mb ungzipped for a base project while Unity3d is able to get its equivlant package down to ~3-4 mb ungzipped.

You can build a custom HTML5 export template with unneeded modules disabled, see Optimizing for size in the documentation.

That said, I don't think HTML5 mobile gaming is conducive to a good user experience; the overhead is huge compared to a native application, and it'll show even more on a mobile device.

robgraeber commented 5 years ago

@Calinou there are good use cases for html5 mobile games like facebook instant games and other chat game platforms especially in Asia. I'd agree that it wouldn't be a primary target for most people unless file sizes were able to get down, but I could see developers having an existing mobile game they want to port to those platforms. Even if it's bit laggy it'd be great for online demos of some visual novel and point and click games too.

Overall I think if the level of effort is not too high (we have support for wasm + webgl 1 already), it'd be great to fix support for mobile browsers. It'll be valuable as a secondary target.

leonkrause commented 5 years ago

I don't have an iPhone, so I'll need console logs

robgraeber commented 5 years ago

@eska014 console log is: Unhandled Promise Rejection: Error: Out of executable memory in function at index 48863

From googling looks like iOS effectively lowered it's wasm limit from iOS 11.2 to now because of how they mitigated their spectre vulnerabilities. Supposedly iOS 12.2 will have a higher memory limit which comes out in a month or two. Not sure if it'll work after iOS 12.2, but seems like the base wasm memory usage for an empty godot project is greater than the memory usage in an empty Unity3d project.

https://forum.unity.com/threads/webassembly-no-longer-working-on-ios-11-2-2.511905/ https://bugs.webkit.org/show_bug.cgi?id=181723

robgraeber commented 5 years ago

I don't think it's feasible fixing wasm on iOS, but asm.js support could be added via Emscripten which appears to be already used within godot. And asm.js builds would be used for all the unsupported browsers.

FWIW Unity3d supports asm.js and performance was relatively decent for a production iOS game I tried compiling.

meinkush commented 5 years ago

just for general knowledge, i was able to run an empty project on an iphone 6 by disabling all modules and the javascript_eval option, don't know how much exactly needs to be disabled for it to run though, going to do some more test and will get back here if i can get more info on that

meinkush commented 5 years ago

ok so it turns out that it can run with websockets and complex gui elements enabled, if you load too much it just reload the page automatically from the memory problem, biggest issue i can see from here on out is that it converts all vectorial data to as close as it can to (0,0) for example, i render an empty scene with just a button in the middle and it converts it to the smallest possible size and puts it in the left upper corner, maybe it's not detecting the screen size? idk but the button is working

cerk commented 5 years ago

biggest issue i can see from here on out is that it converts all vectorial data to as close as it can to (0,0) for example, i render an empty scene with just a button in the middle and it converts it to the smallest possible size and puts it in the left upper corner, maybe it's not detecting the screen size? idk but the button is working

I have a bunch of CheckButtons and Labels in my test scene. I am able to get the scene running as expected on lots of different browsers except for iOS Safari Mobile (I have not checked iOS Safari desktop). iOS Safari Mobile renders all the CheckButtons and Labels on top of each other at the upper left corner of the screen. Have you found a solution/workaround to this issue?

Note: I selected OpenGL ES 2.0 as the renderer for the project.

DigNZ commented 5 years ago

I'm also experiencing this layout issue on ios for html5 exports. All UI controls are in the top left corner, they are sized to the smallest possible - e.g. if a button have an image on it the full image will be shown but layout padding and margins seem to be all zeroed out. I attempted a work around by using the surrounding html to set a specific size in the index.html but either I didn't do it right or it wasn't the correct fix. My project requires html5 working on android and ios so still looking for a fix. Should this be reported as a separate issue to the original or is it related?

kroltan commented 5 years ago

I can reproduce the situation as the previous commenters. I managed to get some images displaying the issue. I built the export template with the following parameters:

scons -j6 p=javascript target=release use_lto=yes optimize=size tools=no module_bmp_enabled=no module_bullet_enabled=no module_csg_enabled=no module_dds_enabled=no module_enet_enabled=no module_etc_enabled=no module_gdnative_enabled=no module_gridmap_enabled=no module_hdr_enabled=no module_mbedtls_enabled=no module_mobile_vr_enabled=no module_opus_enabled=no module_pvr_enabled=no module_recast_enabled=no module_regex_enabled=no module_squish_enabled=no module_tga_enabled=no module_thekla_unwrap_enabled=no module_theora_enabled=no module_tinyexr_enabled=no module_vorbis_enabled=no module_stb_vorbis_enabled=no module_webm_enabled=no module_websocket_enabled=no disable_3d=yes deprecated=no minizip=no module_jpg_enabled=false module_opensimplex_enabled=no module_svg_enabled=no module_upnp_enabled=no

Notice how some elements are not placed entirely at the top left. Those have a rect_min_size and are within a VBoxContainer, so it seems a problem either with the default sizes or anchors of elements.

iOS appearance, everything jumbled to the corner Correct positioning of all elements

kroltan commented 5 years ago

I added asm.js support to the Godot fork we are using here at DOT, dotdigitalgroup/godot@asmjs-support. It seems to mostly work, except that sound playback is extremely broken on iOS. Fortunately we can live with that for our current use case.

This selects between the WASM and asm.js engines depending on the browser's WASM support, but with iOS blacklisted. That way iOS devices always use asm.js, while other systems avoid it. If you want to try out that branch, note that you need to build both the web template, as well as the editor itself, and set a memory heap size in the export options (since asm.js requires a fixed memory allocation)

DigNZ commented 5 years ago

I added asm.js support to the Godot fork we are using here at DOT, dotdigitalgroup/godot@asmjs-support. It seems to mostly work, except that sound playback is extremely broken on iOS. Fortunately we can live with that for our current use case.

This selects between the WASM and asm.js engines depending on the browser's WASM support, but with iOS blacklisted. That way iOS devices always use asm.js, while other systems avoid it. If you want to try out that branch, note that you need to build both the web template, as well as the editor itself, and set a memory heap size in the export options (since asm.js requires a fixed memory allocation)

I also don't particular need sound for my use case either. I'll try this out thanks.

Edit works great thanks.

ChronoDK commented 5 years ago

I added asm.js support to the Godot fork we are using here at DOT, dotdigitalgroup/godot@asmjs-support. It seems to mostly work, except that sound playback is extremely broken on iOS. Fortunately we can live with that for our current use case.

This selects between the WASM and asm.js engines depending on the browser's WASM support, but with iOS blacklisted. That way iOS devices always use asm.js, while other systems avoid it. If you want to try out that branch, note that you need to build both the web template, as well as the editor itself, and set a memory heap size in the export options (since asm.js requires a fixed memory allocation)

That's super nice! Would be great to see this in the main branch.

kroltan commented 5 years ago

I think for it to be merged something should be done with the sound playback, ideally fixing it, as well as more extensive testing. I do not have the required knowledge nor time for such at this moment, but welcome PRs into that branch if anyone does find out the issue.

scottkunkel commented 5 years ago

would it be possible to push this back into this master? Nvm, just saw your pull request. Thanks!

mrdev023 commented 5 years ago

Patch doesn't work for me And the files are too heavy for the web

scottkunkel commented 4 years ago

Patch doesn't work for me And the files are too heavy for the web

Please be more specific. There are engine and project files. I have a project that comes in at 50Mb, but the engine itself is only 300kb.

Faless commented 3 years ago

To answer the OP: Yes, iOS Safari is supported as much as Apple allows, which means, basic features are expected to work but functionalities that requires modern web standards might be lacking. This is the case for example for WebGL2 (i.e. GLES3 support), threads support, etc. We hope to provide an improving support to standard-compliant browsers, but once again, we can't do anything (sane) about them not supporting specific standards. That said, the situation seem to have improved a lot lately on the WebKit/Safari side, which gives us hope.

I'm closing this issue, as there isn't much more to discuss. Specific problems must be tracked in separate issues (one issue per problem).