Opened 2 years ago
Closed 2 years ago
Last modified 2 years ago
#12578 closed defect (fixed)
iOS build fails to launch with new GUI
|Reported by:||thevolumeremote||Owned by:||criezy|
I've tried three (git/daily) builds since the enhanced GUI was released and so far iOS has crashed upon launch every time. I usually compile a daily build once a month or so and it always runs/works great- until the gui was remastered, now it won't launch.
tested on iOS 13.6 and iOS 14.0 and iOS 14.4 both jailbroken and non-jailbroken (Apple dev account signing for non-JB).
Not sure how to provide more information for you on iOS but I have lots of experience compiling ScummVM for iOS and have been doing it for years, happy to help however I can, but for now this is the best I can do without a console etc.
thanks for all you do for us.
Change History (4)
comment:1 by , 2 years ago
|Component:||--Unset-- → Port: iOS|
comment:2 by , 2 years ago
The issue is that the iOS backend asserts in setMouseCursor() because of the pixel format of the mouse cursor that is not supported..
frame #3: libsystem_c.dylib`__assert_rtn + 312 * frame #4: scummvm`OSystem_iOS7::setMouseCursor(void const*, unsigned int, unsigned int, int, int, unsigned int, bool, Graphics::PixelFormat const*) (.cold.1) at ios7_osys_video.mm:486:2 [opt] frame #5: scummvm`OSystem_iOS7::setMouseCursor(buf, w, h, hotspotX, hotspotY, keycolor, dontScale, format) at ios7_osys_video.mm:486:2 [opt] frame #6: scummvm`Graphics::CursorManager::pushCursor(buf, w, h, hotspotX, hotspotY, keycolor, dontScale, format) at cursorman.cpp:68:12 [opt] frame #7: scummvm`GUI::ThemeEngine::showCursor() at ThemeEngine.cpp:2059:13 [opt]
This would probably have been fixed by commit 26dc725ed2 (GUI: Convert the cursor bitmap to the overlay format), but for some reason that commit was reverted.
comment:3 by , 2 years ago
|Status:||new → closed|
This should be fixed with commit 37aa9f908.
comment:4 by , 2 years ago
Confirmed working on my end, iPhone 11 13.6 and iPad Pro on 14.4.1
Thank you criezy!
thevolumeremote: Can you do a git bisection to determine exactly which commit triggered this? If not, can you at least give a "good" and "bad" commit range so the iOS porters can try to work out the cause.