ml
0f59898bb6
build / build (push) Successful in 2m15s
<layout> defaultWidth/defaultHeight/minWidth/minHeight/gravity hint - Quest's Home shell otherwise defaults a freshly-launched 2D panel to a portrait shape, cropping the game's 4:3 640x480 content down to a sliver. - The actual root cause of the remaining crop (game rendering into one corner of an otherwise correctly-sized panel), found via on-device logcat and the new diagnostics below rather than guesswork: ChangeScreenSize() (engine/src/MacSrc/ShockBitmap.c) calls SDL_SetWindowSize() whenever the game sets its video mode. That's a desktop-only operation in effect - Android has no SetWindowSize driver hook, so SDL's generic layer instead overwrites its own cached window size to the game's internal resolution (640x480) and synthesizes a resize event from that, desyncing SDL's notion of the window size from the real, unchanged Android surface (e.g. 1600x1200). Both SDL's own renderer viewport and the engine's custom GL viewport then scale against that corrupted cached size. 10-android-no-window-resize.patch skips the desktop-only SDL_SetWindowFullscreen/SetWindowSize/ SetWindowPosition calls on Android, keeping the legitimate SDL_RenderSetLogicalSize/offscreen-bitmap setup. - 06-android-resize-event.patch: also react to SDL_WINDOWEVENT_RESIZED in the engine's event loop, not just SIZE_CHANGED - Android's SDL video backend never sends SIZE_CHANGED for surface-driven resizes, only RESIZED, an independent gap worth closing regardless of the bug above. - 08/09-android-logcat-*.patch: route the engine's existing log.c output (previously plain fprintf(stderr,...), never actually captured by logcat on this build) through __android_log_vprint instead, so every existing INFO/DEBUG/WARN/ERROR call site becomes visible for on-device debugging. This is what made the diagnostic below (and everything since) observable at all. - 07-android-size-diagnostics.patch: one-time startup log comparing SDL_GetWindowSize/SDL_GL_GetDrawableSize/SDL_GetRendererOutputSize - the evidence that actually pinned down the SDL_SetWindowSize bug above. - QuestShockActivity.java: add a diagnostic onSizeChanged() log on GameSurface, used to rule out a later Android-side panel relayout as the cause before finding the real one.
32 lines
1.5 KiB
Diff
32 lines
1.5 KiB
Diff
--- a/src/MacSrc/ShockBitmap.c
|
|
+++ b/src/MacSrc/ShockBitmap.c
|
|
@@ -42,11 +42,28 @@
|
|
|
|
SDL_RenderClear(renderer);
|
|
|
|
+#ifndef __ANDROID__
|
|
+ // On Android there's exactly one OS-controlled-size surface - no
|
|
+ // desktop-style window to resize, move, or toggle fullscreen on.
|
|
+ // SDL_SetWindowSize() still "succeeds" there (Android has no
|
|
+ // SetWindowSize driver hook, so SDL's generic layer just overwrites its
|
|
+ // own cached window->w/h to the requested game resolution, e.g.
|
|
+ // 640x480, and synthesizes a resize event from that) - which desyncs
|
|
+ // SDL's own notion of the window size from the real, unchanged Android
|
|
+ // surface size (e.g. 1600x1200), and that desync is exactly what then
|
|
+ // makes both SDL's internal renderer viewport and this engine's own
|
|
+ // custom GL viewport (OpenGL.cc's opengl_resize(), driven by that same
|
|
+ // now-wrong cached size) shrink to the game's resolution instead of
|
|
+ // filling the real surface - confirmed on-device via added logcat
|
|
+ // diagnostics (see android/engine-patches/07-09) showing the correct
|
|
+ // 1600x1200 size at startup, then this exact call sequence collapsing
|
|
+ // it to 640x480 the moment the splash screen sets its video mode.
|
|
extern bool fullscreenActive;
|
|
SDL_SetWindowFullscreen(window, fullscreenActive ? SDL_WINDOW_FULLSCREEN_DESKTOP : 0);
|
|
|
|
SDL_SetWindowSize(window, width, height);
|
|
SDL_SetWindowPosition(window, SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED);
|
|
+#endif
|
|
|
|
SDL_RenderSetLogicalSize(renderer, width, height);
|
|
|