-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add iOS version of Dolphin #3885
Conversation
The contents of this directory will be copied into the build directory post build. These files make up the user interface and also handle host messages
iOS needs Prepare() for EAGL to know when to prepare it’s frame buffer to be drawn into. iOS also does not have a default frame buffer. GetDefaultFramebuffer() will return the id of the frame buffer to draw into
Since iOS does not have <asm/hwcap.h> or <sys/auxv.h>, we let hardware information remain uninitialized. This will need to be fixed
For std::array we needed <array>. For sys_cache_control we needed <libkern/OSCacheControl.h>
On iOS pages will be mapped ANON and PRIVATE Map the memory arenas as if we are on a 32 bit machine due to lack of virtual memory
iOS controller handling is not finished yet but this is the skeleton that will be used.
Since I was unable to fix MachineContext.h for iOS, I added empty implementations for IOS until a fix can be added
m_flush_trigger.WaitFor() causes Dolphin to crash on iOS around every other time a game is loaded. Remove for now and discover why this causes a crash later
Added specific CMake configurations for IOS
iOS does not have <sys/disk.h>. These functions won’t be used so setting DKIOCGETBLOCKCOUNT and DKIOCGETBLOCKSIZE to arbitrary values serves as a workaround.
Updated readme to include system requirements and build steps for iOS
Those notices are automatically generated by Xcode
This includes quite a bit of external libraries as well, these should be in External, not pulled into the main tree.
|
Are all added files added on purpose? eg Source/iOS/DolphiniOS.xcodeproj/project.xcworkspace/xcuserdata/willcobb.xcuserdatad/ sounds wrong to me. There are lots of whitespace vs tab issues on indenting. We are very nitpicking about this kind of issues :/ And it will very likely fail lint: https://github.com/dolphin-emu/dolphin/blob/master/Tools/lint.sh
|
Review status: 25 of 241 files reviewed at latest revision, 147 unresolved discussions, some commit checks failed. Source/Core/Common/GL/GLInterface/EAGL.mm, line 21 [r1] (raw file):
|
I fixed all whitespace and newline issues. Sorry about that. I'll add .xcuserdatad and similar xcode files to gitignore. All imported frameworks and libraries are not included in the source. They are found on the iPhone and are linked at runtime. Any other libraries or groups of files are purely UI enhancements and are iOS specific. I don't think they belong in external
|
Reviewed 2 of 5 files at r7. Comments from Reviewable |
@degasus Will do. |
Importing common types into an objc file was causing compiler errors. I’ll use uint16_t instead of u16 until this is fixed
Some things:
|
Reviewed 1 of 108 files at r2, 1 of 2 files at r8. Source/Core/Core/HW/GCMemcardRaw.cpp, line 85 [r8] (raw file):
This should not be needed at all. Maybe this here shows an issue somewhere else... Comments from Reviewable |
Thats odd, I'll apply that patch. I removed ZAActivityBar and a few other libraries that we don't really need. RBVolumeButtons lets you use the volume buttons as the left and right trigger for games. It uses some old libraries that let you intercept volume presses. I'll see if updating depreciated APIs is possible I can't get the Xcode variable SRCROOT to point to the actual source root. It points to the parent directory, and I think something related is causing those warnings. Since the build and source directory are "($SRCROOT)/Build" instead of just "($SRCROOT)". If you build in a directory not named "Build", the xcode project will have the wrong path for files. If you know how to fix that @OatmealDome, that would be awesome. I'll be making all of the suggested UI changes. I also removed a bunch of stuff left over from iNDS (and the project it was adapted from) like you suggested. I really should have cleaned up the code before the pull request. Also I'll get rid of the weird AppDelegate shared instance usage.
|
@WilliamLCobb I took a look, but honestly I have no idea what's wrong with $SRCROOT. Not even my google-fu could help. There might be something wrong with the xcodeproj file, but I'm not 100% sure. Perhaps you could create a new project, copy/paste the existing source files in, and see if the new project works?
|
For some reason, a string as the second argument in Set() would match the overloaded function using that string as a bool. This always evaluated to True and wrote “True” to the setting. In order for the string to be correctly handled, you must wrap it in std::string()
openRomAtPath:inView was blocking the main thread. It now correctly dispatches a block to a background queue.
What caused the OSX build to fail? |
iOS and Android were using the exact same images in 2 different folders. This lets iOS support using a shared folder with android. Android support for this shared folder will need to be added in a later pr
Just a question, does this build of Dolphin support the Apple TV? The underlying tvOS operating system is, as far as I know, functionally identical, but the UI would need to be tweaked for Dolphin to run on Apple TV, as it does not have a touchscreen for inputs. Would having an iOS version be reason to seriously consider writing a Metal video backend (Issue 9510)? It could provide possibly necessary performance increases. It is very impressive what has already been done for such a limited device. Reading up on OatmealDome's original forum thread made it seem like the memory was far too limited to get anything playable. Maybe some of this code could be adapted to help with lower memory Android and PC devices as well? |
@Fallcrest There is no support for the Apple TV at this time. I'd say that if this is merged, it can be a big motivating factor for someone to take up the task of writing a Metal backend. It could save us from the horrible OpenGL support from Apple. (Apparently, there are no changes to OpenGL in macOS Sierra, which sucks.) The devices should have enough RAM; the problem I encountered is that operating system limits us on how we can use/"organize" that memory. About adopting the new code: There isn't really any big change in this PR for how Dolphin handles memory. We simply just initialize the memory map like we're running on a 32-bit device. If there's anything wrong in this post, feel free to correct me. |
@OatmealDome Oh yeah... "macOS" Apple again changed the branding. (looking back at all of their old operating systems shows how many times they have changed the naming scheme. It just doesn't make sense.) Someone will have to change that in Dolphin's code/documentation now, won't they... My apologies for misunderstanding the memory management part. I am most certainly not knowledgeable on the topic, I have just been reading a lot of other people's work and I thought that this was connected to other things. Apple has pretty much dropped support for new versions of OpenGL, as far as I know. But then again, they never kept it up to date and never really talked about it, so who knows if they have any plans. Because of their focus on Metal, I doubt they will give OpenGL a second thought, though. I wish they had transitioned to Vulkan which would have been far more useful to Dolphin (and to practically all developers of anything) because of its cross-platform nature. But for now at least, we are stuck with Metal being the only actively supported solution on Apple systems. Which ends up hurting the adoption of Vulkan significantly. Sigh... Even though Vulkan would only be available for the Windows, Linux, and Android builds, (and possibly FreeBSD, I don't really know how drivers are released for there), it still might be something worth looking into as the maintainers of OpenGL and Vulkan will eventually transition away from OpenGL in favor of Vulkan. It would probably be many years before they do that, but it is worth future proofing ourselves, especially when Vulkan has proven to have very good performance. There is also some project called MoltenVK that is working on getting Vulkan to run on top of Metal, so the same API could be used for Apple products with minimal extra work. It is sadly a closed commercial product, so it could not be used here, but the idea might still be useful. It is very late and I have rambled way too much, most of this is probably irrelevant. I am very excited for this PR, iOS was the last major market, so to speak, that Dolphin needed to get into. (Looking forward to Dolphin being ported to various VR systems next. I won't even benefit from that, it will just be very cool.) |
This should be ready to merge once the git issues for the OSX build are fixed. If it looks like a Metal backend will provide a significant speedup, I'll write a basic implementation after this has been merged. |
@WilliamLCobb Okay, I was beginning to look into a Metal backend, but you will almost certainly finish this faster than I would, plus you have the ability to test this on iOS. I was doing some preliminary research while waiting for several PRs to simplify VideoCommons to make the job easier. I might look into doing Vulkan instead. I'm happy that 5.0 is finally out. There are some really cool ideas that will be implemented in the (hopefully) near future. |
Funny you started looking into a backend, @Fallcrest.. I actually started looking into the feasibility of a Metal backend too a few days after I posted that comment lol. It seems perfectly feasible to me. (After my research on how Dolphin's VideoBackends work with VideoCommon... I support your future PRs to clean it up. They would be helpful to me and to future devs.) By lurking on the IRC, I found that the full message from that other dev was that the "C++ bindings were too slow". The simplest solution here is to just call Obj-C stuff from Obj-C++ files. (Perhaps we can add Obj-C++ back to the WIkipedia page if this happens, neobrain? :P) |
@OatmealDome Well, I was beaten to Vulkan as well, but that's fine. Perhaps you or @WilliamLCobb could open up a minimal PR for Metal just so others know that it is being worked on, and so they can voice their opinions. |
degauss told me to post this: here's the very beginnings of a Metal backend (Mac only). |
New iOS pull request: #3941 |
I messed up the last pull request and it stopped updating commits.
Most of the changes are pretty straightforward.
Added iOS directory in Source.
Added new IOS definition when building for iOS
Added build steps for in readme.
CMake will generate an Xcode project in the build directory and copy in the Xcode project and workspace from the iOS directory. The workspace will combine these two projects, allowing full compatibility with future cmake and source changes while also giving control of all of the build settings for iOS. Since iOS is not inherently supported by cmake, this would have been very hard if not impossible without this step. The iOS app can be built in the Xcode GUI and also built from the command line.
This change is