Yes, it caused build errors. To successfully generate the APK, I had to remove some Windows-specific files. Those files contained Windows-only code, such as
anti-cheat/anti-hack components, DirectX, and system encryption, which do not exist on Android. Removing them is a normal and expected part of porting the project to Android, allowing it to compile and run correctly on the platform.
I successfully generated the APK for both
x86 (LDPlayer and other emulators) and
ARM (mobile devices).
I'm still running more tests and have noticed a few bugs. The HUD also still looks a bit off, but nothing that some additional development and polishing can't fix.
I'm continuing to work on the project, and I'll post more updates soon.
The gl_compat.cpp layer is a
functional workaround, not an optimized engine. It was built to "make it run", not to "run fast". The game logic itself (AI, networking, etc.) is not the bottleneck — the emulator proves this by hitting 40 FPS with identical code.
There is no "easy" optimization that fixes this. Every deeper pipeline change either:
- Crashes on Mali (direct VA)
- Stalls on Adreno (VBO skip)
- Breaks rendering (deferred batching, double buffer, vertex baking)
The root cause is systemic: ~1400 GL driver calls per frame through a legacy compatibility layer. On real mobile GPUs (Mali/Adreno), each call incurs kernel transition + pipeline validation overhead that simply doesn't exist on x86 emulators.
For a production-ready mobile build with 50+ concurrent players, the rendering backend must be replaced with a modern API — sokol_gfx, bgfx, or a complete engine migration