[Core Port Req.] touchHLE (older iOS)

[InfamousKnight]

Upstream info

• Website
• Target platforms: Windows, probably Linux
• Source repo
• Language(s): Rust
• License: Mozilla Public License, version 2.0.

Merits

Because of some ios exclusive titles. I would use it for driver and crystal defenders vanguard

compat list

Technical details

• unknown if can export w/ C FFI
• doesn't have savestates of its own

[InfamousKnight]

linux is supported: https://github.com/Oscar1640/TouchHLE-Linux-builds-UNOFFICIAL/releases

[SuperGamer18]

touchHLE is in a somewhat heavy WIP status, so I don't really think it will come to BizHawk anytime soon.

[InfamousKnight]

The same thing can be said about a lot of cores out there. Even ones that are well developed won't be coming anytime soon either.

[YoshiRulz]

I initially thought the same, but look at their game compatibility list—their 5-star list is about as long as the full library of some of our emulated systems.

[SuperGamer18]

@InfamousKnight well, yes, that is a correct statement, but you can really see that touchHLE is in a WIP state, even when compared to those well-developed cores/emulators you say.
@YoshiRulz that is also a very good point, but why even consider adding iOS when there's no Android emulation core here? (Also as you probably know, Android emulation is much more advanced than iOS emulation, yet both are far from perfect)

I'm not against adding touchHLE to BizHawk btw, I'm just saying that it doesn't make much sense to add it in the state that it currently is. Heck, I would even dare to say that obscure platforms such as the My Vision, CD-i, etc. have better emulation than iOS.

[Spikestuff]

I initially thought the same, but look at their game compatibility list

The thing is the compatibility list is also a small amount compared to the actual available list of iOS 2/3 titles.
Like it's safer to say that 0.1% of titles are actually playable, and that's being generous.
Heck I thought someone would've tested Myst before me, but it was the 333rd title that was reported.

---

In an opinion stance I agree with @SuperGamer18 in that can we focus on emulators that have higher compatibility first, ones that have been highly requested (triple requested), or benched since 2017, or we support the emulator's other systems and potentially a check may help port it across (referring to MAME CD-i, I don't remember the info here I just remember "checkbox") and would produce a large output or one that has hit a wall, before putting in something that's basically an immediate dead end that would need to be constantly updated with each release. Can we wait like 2 more years for it to mature and reassess how far that it's progressed since then?

Heck something of practically a statement in regards to the LibRetro cores is "It only took ~3 changes to get it to build under Waterbox". Obviously I know the part where you need to do the required adjustments and whatnot, but some requested cores (like 5%) only option is essentially the LibRetro ones.

[YoshiRulz]

I initially thought the same, but look at their game compatibility list

The thing is the compatibility list is also a small amount compared to the actual available list of iOS 2/3 titles. [...]

You've missed my point. I'm saying that its supported library in absolute terms is comparable to some of our other systems, and hence I didn't immediately reject this request.

[comparisons to other ports and requests]

We have no policy of prioritising certain cores for inclusion—the only hard rule is that they need a certain level of functionality (rerecording-capable). Other than that, there are only technical barriers. Whatever developers choose to work on is what makes it in.

---

[...] why even consider adding iOS when there's no Android emulation core here? (Also as you probably know, Android emulation is much more advanced than iOS emulation [...]

Android emulators, as far as I know, are all QEMU-based i.e. they use host virtualisation. We can't do that. Knowing nothing about touchHLE apart from that it's written in Rust, I'd say it's likely to be structured in a way that cleanly separates the emulation code from the interface, and is unlikely to have savestate issues (now or in the future—OP said it didn't have savestates at the time).

[SuperGamer18]

@YoshiRulz fair point, but I wasn't even asking for an Android emulation core anyways (AFAIK Android emulators don't have savestates either)