The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

Hi all,
I'm recently investingating Apple Metal and I'd like to write my app using SDL. I was wondering is there any work being done to add Metal support?
If this is not the case, I'm ok to doing it myself, I'm an experienced game developer(16 years xp) however I'm new to SDL and It would be great if someone could point me in the right direction.
All I need is to create a window, initialize Metal and get a device. I don't need SDL rendering.
I was looking into the UIKit/OpenGLES stuff, it seems straight forward enough.
What would be the "correct" way to have OpenGL ES and Metal living side by side?(either one or the other active at once though a flag).
As I see, opengl is suffed deep in all the SDL_video code, maybe I could pretend that my "Metal UIKit View" is a GL View and just implement all the GL functions (like UIKit_GL_CreateContext etc...) but with a metal backend. Am I crazy? whould this break something(assuming I don't try to use the SDL Renderer)? any better alternatives?

thank you for your time

ciao
Alberto

So, I managed to add a rough Metal support(no pun intended ). I implemented a new video driver called "metal" and I initialize it with SDL_VideoInit("metal"). Then I implemented all the GL_CreateContext etc... but using metal so that SDL_GL_Context* is actually a pointer to a UIKit view that is backed by Metal instead of OpenGL ES. This feels quite wrong, that's why I was asking if there would be a better approach. Other than that, the only mismatch that I found is that I need to call a method on the UIView to get a "Drawable"(aka metal framebuffer) each frame. For now I'm sending an Objective-C message to the fake SDL_GL_Context*(that happens to be the UIKit view). I guess to be more SDL like I should add something like SDL_iPhoneGetDrawable() and SDL_iPhoneReleaseDrawable() or similar.
After this is a bit more polished I think adding an SDL Renderer implementation should be quite painless, metal appears to be quite easy to use.

ciao
Alberto

Nobody's doing it yet AFAIK, so you're welcome to!

Obviously you're going to be looking in src/video. The skeleton in
src/video/dummy would tell you what you need to do to make it work,
however you might want to piggyback it off of what you'll find in
src/video/uikit. In fact, the way you get Direct3D in windows is to
call SDL_CreateWindow without asking for OpenGL of any kind. SDL
gives you a window, and from there it's up to you to figure out what
to put in it and how. Basically, get the window handle from SDL and
go to town.

You might get Metal done the same way if you've no desire to support
the SDL renderer. Not played with it since I haven't really tried
iOS development. I think my iPad (Air) supports Metal, so I suppose
I could test the code using it at least if I ever sort out a
toolchain I'm happy with. I am set up for proper codesigning and
all, but I hate IDEs.

Joseph

On Wed, Jan 07, 2015 at 05:44:51PM +0000, fagiano wrote:


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

this is the most epic thread name ever!

bring back 80's apple metal!

apple metal is not dead!



On Wed, Jan 7, 2015 at 9:44 AM, fagiano wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2015-01-07 18:44 GMT+01:00 fagiano:


Getting the native window SDL created behind the scenes is very simple, take a look at
https://wiki.libsdl.org/SDL_GetWindowWMInfo and that struct definition it fills. I believe
you don't even need it to create the Metal device itself as that is queried by some
argument-less "giveMeTheDefaultDevice()" function.


As for whether any GLES code in SDL might interfere with Metal, I don't know. Why don't
you experiment with it and report back? =P

Generally you shouldn't touch any functions prefixed with GL_ because those are strictly

tied to OpenGL and not needed for SDL / window initialization.

Craig Federighi agrees: http://i.imgur.com/oWfukhT.jpg

(It seems my mailing list posts still aren’t showing up in the SDL forums in a timely manner; I sent a reply to this thread half an hour ago...)

On Jan 8, 2015, at 4:42 PM, Neil White wrote:


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I’ve just started to add support for this myself. Right now my (very unfinished) implementation looks something like this:


Two new iOS-specific public functions are added (declared in SDL_system.h):


CAMetalLayer *SDL_iPhoneCreateMetalContext(SDL_Window *window);
void SDL_iPhoneDeleteMetalContext(CAMetalLayer *layer);


CreateMetalContext will internally create a new metal view (subclassed from SDL_uikitview) and attach it to the window / view controller. The view’s CAMetalLayer is returned by the function, which lets you access and change anything Metal-specific you’ll need. When the view is created it also creates a new MTLDevice and attaches it to the CAMetalLayer.


DeleteMetalContext removes the view from the window it was attached to and removes the reference SDL had to it.


The functions will do nothing in iOS 7 and below, and in the iOS Simulator (since the Simulator doesn’t support Metal.)

On Jan 7, 2015, at 1:44 PM, fagiano wrote:

This sounds much cleaner and it's the one I'd go with honestly.

Joseph

On Thu, Jan 08, 2015 at 08:13:24PM -0400, Alex Szpakowski wrote:


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Cool! , Indeed this seems like a cleaner way than screwing with the OpenGL initialization. I also subclassed SDL_uikitview but I did the instantiation as fake gl context. I think you way is the way to go. At the moment I started it didn't occur to me that all I needed from the view was CAMetalLayer, should be much less code. What do you plan to add other than context creation? I cannot think of anything else.

thank you for your input

ciao
Alberto

Another question Alex, how do you deal with contentsScale? I was looking at my "view" code, and I see that in case of a view resize the drawable has to be set to windowsize * contentsScale. however contentsScale is only accessible from the view. Is there a way to get the scaled size from SDL? The SDL_window size seems to be in pixels not points.

Alberto

With my other changes[1] to SDL for iOS (which will be merged in soon hopefully), the contentScaleFactor of a SDL view is the native scale of the screen if the SDL_WINDOW_ALLOW_HIGHDPI flag is used when creating the window, otherwise it’s 1. You can get the ‘drawable size’ of an OpenGL context with SDL_GL_GetDrawableSize, and you can get the size of Metal drawables with the ‘drawableSize’ property of the CAMetalLayer. The new behaviour matches SDL’s current behaviour in OS X.


In either case, the drawable size is updated by the view's code when the view is resized (e.g. in my metal view code, I update the CAMetalLayer’s drawableSize property in layoutSubviews.)


[1]: https://bugzilla.libsdl.org/show_bug.cgi?id=2798
(I also have some other fixes/updates for iOS that aren’t complete yet, but will be included in an updated version of the above changes.)

On Jan 9, 2015, at 3:11 PM, fagiano wrote:

I think context creation and destruction should be enough, but if someone suggests another useful function I’ll definitely add it.


I made a quick test app that works well: http://hastebin.com/suxikemaxo.m

On Jan 9, 2015, at 2:44 PM, fagiano wrote:

any women with large brasts and a mac bored at the library waiting for
email a/s/l

I recommend http://www.kuvaton.com for idling

On Fri, Jan 9, 2015 at 12:44 PM, Alex Szpakowski wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

The window size is always in points (rather than pixels) with my changes – which also matches SDL’s current OS X behaviour. So you can get the size in points with SDL_GetWindowSize, and the size in pixels (assuming you’ve created the window with the SDL_WINDOW_ALLOW_HIGHDPI flag) with SDL_GetRendererOutputSize if you use SDL_Render, SDL_GL_GetDrawableSize if you use OpenGL, or CAMetalLayer.drawableSize if you use Metal.

On Jan 9, 2015, at 4:44 PM, Alex Szpakowski wrote:

cool thanks, it sounds great

Alberto

I don't know much about Metal, so this might be a stupid question: can
the user create their own Metal context with the information that SDL
provides in SDL_SysWMinfo?

If it's just going to be...

SDL_SysWMinfo wminfo;
SDL_GetWindowWMInfo(window, &wminfo);
CAMetalLayer *l = [[CAMetalLayer alloc] init:wminfo.uikit.window];

...then we probably shouldn't add new APIs for it.

(A Metal backend for SDL's render APIs is a totally different thing, in
any case.)

--ryan.


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

A note for anyone attempting this at home: SDL’s current iOS code doesn’t create a view controller or a view until SDL_GL_CreateContext is called, but I’m finishing up a patch that will make all SDL windows have a view controller and a view (among a lot of other changes), so my statement only really applies if/when that patch is applied.

On Jan 12, 2015, at 1:24 PM, Alex Szpakowski wrote:


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Ah, I had forgot about that. Yes, that should work – you could add the CAMetalLayer as a sublayer to the uiwindow’s root viewcontroller’s view’s layer, or create a custom UIView subclass and add that as a subview to the view.

It’s only a bit more work than calling iPhoneCreateMetalContext (assuming you know enough about UIKit to properly add the layer.) You’d also have to add some code to update the drawable size when appropriate, but you’re right, it doesn’t seem worth it to add a new SDL API when it can be done fairly simply without it.

On Jan 12, 2015, at 1:13 PM, Ryan C. Gordon wrote:


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

This might be a silly question, but is there a reason the propoesd Metal function is called SDL_iPhoneCreateMetalContext and not SDL_iOSCreateMetalContext?

I was being consistent with the other[1] iOS-specific SDL functions, which have ‘iPhone’ prefixes rather than ‘iOS’ (presumably because at least some of the iOS backend of SDL was developed when iOS was still called iPhone OS.) I would have preferred to prefix them with iOS, but I value being consistent more.


In any case the functions won’t be added, since it’s relatively simple to create a CAMetalLayer without them.


[1]: https://hg.libsdl.org/SDL/file/a4b031e28de8/include/SDL_system.h#l73

On Jan 16, 2015, at 5:22 PM, PoV wrote:

Here’s a simple example: https://gist.github.com/slime73/12284a8299be857d2581

On Jan 12, 2015, at 1:24 PM, Alex Szpakowski wrote:


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

This is one place where I think we can actually safely break the ABI to rename them. SDL is never going to be installed system-wide on an iPhone per Apple's sandboxing security model. (Jailbreaks theoretically could but AFAIK don't.)


Even if we had to provide both symbol names by default, we could safely follow Apple's example of warning users if they're using the old name to change it.

JosephSent via mobile


On Jan 16, 2015, at 18:12, Alex Szpakowski wrote:

Developers can build and run dynamic (and shared, to a limited degree) frameworks on iOS 8+, although SDL isn’t set up to build as a dynamic framework for iOS right now.

On Jan 20, 2015, at 6:43 AM, T. Joseph Carter wrote:


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

So it's now or never?
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Now or tomorrow or for SDL 2.1... depending on what Ryan and Sam have to say.

One option is to have #defines for either the new/proposed SDL_iOS* names or the old/current SDL_iPhone names which point to the actual function names, like how SDL_mutexP / SDL_LockMutex and SDL_mutexV / SDL_UnlockMutex are right now.

On Jan 20, 2015, at 7:23 PM, Jared Maddox wrote:


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org