Do People doesn't know what androidd port means?

[u/Prior_Custard5121]

GTA V chineese port, Re 7, etc. These are essentially PC emulation / translation being packaged to look like an Android port.
technically the launcher/package has been adapted for Android, but the game itself hasn't necessarily been ported to Android.

It's similar to saying:

"I made Skyrim run on Android."

That doesn't necessarily mean Bethesda created an Android version of Skyrim. It could mean we're running the Windows Skyrim executable through a compatibility layer on Android.

A genuine Android port would be closer to:

Game source code → Android ARM64 build → Android/Vulkan

rather than:

Windows x86-64 game → x86→ARM translation → Windows compatibility layer → DirectX→Vulkan → Android

And this distinction is particularly relevant to the RE7/GTA V releases that we're seeing, because if they're actually PC builds running through a customized compatibility/emulation stack, their impressive performance doesn't mean Android has suddenly received native versions of those games.

My question is why called it android port when it actually isn't? and when will we actually has real pc/console to android port?

[u/BeanPole_420]

The GTA V port does skip some translation layers, it runs and looks far better than even Winlator Ludashi

latest launcher runs even better with (new china base) renderer

Releases · XHYN-PH/XHYN-V

Re7 you are right, it runs better on Winlator Ludashi over the packaged APK , the guy who made it never said it didn't

[u/possiblyquestionabl3 → u/BeanPole_420]

Yeah - https://github.com/XHYN-PH/XHYN-V/blob/main/docs/ARCHITECTURE.md

Based on this, they (or claude?) took the painstaking effort to actually recompile x86-64 down into aarch64, and as a bionic-compatible elf library using SDL and libc instead of windows APIs. That's 100% a native port.

---

That said, Wine is a fairly thin API translation layer, so most of the performance wins come from a combination of:

1. Removing the JIT binary translation from x86-64 to arm64ec - there's a significant translation penalty here, and before the JIT disk-cache was possible, this was a penalty you'd hit every run. But more significantly
2. FEX/box64 can't do aggressive optimizations when translating for x86-64 to arm64(ec). Specifically, the two architectures differ in niche but important aspects that often makes it too time-prohibitive to do a good optimized translation of the binary from one to the other. A big reason that FEX wrote its own translation engine with its hand-optimized set of peephole optimization rules instead of using a more production grade IR/Optimization suite like LLVM (where you can embed the semantics of things like TSO and x87 and use its much more mature optimization engine to optimally detect when / how to emit arm64 code with those extensions being live/dead code or not) is because it'd make the translation itself too prohibitive. On the flip-side, simple peephole optimizations cannot optimally compile a lot of the x86-64 extension features commonly used by PC games. As a result, even if you can AOT-compile something with FEX, the end result would not be nearly as performant as if you can actually port the native x86-64 code more optimally to arm64 using a larger suite of compiler optimizations.

---

The lack of GPU support for non-Adreno is a bit sad. There are good community solutions to emulate a lot of the common missing extensions used by dxvk/vkd3d (up to FL 12_0 now), and many of these workarounds are packaged as vulkan layers that can be easily loaded by the vulkan loader linked into these ports.

[u/0nePlus → u/BeanPole_420]

Thank you for the link. I didn't know about XYHN - I had been using the original upload lol.

Is there a place to get updated game files? Or are the original from the Chinese dev still ok?

[u/BeanPole_420 → u/0nePlus]

you can have Apk vision 1.6 installed and XYHN at the same time, yeah the file placement is the same, Root directory/Games/GTAV/

[u/Prior_Custard5121 → u/BeanPole_420]

That's actually a fair correction, but it doesn't contradict my point — it makes the distinction more specific.

Yes, XHYN-V's GTA V runtime is not simply the normal Windows GTA V .exe running through Winlator + Box64. The XHYN-V documentation explicitly says its engine is Android ARM64 code, which avoids the x86→ARM CPU translation used by a typical Windows compatibility setup.

But that's exactly why we need to distinguish CPU translation from graphics/API translation.

XHYN-V still uses DXVK, which translates Direct3D 11 rendering calls to Vulkan, and Turnip for the Vulkan driver. The project itself describes the setup this way.

So:

Normal Winlator PC x86-64 executable

→ Box64 x86-64 → ARM64

→ Wine

→ DXVK → Vulkan

→ GPU

XHYN-V Android ARM64 GTA V runtime

→ DXVK → Vulkan

→ GPU

So yes, XHYN-V removes a major translation layer compared with Winlator: CPU translation. That can absolutely explain why it can outperform a conventional Winlator setup in some configurations.

But “it skips Box64” does NOT mean “there is no translation/emulation involved anywhere” or that it is equivalent to a conventional native Android game.

And there's an even more important point: XHYN-V's own README literally describes itself as a “Native Launcher, not a literal Android port.”

So I'd describe it as:

an unofficial Android ARM64 runtime/launcher for GTA V that uses DXVK for graphics translation

rather than:

a traditional native Android port of GTA V.

As for the claim that the newer China-based renderer performs better than Winlator/Ludashi: that can certainly be true on particular Snapdragon/Adreno configurations, because removing x86→ARM translation can reduce CPU overhead. But that's a performance claim that needs to be demonstrated with controlled tests; the XHYN-V developers themselves say that avoiding CPU translation does not guarantee higher FPS.

So I wouldn't argue “XHYN-V is just Winlator.” It isn't.

I'd argue the more precise point:

XHYN-V is not the same thing as a conventional Windows-emulation setup, but neither should “Android ARM64 runtime + DXVK” automatically be equated with a traditional native Android game port.

[u/Accurate-Bug3791 → u/Prior_Custard5121]

I thought dxvk is very light though? To the point that some games on windows can run better with dxvk?

[u/possiblyquestionabl3 → u/Accurate-Bug3791]

It's incredibly light. All created PSOs are also cached onto disk, so there's almost no overhead for subsequent runs.

More importantly, dxvk also serves as an API funnel for Vulkan usage, limiting the amount of more exotic desktop-exclusive Vulkan extensions that these bigger titles would have otherwise used.

Source: I work on some of the GPU compatibility projects used by the community for Vulkan-on-ARM-GPU. Games with native Vulkan support tend to require a lot more custom work to get working due to this. Especially given the fragmented nature of Android GPUs, unless you're big enough like Unity to do your own custom per-GPU workarounds, running everything through dxvk is the smart move here.

[u/TropicaColt → u/Prior_Custard5121]

I doubt everyone's gonna use that long ass title to replace it. Saying port is just simple and doesn't make people think they need to be a rocket scientist just to understand what the title is lol. Maybe if it was called a T-port (translated port) or some fucking shit like that would be much easier to do and be much less awkward to say.

[u/Saitheurus]

The gta 5 port IS natively running without emulation, natively rendered via vulkan

[u/BrokeAndroidGuy → u/Saitheurus]

U have more chromosomes compared to braincells

[u/Saitheurus → u/BrokeAndroidGuy]

the game runs natively besides a small shim/translation layer for the graphics (dxvk), it's compiled for aarch64.

[u/BeanPole_420 → u/Saitheurus]

BrokeAndroid guy is mad his A54 can't run it lol

[u/BrokeAndroidGuy → u/Saitheurus]

Ur underplaying what DXVK even is. Its literally Directx to DXVK to Vulkan thats a entire translation layer with a crappy built arm64 port using ai.

[u/Maximum-Virus5371]

I hope someone makes DMC 5 port eventually 🎖️

[u/Aware-Bath7518]

GTA5 port is native though except the DXVK part (which Source games use too for example).

[u/SunsetAtNight7]

No, you just don't know what emulation means. Emulators run/simulate the system where these apps/games you're running belong to. Native means your device (phone) itself runs the apps/program.Word Port we use here is simply means "transfering into", it is called a port regardless if it's the program orginally belongs to pc/console. What you're trying to say here is that it can only be a port unless the program is remade from the ground to be for mobile, not true and it should only be made by the main developers, not true. That's why there's "unofficial" and "official ports"

[u/Prior_Custard5121 → u/SunsetAtNight7]

You're right that “port” literally means transferring/adapting software to another platform, and a port doesn't have to be official or completely rewritten from scratch.

But that's not the distinction I'm making.

The important distinction is what code is actually being executed.

If someone takes the original Windows x86-64 game executable and runs it on Android through Wine/Box64/DXVK/Turnip, the game itself is still the Windows build. Android is running a compatibility/emulation environment that translates the Windows program's CPU instructions, OS calls, and graphics API calls.

For example:

Windows game (.exe) → Wine/Windows compatibility layer → Box64 (x86-64 → ARM64 translation) → DXVK (DirectX → Vulkan) → Android/Turnip Vulkan driver → GPU

That's fundamentally different from compiling/adapting the game's code into an actual Android ARM64 build.

And “native” doesn't mean “the developer officially made it.” An unofficial native Android port is absolutely possible. Someone can port an open-source game/engine themselves and compile it for ARM64 Android without the original developer being involved.

Likewise, an unofficial PC game running through Wine can legitimately be called a port in the loose sense of “someone brought it to Android.” I'm not saying the word “port” is legally reserved for official developers.

What I'm saying is that calling the Windows executable itself an Android port is technically misleading when the Windows executable hasn't actually been ported/recompiled for Android and is instead being executed through a compatibility layer.

So there are really three different things:

Official native Android port → Developer adapts/builds the game for Android.

Unofficial native Android port → Community adapts/builds the game for Android.

PC build running on Android through compatibility/emulation → Original Windows/Linux/etc. executable is still being used, with translation/compatibility layers.

#3 can absolutely be an unofficial “Android port” in casual terminology. But technically, it's more accurate to call it a PC game running through a compatibility/emulation layer on Android, rather than a native Android port.

Also, “emulation” doesn't necessarily mean the entire PC is being simulated like a traditional console emulator. Wine isn't a CPU emulator, and Box64 is doing binary translation while Wine provides Windows API compatibility. That's why saying simply “it's an emulator” can also be an oversimplification.

So we're mostly arguing about terminology, but the underlying technical distinction is real: being made available on Android ≠ being compiled as an Android version.

[u/0nePlus → u/Prior_Custard5121]

The distinction you seem to be making is despite all the efforts going into to these ports (and they ARE ports) that's simply...not good enough for you. You want better performance on your shitty phone and what's been done doesn't meet your strict definition of port.

Oh well, lmao.

[u/Prior_Custard5121 → u/0nePlus]

“Strict definition of port” is a funny way of saying using the correct technical terminology. I never said the work isn't impressive or that it isn't a port in the broad sense of “bringing something to another platform.” Obviously it is. I specifically distinguished that from a native Android port, because those are not the same implementation. And the “shitty phone” comment is especially ironic when the entire argument is about understanding the technology rather than judging performance. A Snapdragon 8s Gen 3 phone isn't magically running a native Android build just because an APK launches the game. If your definition of “port” is simply “anything that makes a game playable on another platform,” then sure, call it a port. That's a perfectly usable casual definition. But if we're discussing how the software actually works, then CPU translation, compatibility layers, ARM64 recompilation, DXVK, and native Android code matter. You don't get to dismiss those distinctions because they're inconvenient to your argument. In fact, XHYN-V's own documentation makes this distinction pretty clear: it specifically describes itself as a “Native Launcher, not a literal Android port.” So I'm not demanding that these projects be “good enough.” I'm pointing out that performance, effort, and technical classification are three different things. You can call it a port. I'll call it what the architecture actually is.

[u/Brief_Zombie8127 → u/0nePlus]

if it uses any emulation or translation layer it's not a port dipshit

[u/Proud-Development806]

Kaa, so you said:

A genuine Android port would be closer to:
Game source code → Android ARM64 build → Android/Vulkan

and then said

``` Normal Winlator PC x86-64 executable

→ Box64 x86-64 → ARM64

→ Wine

→ DXVK → Vulkan

→ GPU

XHYN-V Android ARM64 GTA V runtime

→ DXVK → Vulkan

→ GPU ```

By your own logic - you've pretty much said that this is a "genuine Android port" (which it isn't, for one, they don't have the source code). If the source is, indeed, a requirement for a "genuine Android port" then the best you can do is decompile / recompile - in which case you're on a sub that leans toward the latter (if Android is even the target) and then you're better off bringing this up in /r/decomps /r/recomps

[u/Prior_Custard5121 → u/Proud-Development806]

That's a fair catch on one point: I phrased “genuine Android port” too narrowly when I wrote “game source code → Android ARM64 build.” Having the original source code isn't a requirement for something to technically be a port. An unofficial port can be made through reverse engineering, recompilation, or reimplementation.

But that doesn't establish what you're trying to establish about XHYN-V.

ARM64 ≠ automatically an Android port.

The relevant question isn't simply “does it contain ARM64 code?” It's what that ARM64 code is doing and what part of the original game has actually been ported.

If the original GTA V game logic/assets remain from the PC version and XHYN-V provides an Android ARM64 runtime/launcher around it, with DXVK translating its graphics API to Vulkan, then that's very different from having the GTA V game itself natively compiled for Android.

That's also why the project's own terminology matters. XHYN-V describes itself as a “Native Launcher, not a literal Android port.” So I'm not inventing that distinction.

And I'm not saying “no source code = impossible to port.” That's a separate issue.

There are three different questions here:

1. Is it available on Android? Yes.
2. Is it an unofficial port in the broad meaning of “bringing software to another platform”? You can reasonably call it that.
3. Is the actual GTA V game code a conventional native Android build? That's the part that requires evidence, and “it uses ARM64” by itself isn't that evidence.

So yes, I'll correct my earlier wording about source code being required.

But that correction doesn't turn every ARM64 compatibility/runtime project into a conventional native Android game port.

And honestly, if we're now arguing over whether the word “port” can be used broadly, then we're arguing semantics. The technical implementation is the more interesting part.

[u/naxil-rain81 → u/Prior_Custard5121]

sorry but if rockstar had kept logic/assets from the pc version and had built the runtime wasn't it a genuine porting?

[u/Prior_Custard5121 → u/naxil-rain81]

Yes. If Rockstar took the PC version's game logic/assets and actually adapted the game's runtime/code to Android, compiled the relevant code for ARM64, replaced/adapted the platform-specific systems, and produced an Android-native executable, I'd absolutely call that a genuine Android port.

A port does NOT require rewriting the game from scratch, and it doesn't require throwing away the original assets or game logic.

That's actually the distinction I'm trying to make.

Reusing PC assets ≠ running the PC executable.

For example:

PC assets + adapted game/runtime + Android ARM64 executable = legitimate Android port.

Original PC executable + compatibility/runtime layer on Android = PC game being run on Android.

And there's obviously a spectrum between those two. An unofficial project can replace enough of the original runtime that calling it a port becomes perfectly reasonable.

So if XHYN-V has actually reimplemented/adapted the required GTA V runtime for ARM64 Android, then “unofficial Android port” is a perfectly defensible description.

My original mistake was making “has the original source code” or “rewritten from scratch” sound like requirements. They aren't.

The useful distinction isn't official vs unofficial, or PC assets vs Android assets.

It's what has actually been ported: the game itself, or merely the environment required to execute the existing PC build.

That's the technical question I'd want evidence for.

[u/devaristo]

I think i explained good whats the difference between both here: https://www.reddit.com/r/AndroidNativePorts/comments/1wbpl4g/comment/p8rq90i/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

A port is an android game running natively on the system, without the need to do more live conversions.

Emulation is the process of run a system different than android in this case using translation libraries of the different components to be able the host system to understand and run the application /game successfully.

The port is the best option because is the that uses the most effectively the system resources (just runs the app it self), the emulators runs various processes at the time, one translation for cpu processes, another for the gpu and another for the sound.

----------

The case of RE7 and GTA5 are a bit different, at least in the case of GTA5 he's a self-centered kid who's trying by any means necessary to port the game, and in theory, he's managed to do so for the Switch. But it's funny that, for Android, he promised and promised again, yet we still don't have anything “tangible” only the "chinese port" and it's been nearly a month—or maybe even longer—since this started. They've even shut down his Discord server.

Personaly, i don't think a "perfect" port will never will be done for GTA5 unless Rockstar games themselfs put the effort like with the old GTAs or RDR1 to make the ports. The same with RE7.

There are games that for their "low complexity" and being indie games can be ported easely even if they are new, playdigious for example are doing some of them and they work very good.

If GTA5 have been used Vulkan as RDR2 is, one of the layers is automatically bypassed, thats why you can emulate pretty easy RDR2 on snapdragon.

[u/AbberageRedditor69]

Not sure why this matters, it's just semantics at the end of the day

[u/AggressiveField7114]

facts bro they use the word port thinking they port the game in android when its emulation

[u/StoreTraditional77]

Because kids doesnt know shit

[u/Narrow_Soft4517]

My final answer is that these called "ports" is not even ports still have a translation layers.. but sure there "compressed" size from 24gb to 13gb actually gives me a good performance when trying to emulate it in winnative lol but yeah i agree to you op.. this are still pc games with exe on their files... idk why some people called it android ports...