touchHLE
touchHLE copied to clipboard
Add stubs for various APIs
This PR includes some changes I made in an attempt to get some other apps to run. I was unsuccessful (there are a large number of POSIX functions that are missing), but I hope that this can serve as a helpful starting point for improved compatibility.
Cool! I think some of these are a bit too stub-y, but there's some interesting stuff in here… I'll try to remember to look at it more later.
Oh yeah, just curious, what apps were you trying?
Thanks! The apps I tried were:
-
Doom for iPhone 1.0 (open-sourced by the developer: https://github.com/id-Software/DOOM-iOS/tree/0cdbbdf96e4f331676b8ce96e20ac4943d0ff0f7)
- Still crashes due to multiple POSIX functions not being implemented. I stubbed a few more of these (not included in this PR because they're incomplete) but gave up because there were too many.
-
Rat on a Skateboard (iOS 2.2.1+)
- This app tries to initialize a CADisplayLink (among other things) and fails. CADisplayLink was not introduced as public API until iOS 4.0, but it appears that this app got around that on earlier versions by initializing it through NSClassFromString. This is also why I had to implement UIDevice, as the app compares the system version to see if it needs to use NSClassFromString or if it can use the public API.
I think Wolfenstein RPG uses POSIX stuff too, I'm guessing it was developed by the same team or shares some code.
I apologise if you can't comment etc due to the current interaction pause btw. Feel free to contact me via another means if you want, but I'll probably not respond very quickly.
Would you mind if I just cherry-pick the commits I'm happy with straight to trunk, and then I review the ones I think could be improved?
Sure, go ahead!
Can you certify the following? I'm thinking of requiring it for future contributions:
Developer Certificate of Origin
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
Thanks for your contributions, I can see you've put in a lot of work. Sorry for being so picky…
I have a local branch with some cherry-picks from this that I'll merge into trunk at some point:
$ git log -6 --pretty=oneline
bc3e81eca6c8671c00d0b6e25fe60fb9fe7985fb (HEAD -> nitinseshadri-cherry-picks) Add explanation for 0x7C8 constant
90fabafb88ad03095396d3f5cd6c421779214680 Remove Monkey Ball-specific alcMacOSXMixerOutputRate hack
3bc75111f1f3e17ec4122be9a775d241251d5c1e Add Apple-specific alcMacOSXMixerOutputRate to OpenAL
475bb5348613f616a71507a66f4d33fff127b3e9 Add support for floats as format arguments in printf et al.
0ba998acee445956dc496ceb35a971e74203b043 Add some audio session functions to AudioToolbox
3183b792f5b4a3f757ee16c56dffa663127a5275 Add support for landscape right orientation
In general my policy is to only use stubs where the action or result value of the function/method is not likely to be important. I'm worried that otherwise, the execution flow of the emulated app is going to diverge in weird ways and strange bugs will appear. This policy, and some stylistic things, are why I've cherry-picked so few of these.
Btw, I have a private Discord server specifically for development discussion, if you are interested. You can join it if you want to (email me for an invite).
What are your thoughts on the changes related to -[UIView layoutSubviews] and -[UIApplicationDelegate applicationDidBecomeActive:]?
I actually tried adding applicationDidBecomeActive:
for Super Monkey Ball, but it didn't affect whether the app ran correctly in any way, and if I remember correctly it caused it to call an extra API that I didn't feel like implementing. So it was just for convenience that I skipped it. Likewise, Super Monkey Ball doesn't seem to need layoutSubviews
.
But I'm sure we'll have to call those eventually.
I guess adding a default implementation of layoutSubviews
is harmless.
I actually tried adding
applicationDidBecomeActive:
for Super Monkey Ball, but it didn't affect whether the app ran correctly in any way, and if I remember correctly it caused it to call an extra API that I didn't feel like implementing. So it was just for convenience that I skipped it.
I think I ended up implementing those. I think it was glDeleteFramebuffersOES() and glDeleteRenderbuffersOES(). The app also calls those in layoutSubviews and in applicationWillTerminate.
I notice you're appending new commits to correct issues in older commits. Perhaps because my old employer used Gerrit, I prefer to modify the old commits instead by editing the git history, so each commit is complete and self-contained. I can recommend git rebase -i
if you're not familiar with it.
You don't have to do this yourself though, I'm going to do it anyway when merging.
It's no problem for me, but you may want to rebase against the latest trunk so that you don't get weird duplicates of some of the commits merged in from trunk.
Should be good now. I rewrote the history so it was a bit clearer, but you might need to re-cherry-pick things as a result.
Thanks a lot, this looks much cleaner!
Uhh, did you miss my comment about the Developer Certificate of Origin from earlier? I don't need you to actually sign all the commits or anything, but if you can at least tell me you agree with all of it, that's reassuring. (Sorry, I'm a bit paranoid with this particular project…)
Yes, I agree with all parts of the Developer Certificate of Origin.
I've merged most of these now, thanks a lot! I've commented on the remaining ones that I noticed needed fixes, and the rest are things that I don't want to merge (or possibly things I missed).
I've merged most of these now, thanks a lot! I've commented on the remaining ones that I noticed needed fixes, and the rest are things that I don't want to merge (or possibly things I missed).
I think I addressed all the comments; the only things which I think you missed were
- Add stub for [UIView setExclusiveTouch:] (unless you don't want to merge this)
- Add [UIView layoutSubviews:] and [UIApplicationDelegate applicationDidBecomeActive:] (works with Super Monkey Ball now that glDeleteFramebuffersOES and glDeleteRenderbuffersOES are implemented, unless there is another reason to not merge this. Some other apps appear to use both places to do initialization so I think it would be worth merging.)
Add stub for [UIView setExclusiveTouch:] (unless you don't want to merge this)
I want to skip this for the time being since I'm pretty sure we wouldn't use the right behaviour. It might be trivial to do a real (if hacky) implementation though by storing which view has exclusive touch somewhere?
Add [UIView layoutSubviews:] and [UIApplicationDelegate applicationDidBecomeActive:] (works with Super Monkey Ball now that glDeleteFramebuffersOES and glDeleteRenderbuffersOES are implemented, unless there is another reason to not merge this. Some other apps appear to use both places to do initialization so I think it would be worth merging.)
Oh, sorry, I didn't realise you'd re-enabled those. Hmm, sure, I'll probably merge those soon. We should probably also send applicationWillResignActive:
when quitting.
Oh, sorry, I didn't realise you'd re-enabled those. Hmm, sure, I'll probably merge those soon. We should probably also send
applicationWillResignActive:
when quitting.
Thanks! applicationWillResignActive:
isn't sent when quitting, it's only sent when there is a temporary interruption (e.g. phone call, text message), so I don't think we'd need to send it.
Oh really? Hmm, maybe I need to re-read the application lifecycle docs.
I've now cherry-picked what I think are all the remaining ones:
$ git log -4 --pretty=oneline
a295b05cf7ee1a44350acb49b8f273b53dded2ec (HEAD -> trunk) Add layoutSubviews and applicationDidBecomeActive:
7174fc62b82b408d48c0f81fa52dfd4cb1a22da2 Add basic implementation of objc_copyStruct
51912f208e25c4d13ac55003bc9cc1d359864d7a Add libc strncmp
d8a6ea289b12e6fff65bf8ecc538c794b4c89ef3 Add [NSTimer invalidate]
The only one I didn't cherry-pick is the path component thing.
I've acknowledged your changes in the changelog and credited you via your GitHub username: f061f63e6e9f4e6864d4e4a2b31352984024afb7.
If you'd prefer to be credited in a different way, please let me know!
Thank you!
I personally believe the discord server should be open to the public, but read only unless you are an actual developer. That way enthusiasts can check in with development, and you will not have to deal with spam.
@upintheairsheep My time isn't free and I don't want to have to deal with tons of questions from novice users all the time. With that said, I understand what you're asking for. I would like it to be easy to keep up with new releases and so on. I'm just not sure what way to do it.