Hey folks,
I have been thinking about porting my tech stack (engine + game prototype) to Apple products for some time now. I have done some Mac development in the past, small scale Cocoa desktop development 10 years ago or so. I realize I have fallen out of the Apple development loop completely and don't really know what's what anymore. So I ask you for pointers and tips on how to proceed.
Some background:
- My game is a classical Win32 app linking to my main engine library, which is a DLL. The engine can then load any number of plugin DLLs at runtime. Eg. the rendering backends are loaded as plugins. If you know how OGRE loads render systems you get the idea, as that was what inspired me back in the day.
- The current version of the engine has rendering backends for DX11, DX12 and Vulkan, and the abstraction layer is written with the modern APIs in mind, ie. it exposes command queues, command buffers, PSOs, fences etc. Because of this I imagine I should target Metal rather than try to bolt an OpenGL backend onto it for the Apple platforms.
My first order of business would be to get a simple test app (eg. a spinning cube) running on an iPad Air 2. I have a few questions on how to get started:
1. What kind of projects do I want to set up in XCode? What should the actual game be? Xcode offers me something called a "Game". Is that the right one? Or perhaps "Single view app"? Keep in mind that the game would probably not be the thing that instantiates the window. In my windows builds the game contains mostly game-specific code. The engine library contains the code for loading a renderer backend DLL which then sets up the actual window (plain Win32 window for D3D-backends and a GLFW window for Vulkan). Can I do the same on iOS? Or does the game itself have to create the window on iOS?
2. What about the engine library and the plugin libraries? What kinds of projects do I create for them? XCode offers something called a Cocoa Touch Library, but that sounds like it is related to the touch UI somehow.
3. On windows the game runs in a typical main loop, something like:
void main()
{
startup();
while(running)
{
update();
render();
}
shutdown();
}Can I use the same kind of structure on iOS with a Metal backend? Most Metal tutorials I see use some kind of view that has a draw callback that it fires when it is time to draw things. That's fine as well if that is how the OS wants me to structure the game, but that would require some changes to how the game is set up. If that's the case, where do I put all of the non-rendering code, ie. the world update etc. Is there a separate place for that or do I put all of the update in the draw callback?
4. Should I be using something like SDL for this? I did some googling and it seems people have made Metal work with SDL but it is all highly WIP or unofficial. SDL seems to offer the plain old update/render loop structure I mentioned above, even on iOS, but does that work well with Metal? Or is it better to let the OS call into your code for updating/rendering?
Thanks!
