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?
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.
JosephOn Wed, Jan 07, 2015 at 05:44:51PM +0000, fagiano wrote:
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?
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.
apple metal is not dead!On Wed, Jan 7, 2015 at 9:44 AM, fagiano wrote:
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?
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
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.
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:
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?
(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:
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:
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?
I?ve just started to add support for this myself. Right now my (very unfinished) implementation looks something like this:
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.
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.
With my other changes1 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.)
(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:
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.
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 <@Alex_Szpakowski> wrote:
With my other changes1 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.)
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 What do you plan to add other than context creation? I cannot think of anything else.
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 idlingOn Fri, Jan 9, 2015 at 12:44 PM, Alex Szpakowski wrote:
With my other changes1 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.)
On Jan 9, 2015, at 3:11 PM, fagiano wrote:
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.
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.
This might be a silly question, but is there a reason the propoesd Metal function is called SDL_iPhoneCreateMetalContext and not SDL_iOSCreateMetalContext?
| Mike Kasprzak | Sykhronics Entertainment | Blog | Twitter | Ludum Dare |
). 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.