Skip to content

Bannerlator 2.8.2

Choose a tag to compare

View all tags
@github-actions github-actions released this 26 Jul 21:10
· 2376 commits to main since this release
2.8.2
dc1a78d

Bannerlator

2.8.2  versionCode 51  app-side update

Bannerlator 2.8.2

Run Windows apps and games on Android — no PC and no root required.

2.8.2 is a small hotfix over 2.8.1 — it corrects battery power reporting on devices that report battery current in milliamps (e.g. the HONOR Magic line) and sharpens the in-game performance HUD's accuracy. Everything from 2.8.1 is included. Like always it's entirely app-side — no ImageFS reinstall — your containers, themes, custom accent and per-game settings all carry over untouched. Just install over 2.8.1.

🔧 What's fixed

  • Battery power (Watts) now reads correctly on devices that report battery current in mA (e.g. HONOR Magic 7 Pro) — was showing 0.0W. Current-unit is now auto-detected (mA vs µA), so watts are right on those devices while unchanged everywhere else.
  • HUD engine/API label is now live and accurate — it re-checks the running game continuously instead of latching on the first API, so DirectX 12 / Vulkan / DirectX games (e.g. UE titles) are labeled correctly rather than stuck on the wrong one.
  • Per-core CPU % now fills in on devices where the kernel restricts per-core stats (falls back to a clock-based estimate).
  • FPS reads honestly at rest — the counter decays to 0 when no frame is being presented instead of freezing on the last number (fixes stuck FPS at menus and after switching API in the AIO Graphics Test).
  • HUD stays visible on OpenGL titles — it now follows the focused game window and re-binds correctly across API switches.

🙏 Credits

  • Angel — community tester on a HONOR Magic 7 Pro who reported the 0.0W battery bug, ran every diagnostic and test build, and device-verified the fix.
  • The winlator_ludashi_plus project by squalle0nhart — its battery-current handling showed the mA-vs-µA auto-detect approach we adopted.

⚠️ Testing a 2.9 pre-release (2.9-pre1 / 2 / 3 / 4)? Read this before updating.

These pre-releases carried the Virtual Controller Pro update (PR #156) that you've been testing. 2.8.2 does NOT include it — so updating to 2.8.2 will remove your Virtual Controller Pro setups / profiles.

If you want to keep those controller settings, do NOT update to 2.8.2. Stay on your pre-release and wait for the coming 2.9 release (landing in the next few days), which brings Virtual Controller Pro back — finalized. Everyone else can update freely.

🧩 The Fusion HUD is open source — for other projects to adopt

The performance overlay in this release (and the cross-vendor metric backend behind it) lives in its own forkable, GPL-3.0 library so any Winlator / Wine / PC-emulation project can incorporate it — including the mA/µA battery fix from this release.

  • 📦 Latest release: FusionHUD v1.0 — library .aar + a demo APK to preview it.
  • 📁 Source / fork it: github.com/The412Banner/FusionHUD
  • Consume via JitPack (com.github.The412Banner:FusionHUD:v1.0) or drop the source in directly. Attribution to The412Banner is required under the license's §7(b) term — otherwise fork and ship freely.
❓ Why does OpenGL / DirectDraw FPS differ from the benchmark in the All-in-One Graphics Test?

If you run the All-in-One Graphics Test and notice the HUD's FPS is lower than the benchmark's own on-screen FPS on the OpenGL and DirectDraw cubes — that's expected, and both numbers are correct. They measure two different points in the rendering pipeline.

The HUD reports the displayed frame rate — frames that actually reach your screen.

  • Direct3D and Vulkan games explicitly present every rendered frame 1:1, so the emulator can count each one. Here the HUD and the game's own counter match — the D3D/Vulkan cubes read their true rate.
  • OpenGL and DirectDraw run through Zink (OpenGL-on-Vulkan). The game renders continuously into a shared buffer that the compositor then samples at the display's refresh rate — individual frames are never presented as discrete events the emulator can count. So the benchmark's built-in counter shows how fast the game's render loop spins (often much higher, and uncapped), while the HUD shows how many of those frames are actually composited to the screen (≈ your display's refresh rate).

In short: the benchmark counts the app's internal loop; the HUD counts the frames you actually see. This gap only shows up in uncapped synthetic tests like the cube — normal, frame-limited OpenGL games read the same on both. Surfacing the true internal GL loop rate would require guest-side (Wine/Zink) instrumentation, a much deeper layer; the HUD deliberately stays on the honest displayed rate.

🐛 New: Mali GPU report board

Games misbehaving on a Mali GPU (Exynos / Dimensity / Kirin / Helio)? There's now a dedicated public bug-report board for Mali devices — file a structured report with your logs, and get answers back from the developers in a public discussion thread on each report.

Every report gets its own discussion thread — reply as the original poster (no account or password needed) and the developers answer right there.

Assets 6
Loading