OpenGL is about two decades of amalgamations and mistakes that needed to be cut out of the working spec. And as a result we have more low-level APIs that are now vendor specific, such as Metal, AMD's Mantle, and so forth...
The downside is we're now at risk of losing an open standard API. OpenGL is bad, and yes, it needs to be retired. But without an mature alternative development costs will only grow.
All of this reeks of the worst kind of anti-competitive behavior and its time for an investigation.
> I don't think you actually know what anti-competitive means.
This is not a good Hacker News comment because it puts another user down and because it doesn't add information. It would be much better without the first bit and if it taught us something about what "anti-competitive" means.
the market hungers to return to a programming paradigm in which the developer can interact much more DIRECTLY with the hardware without a bloated CPU bound OS or graphics API in the way.
Yeah, because all of us really want to go even more backwards in terms of having to deal with the BARE METAL (read: weird fucking behavior) of all of these cards. The current situation with OpenGL is far from ideal, but it's a damned sight better than having to rewrite my code all the time every time for each new device that comes out.
The last chunk of the article talks about the magical ~physics~ that this sort of thing will enable, because real-time raytracing is the the future right? Right? Guise?
If Apple does indeed end up ditching OpenGL (not that they were doing a great job of keeping up with the core API until recently, though they did keep new extensions rolling in steadily), it'd be more proof of them being shitty to engineers and the rest of the development community as a whole.
That's probably why Apple didn't announce Metal for the desktop.
With tight vertical integration with the hardware, and no contention for multiple apps/windows drawing to the screen, the iOS platform is ideal for this.
To be fair, the Metal API is a lot more straightforward then OpenGL, and OpenGL is far from being "write once run everywhere". Each OpenGL platform, GPU and driver comes with its own set of quirks and problems. I do not think that vendor-specific APIs are the right way, but the current OpenGL situation isn't that much different. I would have hoped that Apple shows some real progress on their OpenGL implementations instead of writing their own API though.
From a company that funded Khronos for OpenGL ES and shared canvas/webkit with the world, this would be the wrong direction. WebGL success is largely hooked to OpenGL and its use on mobile as OGLES and WebGL are based on the same base spec. The OpenGL battle was just won with mobile, why replace that?
“All warfare is based on deception. Hence, when able to attack, we must seem unable; when using our forces, we must seem inactive; when we are near, we must make the enemy believe we are far away; when far away, we must make him believe we are near.”
Is this particular case, make everybody compromises performance by adapting themselves to OpenGL while we prepare an almost-bare-metal thing?
The key (and there's probably a Sun Tzu quote about it as well) is getting your competition to where they want to be ... in a way that entangles them there. OpenGL is a respectable place to be, and making it an industry standard & norm ensures everyone can achieve their goals by leveraging the work of others; there's nothing wrong with a solid grounding in OpenGL. The trick, of course, is recognizing that there is always a better position, and preparing to move there while helping everyone else get to a nice comfortable position below it.
Agreed. I've been excited at the notion that OpenGL was becoming the de-facto low level graphics API (if you want any multi-platform compatibility), and then Apple throws this new thing out to re-fragment the market.
Adopting Metal for reasons of extra performance is one thing. Completely eliminating OpenGL ES support from iOS has no excuse other than shutting off Android, so that would be a pretty nasty move from them. I hope they don't do it. Forget about Android users - it's iOS developers that should be crying foul if Apple intends to do that, as it will force them to live in an iOS-only world whether they like it or not.
"as it will force them to leave in an iOS-only world whether they like it or not."
I think you meant "live", but you could get leave to work in there as well. It would certainly take a lot to convince me to develop something for the iOS ... gated community.
Emphasis on the word "chance". You could spend quite a bit of effort developing an app only to find out that Apple won't approve it, or perhaps requires unacceptable changes.
Hence my emphasis on "gated community". Some people like the trade-offs in this business model (earning money does have its attractions :-), I personally don't.
Who said anything about completely eliminating OpenGL ES? SceneKit writes to OpenGL, OpenGL views are pervasive, WebGL is turned on in Safari, CALayers are OpenGL backed. Metal just lets you tweak the render pipeline.
I'm actually surprised (after reading his bio) by this article. Did I completely miss the point of Metal? It sounded like more similar to low-level console platform APIs than to OpenGL or DirectX.
Which, realistically, is what Apple needs. The iOS platform is becoming one of the de-facto big players in the portable console market. Console-level APIs are a logical extension.
Insert speculation about Apple TV as Wii competitor here.
Can you elaborate about Apple becoming one of the big players in the portable console market?
I don't really follow Apple so maybe you're referring to their other offerings and some sort of integration but Apple has never seemed to understand "gaming."
iOS becomes a pretty big gaming platform currently. This years Apple Design Award winners have a pretty decent game percentage: https://developer.apple.com/design/awards/
What isn't Apple understanding? Do they need to make a dedicated gaming device for them to be considered to "understand" the gaming market?
The iPod Touch outsells the PSP/PSVita, which is the second-place of the dedicated portable gaming consoles. Add in the iPhones, and you're looking at an install base as big as Nintendo's DS/3DS family.
It's quite simple really, Apple kind of accidentally became one of the biggest players in gaming.
Not everyone has a DS, not everyone has a Vita, but nearly everyone has a smartphone. Smartphones are the one device you always have on you, and it is by far the mobile device that consumes the most of your time.
This makes Android and iOS huge mobile gaming players, even if they didn't set out to do so. Gaming on smartphones and tablets has become a much larger thing than what Apple and Google ever suspected. How many hours do you figure people game on their Androids and iPhones every day, vs. "real" mobile gaming devices like the DS or the PS Vita?
Easy low-level OpenGL access paved the way, somewhat accidentally, and Apple has been shrewd in keeping middleware developers well-supported, and now they're working on a bunch of first-party libraries that lower the barrier to entry for game devs. And now, they're working on their own low-level hardware access.
They just want to sell their web services and collect data.
Android still lacks the comfort of iOS and WP 8.x for game development on the official SDK and the NDK is treated as a undesirable cousin that appeared unannounced.
>Insert speculation about Apple TV as Wii competitor here.
I thought the Plants vs. Zombies demo already looked better than the Wii U. If Apple puts an A8 in the next AppleTV and keeps it under $200, it would be a very appealing alternative to a $400 xbox.
Apple selling a game controller still seems like a weird prospect, though.
I think iDevices are natural controllers, with 3rd parties making dedicated hardware as the market grows beyond casual games.
It'll start with stuff like shared family games (board on the TV, your secret deck in your hand on your own iDevice), with more hardcore but less controller-dependent games like racers following, then twitchy shooter stuff requiring proper gamepads coming last of all.
I'd think the Wii1 provides the best model here - a really accurate and solid pointing-device controller that turns sideways into a gamepad, combined with the minimal media nav buttons. There's your perfect console controller / media device hybrid interface.
Of course, the problem is that everybody also wants to stick a keyboard onto the darned thing, and that's where the slickness goes away.
I don't necessarily agree. I think a big part of Metal is to address the limited resource space (such as RAM) that game makers currently face. If you have an iPhone 5S, you're usually fine -- but iOS 7 (and I'm sure iOS 8) takes up a lot more overhead than previous versions. In addition to paving the way for better experiences and better manipulation of the GPU, I also think this about providing game makers a way to better take advantage of the full iOS hardware stack.
That isn't to say there might not be another reason for them to forgo the Mac (whether it's waiting for ARM support or otherwise) -- or that Apple probably isn't actively looking at if/when it can bring an A-whatever to power a Mac, but that still seems a long way off.
I might be way off here but the idea that metal et al have anything to do with enabling ray tracing seems absurd. The cards still are hardware optimized for triangle rasterization, the api doesn't change that.
What I find fascinating, in general, is Apple's rise as a gaming powerhouse.
Take SpriteKit. It didn't exist until it was announced at WWDC 2013. Up until that point, the functionality offered by it was largely either hand-rolled by the developer, or achieved via framework (e.g., Cocos2D). I think Apple realized that they could capture more mind-share and confidence if they offered their own first-party framework offering.
Fast-forward a year later, and we have an enhanced SpriteKit (i.e., light sources, field forces, per-pixel physics, inverse kinematics), and of course the newly-announced SceneKit (3D scene rendering for casual games), Swift and Metal... all within a year!
With regard to Metal, Tim Sweeney had this to say after the Zen Garden app demo:
"There are thousands of objects being rendered here in a scene that we couldn't have dreamed of building, prior to Metal delivering a 10 fold increase in rendering efficiency. To have this level of graphics capability on iPhone and on iPad now is a stunning breakthrough. We're proud to have been a part of it. Of course, we'd love to share this with you, so as soon as iOS 8 is available, we'll be making Zen Garden available in the App Store for free."
Swift is hardly VB. Swift is a modern functional language competitive with Java. It's far more complex than Objective-C. The threading model in Swift utilizes GCD and Closures versus the "perform selector in background" semantics of ObjC.
A PC vendor-specific high-level language? VB is the obvious comparison. Sure Swift is a better language, but it fills the same niche as VB - a platform has a difficult API and they want a more productive language, so they make something very high level using popular practices of the day, custom made to map tightly to their platform.
It's just the popular practices in that niche in VB's day were things like Delphi and Tcl/TK, whereas Swift comes out in the day of Java/C#/Golang.
Objective-C supports GCD just fine. In fact, I make use of that far more often than "perform selector..." and I'd say I'm probably not in the minority on this.
No. There is a huge difference in that Apple has strong competitors (Google, Microsoft, Amazon), while Microsoft didn't at the time.
Since Android now holds the vast majority of the mobile market in many regions, game engines have to support multiple APIs and cannot just switch to Metal. While around ~2000 pretty much everyone was only doing Direct X.
Obviously, this is only good for users. There wouldn't be much incentive for Apple to come with Metal if they had 97% of the market. And the ball is now in Google's court to outdo Apple.
Keep in mind, that Microsoft, Apple, Samsung, nVidia, AMD, Intel, will keep having support for OpenGL (ES or other versions). And it is still the simplest way to write code for multiple platforms at the same time.
Of course, each of them tries to "bind" you by offering some extra speed or features and make it hard for you to publish to other platforms. But at the end, I believe that OpenGL (ES ...) is the only thing that will survive :)
It is very much like client-side web apps. Adobe wants you to use Flash, so you would have to buy Adobe Flash. Microsoft wants you to use Silverlight, so you would have to buy Visual Studio. Oracle wants you to use Java, etc ... But at the end, Javascript remains. It is not prefect for everyone, but it is "open" and free to implement, free to develop without paying anything to anybody.
Provocative title, but probably overstated. SceneKit uses OpenGL directly with shaders and deferred rendering. Metal seems likely to become more mainstream as engine developers adopt the tech, but there are going to be lots of developers who are overwhelmed with writing glsl shaders, let alone significantly altering the render pipeline.
This is tragic news. Instead of working on an open cross-platform solution, they create their own proprietary crap. This must die. Vote with your money.
59 comments
[ 1.3 ms ] story [ 136 ms ] threadThe downside is we're now at risk of losing an open standard API. OpenGL is bad, and yes, it needs to be retired. But without an mature alternative development costs will only grow.
All of this reeks of the worst kind of anti-competitive behavior and its time for an investigation.
This is not a good Hacker News comment because it puts another user down and because it doesn't add information. It would be much better without the first bit and if it taught us something about what "anti-competitive" means.
Yeah, because all of us really want to go even more backwards in terms of having to deal with the BARE METAL (read: weird fucking behavior) of all of these cards. The current situation with OpenGL is far from ideal, but it's a damned sight better than having to rewrite my code all the time every time for each new device that comes out.
The last chunk of the article talks about the magical ~physics~ that this sort of thing will enable, because real-time raytracing is the the future right? Right? Guise?
If Apple does indeed end up ditching OpenGL (not that they were doing a great job of keeping up with the core API until recently, though they did keep new extensions rolling in steadily), it'd be more proof of them being shitty to engineers and the rest of the development community as a whole.
With tight vertical integration with the hardware, and no contention for multiple apps/windows drawing to the screen, the iOS platform is ideal for this.
“All warfare is based on deception. Hence, when able to attack, we must seem unable; when using our forces, we must seem inactive; when we are near, we must make the enemy believe we are far away; when far away, we must make him believe we are near.”
Is this particular case, make everybody compromises performance by adapting themselves to OpenGL while we prepare an almost-bare-metal thing?
Is this really much different than programming for a console?
For Apple, pretty much all of them. SceneKit, SpriteKit, HealthKit, CloudKit, … The list is long.
I think you meant "live", but you could get leave to work in there as well. It would certainly take a lot to convince me to develop something for the iOS ... gated community.
Like the chance to make decent money? Gotta give Apple credit, their users are willing to shell out cash.
Hence my emphasis on "gated community". Some people like the trade-offs in this business model (earning money does have its attractions :-), I personally don't.
Insert speculation about Apple TV as Wii competitor here.
I don't really follow Apple so maybe you're referring to their other offerings and some sort of integration but Apple has never seemed to understand "gaming."
The iPod Touch outsells the PSP/PSVita, which is the second-place of the dedicated portable gaming consoles. Add in the iPhones, and you're looking at an install base as big as Nintendo's DS/3DS family.
Not everyone has a DS, not everyone has a Vita, but nearly everyone has a smartphone. Smartphones are the one device you always have on you, and it is by far the mobile device that consumes the most of your time.
This makes Android and iOS huge mobile gaming players, even if they didn't set out to do so. Gaming on smartphones and tablets has become a much larger thing than what Apple and Google ever suspected. How many hours do you figure people game on their Androids and iPhones every day, vs. "real" mobile gaming devices like the DS or the PS Vita?
Easy low-level OpenGL access paved the way, somewhat accidentally, and Apple has been shrewd in keeping middleware developers well-supported, and now they're working on a bunch of first-party libraries that lower the barrier to entry for game devs. And now, they're working on their own low-level hardware access.
Android still lacks the comfort of iOS and WP 8.x for game development on the official SDK and the NDK is treated as a undesirable cousin that appeared unannounced.
I thought the Plants vs. Zombies demo already looked better than the Wii U. If Apple puts an A8 in the next AppleTV and keeps it under $200, it would be a very appealing alternative to a $400 xbox.
Apple selling a game controller still seems like a weird prospect, though.
Rather convenient that iOS 7 included a game controller API and Apple hardware certification for Bluetooth controllers.
(Of course, they are expensive and poorly reviewed, but the groundwork is there.)
I think iDevices are natural controllers, with 3rd parties making dedicated hardware as the market grows beyond casual games.
It'll start with stuff like shared family games (board on the TV, your secret deck in your hand on your own iDevice), with more hardcore but less controller-dependent games like racers following, then twitchy shooter stuff requiring proper gamepads coming last of all.
Of course, the problem is that everybody also wants to stick a keyboard onto the darned thing, and that's where the slickness goes away.
Why not? Ever heard of Pippin?
http://www.anandtech.com/show/8116/some-thoughts-on-apples-m...
https://ilikecode.wordpress.com/2014/06/03/what-impact-ios-m...
This is the reason Metal isn't introduced on Mac. They're waiting. Waiting until their Macs run on ARM.
I'm not saying it'll happen tomorrow. It may take a few years.
Is Apple returning to make its own chips trend?
That isn't to say there might not be another reason for them to forgo the Mac (whether it's waiting for ARM support or otherwise) -- or that Apple probably isn't actively looking at if/when it can bring an A-whatever to power a Mac, but that still seems a long way off.
Take SpriteKit. It didn't exist until it was announced at WWDC 2013. Up until that point, the functionality offered by it was largely either hand-rolled by the developer, or achieved via framework (e.g., Cocos2D). I think Apple realized that they could capture more mind-share and confidence if they offered their own first-party framework offering.
Fast-forward a year later, and we have an enhanced SpriteKit (i.e., light sources, field forces, per-pixel physics, inverse kinematics), and of course the newly-announced SceneKit (3D scene rendering for casual games), Swift and Metal... all within a year!
With regard to Metal, Tim Sweeney had this to say after the Zen Garden app demo:
"There are thousands of objects being rendered here in a scene that we couldn't have dreamed of building, prior to Metal delivering a 10 fold increase in rendering efficiency. To have this level of graphics capability on iPhone and on iPad now is a stunning breakthrough. We're proud to have been a part of it. Of course, we'd love to share this with you, so as soon as iOS 8 is available, we'll be making Zen Garden available in the App Store for free."
Not for junior engineers.
It's just the popular practices in that niche in VB's day were things like Delphi and Tcl/TK, whereas Swift comes out in the day of Java/C#/Golang.
Since Android now holds the vast majority of the mobile market in many regions, game engines have to support multiple APIs and cannot just switch to Metal. While around ~2000 pretty much everyone was only doing Direct X.
Obviously, this is only good for users. There wouldn't be much incentive for Apple to come with Metal if they had 97% of the market. And the ball is now in Google's court to outdo Apple.
Agree, let me just grab my quantum physics engine and spin up my realtime ray-tracer and build a next hit game in a month.
Of course, each of them tries to "bind" you by offering some extra speed or features and make it hard for you to publish to other platforms. But at the end, I believe that OpenGL (ES ...) is the only thing that will survive :)
It is very much like client-side web apps. Adobe wants you to use Flash, so you would have to buy Adobe Flash. Microsoft wants you to use Silverlight, so you would have to buy Visual Studio. Oracle wants you to use Java, etc ... But at the end, Javascript remains. It is not prefect for everyone, but it is "open" and free to implement, free to develop without paying anything to anybody.