"With Metal, Apple hopes to replace the industry-standard 3D-graphics API (application programming interface), called OpenGL, with its own development API that sits between the game software and Apple's A7 mobile chip."

Comments section:

Quote

So rather than implementing a decent version of OpenGL on their phone, they write their own library and try to further tie devs to their platform. Proprietary APIs, now that's innovation!

If they actually ditch OGL completely, then that's going to suck, at least for us indies. If that happens, I'm interested in seeing how it affects the current iOS gaming ecosystem.

This is dumb, the conference was basically explaining basics of graphics to newbs. Just replacing "OpenGL" with "Metal". I can't wait for them to come out with a new shaders language, and some kind of weird rasterizer and people to call it "innovation".

Good ole' Apple, trying to cram bullshit down our throats and call it "cool, unique and innovative" when it's actually just a rehash of systems we already have, that work just as good (sometimes better) than what they are proposing.

If Apple ditched OpenGL for their propitiatory garbage, all they're going to do is alienate their devices making it even harder for developers to make Android/iOS apps, and since Android is gaining huge ground right now I could see some devs dropping iOS entirely in favor of the easier to develop (and port to PC), android.

But in all honesty, Apple is probably just going to support both, I hope. The real question is how good will OGL support be now. Knowing apple's slimy ways, I could see them half-ass supporting OGL, trying to push their API on us hoping to get people to become iOS exclusive devs. Either way, I feel bad for the multiplatform mobile devs out there.

Just imagine if they push "metal" as the exclusive API for their computers. I wonder how that will affect our "Compile once run anywhere" java we're used to when using OGL libraries. We'd all have to rewrite Metal-specific versions of our java apps. If that happens, I won't bother supporting the Apple product line. There would be no point in doing all that extra work just for a fraction of the gamer market.

In theory, we would be fine if I am understanding how the JVM works, but you never know with Apple. They love to purposely limit their system to force people in line.

This is such bullshit... They are really going to try and do that? I highly doubt it will improve their position, because they'll just lose many of the most experienced developers out there. Have fun dealing with all the newbie games Apple.

There was no mention that they will ditch openGL. It's just low level api for people who write graphics hungry games or professional game engines. If you are crying it's not meant for you. I see this reaction quite hilarious.

Right, it's only speculation at this point about non-continued OGL support, but if it's done away with (and I'm not sure how they can do that, business-wise) then libGDX (our relative case) loses a deployment target for iOS8+.

I had the same thought with, "weeeell, we still support OGL, but our implementation is kinda shitty and suck it." That could still happen, although it's doubtful.

There was no mention that they will ditch openGL. It's just low level api for people who write graphics hungry games or professional game engines. If you are crying it's not meant for you. I see this reaction quite hilarious.

The issue is not that we are worried about them ditching OpenGL. If they did that then they would lose a significant portion of their developer base, destroy what little gaming market they have, and result lots of major cross-platform software breaking. If they were to ditch OpenGL, they'd have to open up the specifications for Metal or risk a collapse.

The issue is that developers who use Metal will be given an unfair advantage over non-Metal, resulting in people switching to Metal, and therefore resulting in lots of non-portable software.

And I would go as far to say that I would be surprised if Apple didn't give Metal developers an unfair advantage.

Luckily, the majority people who develop software are aware of Apple's bull****, and so the only people who are going to fall for it are the Apple fanboy developers.

Every one in web is crying how openGL is broken/retarded/slow and when somebody is trying to give low level rendering API that potentially has market and actual need its suddenly bad thing? I personally used months for our last iOs game cpu optimizations and huge share of that went for fighting with driver overhead. It would have been so much faster to just use some different rendering API with direct control instead of just guessing fast paths.

Every one in web is crying how openGL is broken/retarded/slow and when somebody is trying to give low level rendering API that potentially has market and actual need its suddenly bad thing? I personally used months for our last iOs game cpu optimizations and huge share of that went for fighting with driver overhead. It would have been so much faster to just use some different rendering API with direct control instead of just guessing fast paths.

While I agree with some of what you said, a closed standard is something that we should stay well away from.

We're only just starting to recover from the damage caused by Microsoft and Direct3D. The last thing we need is a new closed API that reeks of vendor lock-in.

Every one in web is crying how openGL is broken/retarded/slow and when somebody is trying to give low level rendering API that potentially has market and actual need its suddenly bad thing? I personally used months for our last iOs game cpu optimizations and huge share of that went for fighting with driver overhead. It would have been so much faster to just use some different rendering API with direct control instead of just guessing fast paths.

I personally used months for our last iOs game cpu optimizations and huge share of that went for fighting with driver overhead.

I can't speak for mobile, but on desktop the CPU overhead is basically gone thanks to 3 new extensions:

- ARB_buffer_storage: Persistent buffers can be mapped once and used forever, allowing you to build data on all CPU cores and gets rid of stalls of the driver server thread. - ARB_bindless_texture: No need to bind textures anymore. Texture handles can be stored in uniform buffers, texture buffers, etc. - ARB_multi_draw_indirect: Read draw call parameters from a (persistently mapped) buffer and render multiple things at the same time.

These features all give massive improvements in driver overhead since the most common and batch-breaking OpenGL functions can be removed. Even better, since texture handles and draw commands can be uploaded into buffers from any number of threads, we also have huge threading possibilities. All three extensions are supported in the latest Nvidia, AMD and Intel drivers on Windows, EXCEPT ARB_bindless_texture which isn't supported on Intel's cards yet. These three extensions alone should provide Mantle-like performance and almost Mantle-like threading possibilities.

Apple are the height of scum IMO, sure when they first fired it that iPhone it was revolutionary. Now they are just milking the cash cow and doing whatever they can to make sure no one can do the same, like sue any company that tries to do something even remotely similar.

"This code works flawlessly first time and exactly how I wanted it"Said no programmer ever

Apple are the height of scum IMO, sure when they first fired it that iPhone it was revolutionary. Now they are just milking the cash cow and doing whatever they can to make sure no one can do the same, like sue any company that tries to do something even remotely similar.

Maybe you don't understand what those people are trying to achieve. If no one is interested where modern openGL is going then it never will be fixed. There are lot's of problems that could be removed if just someone would care.http://www.joshbarczak.com/blog/?p=154 "OpenGl is broken"

Every one in web is crying how openGL is broken/retarded/slow and when somebody is trying to give low level rendering API that potentially has market and actual need its suddenly bad thing? I personally used months for our last iOs game cpu optimizations and huge share of that went for fighting with driver overhead. It would have been so much faster to just use some different rendering API with direct control instead of just guessing fast paths.

Thats valid, but thats a very specific use-case

How normal 60fps game is spesific use-case? Gameplay needed 60fps with minimal input latency and absolute no stutter and we still wanted modern and clean 3d look. I happened to be only graphics programmer so my job was to deliver that.

It's a rubbish idea. Fixing their OpenGL drivers would have been a more productive use of time, except it's only part of Apple's proprietary lock-in process which they've been maturing over the last decade. Think:

1. App Store. The only place you can buy applications.2. Replacing Obj-C (and, for that matter, C) with Swift. Useless anywhere else*3. Replacing key cross platform APIs with proprietary APIs (Metal) under the guise of "performance" when, in fact, it's not going to be any faster for 99% of the people using it.

Cas

* Swift does have a bunch of awesome features in it though that are sorely missed in Java. Tuples! Options! Default parameters! Although it also looks like only 10% complete half-baked joke compared to the rest of the Java specification.

I've been trying to follow that, but I have almost no idea what they're talking about. o_O I know they're discussing how well ARB_bindless_texture fits Nvidia and AMD hardware, but they're talking about exactly how this is implemented in hardware on different GPUs, which is a bit over my head. >_>

Every console (or embedded device), steam, google play? Money's in software. Even better if you can get a cut of everybody elses. Win!

Counter: Steam is in addition to being able to obtain software from anywhere else. Likewise Google Play - Android can load .apks from anywhere, though it makes it a tiny bit less obvious to users how to do it. Consoles have of course been playing the lock-in game for years and always will.

What annoys me about all the hardware zealots and people complaining about this and that... to us ordinary troops in the field, it doesn't matter. We just want a subset of an API that works well, and generally, that's what we're getting, and using, successfully.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org