Apples rendering API:
http://www.ubergizmo.com/2014/06/apple-metal-graphics-api-to-boost-ios-game-performance/
EDIT: It was not intended to to post this topic on "Coding Horror" I've missclicked the 'GDNet Longue'
Apples rendering API:
http://www.ubergizmo.com/2014/06/apple-metal-graphics-api-to-boost-ios-game-performance/
EDIT: It was not intended to to post this topic on "Coding Horror" I've missclicked the 'GDNet Longue'
I would hope that this might finally convince Khronos of the need for a more drastic re-imagining of OpenGL. Hell, Introduce a new open, low-level, cross-platform 3D API if they have to, but they need away to break away from the legacy and move in a different direction than what they are now. Their latest proposed enhancements gain performance but lock you into certain patterns that you or your program might not favor, and still places a lot of burden on drivers.
Everyone else is ready to move to the automobile, and meanwhile Khronos intends to build a better horse.
Equally interesting is what this might mean for Android -- GLes (or Unity) has been the traditional cross-platform layer between iOS and Android Graphics. Android mostly lacks the high-end mobile gaming market already, but when Metal becomes the API of choice for AAA-style mobile games, and it looks to be a stone's throw from D3D12, it might boil down to iOS and Windows Phone serving up high-end mobile games.
I for one am very happy to see Metal -- much more so than I care about Mantle or D3D 12. The GL ES API is a ridiculous amount of overhead.
People keep saying it's Apple's version of Mantle/D3D12, but to me it looks a lot more like D3D11. No manual memory/sync management (or am I just missing that somewhere?), no bindless textures, etc. So far the only solid step above D3D11 that I've noticed is that there's actual API's for managing command buffer submission, and they allow for free-threaded command buffer creation. The fact that they don't let you re-use command buffers across frames is a bit of a bummer, as are the separate command buffers for rendering/compute/copy. However I would suspect that this is a reflection of how the underlying hardware works on their platform. Probably the biggest issue is the apparent lack of Draw/DispatchIndirect functionality. Compute is a whole lot less useful without that.
Still, it's cool to see that Apple cares enough to give developers a way out of the nightmare that is OpenGL ES. Too bad they had to make it an Objective-C API.
Too bad they had to make it an Objective-C API.
Would it be better if it used their new Swift (supposedly Obj-C without the C) language? Because the only things better than Objective-C is a new language based on Objective-C.
I can't imagine that OpenGL will just go away. It is used by so many other things besides games. I figured with all the effort that Valve has put into Linux and OpenGL that it will force them to be relevant.
My big question is what to start learning now to stay relevant? Are there books on this new way of doing graphics, or is it still too "bleeding edge"?