The future of non-indie game development seems very much to be going towards hardware: Mantle, Metal, libgnm, DX12. If you're on a console, you can afford to actually develop for the console. If you're not, you don't matter. (Indies don't care, but few people care about them, so that tail wouldn't wag the dog. Nobody cares about Steam Machines, so I don't know why you'd bring them up.)
No. It had OpenGL ES 1.0 with Cg for shaders.
> The PS4 has OpenGL
Since when? Only if a third party company is offering it.
It doesn't change the abject silliness of the sibling thread though.
> It doesn't change the abject silliness of the sibling thread though.
I do boring IT stuff. But once upon a time I had some opportunities in gaming (long long time ago), which I blew up for being more focused on the OSS aspects of the tooling than what really mattered, having a game.
I really learned the hard way, how the different the game development culture is from the FOSS one. Which I should have known given the similarities with the demoscene.
Even though I am not in the industry, I do follow it regularly.
Oh sure. Lock-in mentality is the reason. Never mind that Apple is doing Metal and AMD is doing Mantle because of defined, demonstrable issues with higher-level abstractions, both GLES and DX11 respectively. Certainly never mind that DX12 is shaping up to provide the same sort of low-level primitives as Mantle/libgnm/Metal. No, they're just hissss lock-in hissss. Can't possibly be because, like, it's a better option, can't have that. Like, do you know how many calls you have to make to accomplish stuff in some basic OpenGL extensions? And how much less you can do without the significant amounts of overhead it causes--overhead you can't remove because it's in the spec and now it never goes away?
Did you ever stop to think, for just one second amidst your "there is no reason" absolutism about something it certainly sounds like you don't know much about past laymanship...maybe they're not laymen and maybe they have a good reason for stripping away abstraction? Not even providing their own incompatible abstraction, but just getting rid of it? I mean, Snidely Whiplash wants to make his platform dev-friendly too, but instead of doing that he gives you this bleeding bare-metal API? Come on. Have you stopped to give these guys an ounce of credit?
And complaining about a "release schedule resulting in outdated hardware" fails to comprehend that "outdated hardware" is every nine months. That is a feature, so that normal people don't have to go buy nVidia GTX9581 Platinum Edition cards every two years. Your position frankly beggars belief. The PC gaming treadmill sucks. The mobile treadmill sucks. And you want to make people jump to it on consoles? Do you know a normal person?
Bad comparison. While AMD proposed to Khronos their Mantle as a base for OpenGL-next and in general aim to make it open, Apple didn't do any such thing. Apple does Metal precisely out of lock-in mentality. Any API that will lock developers to one platform is a dead end.
> "release schedule resulting in outdated hardware" fails to comprehend that that is a feature, so normal
Yeah, a "feature" that degrades games' quality because developers are constantly held back by requirements of console ports. It's not a "feature" to stagnate hardware for such long periods of time. Consoles are closed platforms with manufacturers in full control. It has some pluses like more stable expectations, but minuses outweigh them. Open platforms are the future and the locked-in ones will be considering some changes when stronger competition will give them a kick.
If you don't think Apple has invested a shit-ton of money into GLES to make it habitable I just don't think you're living in a world inhabited by the rest of us. Apple has spent tons of man-hours and money dealing with the OpenGL process. But no, Snidely fuckin' Whiplash is over here curling his moustache and hissing "yessss, yesss, everything we do by stripping out layers of abstraction and making things faster for obvious and comprehensible reasons is eeeeeeevil."
They still support GLES. They still participate in the process. But they offer a frankly better solution too, one on top of which you can build an agnostic API that can better leverage each platform's better options than OpenGL.
> It's not a "feature" to stagnate hardware for such long periods of time.
Cool. Get normal people to shell out for a new console--you know, that thing that lives in a home theater center that you buy and stop thinking about--every two years. Don't worry, everybody else will definitely wait for the market to prove you right, they won't be over here cooking on what actually works.
> If you don't think Apple has invested a shit-ton of money into GLES to make it habitable I just don't think you're living in a world inhabited by the rest of us...
they offer a frankly better solution too
So, where is their proposal to make Metal into OpenGL-next? Until it surfaces, Metal will remain a lock-in attempt.
They aren't computers. This is the blinkered view of people way too close to their choice of silicon that ignores what people who actually buy hardware want. Normal people don't want computers. Computers suck and are hard to use. They want predictable, turn-key solutions. I'd point to the smoking ruin that is the commercial HTPC market as evidence that, hey, maybe this actually is a thing that works...but I have this sneaking suspicion you'll just say that's definitely not a true Scotsman, no no no.
> So who said consoles have to be all locked up and controlled by Sony, MS and Co.?
Nobody, so don't put words in my mouth.
> So, where is their proposal to make Metal into OpenGL-next? Until it surfaces, Metal will remain a lock-in attempt.
If you would stop extrapolating general-purpose software to to hardware layers for just a tick, the notion might enter your head that Metal is designed around the behaviors of the guts of the A7. It doesn't make sense to generalize it because the generalization of it into "OpenGL-next" takes away the reason to use it! You can bleat 'till you're blue in the face about how terrible it is that people would trade abstractive consistency for performance, but it's what everybody's done in games--and, when you add enough zeroes to a problem, software in general--forever.
Abstractions inevitably fail. Your ideology can attempt to ignore it. It'll fail, too. And the arrogance that you display in this insistence that people have thought about this much much more than you must be acting dishonestly because they disagree with your ideological bent is simply astounding.
Sony and MS did. "Nobody" now is probably Valve who want to disrupt the sickening locked up consoles scene. Time will tell if they'll succeed.
> It doesn't make sense to generalize it
No, it does make sense to provide a generic cross platform API. We aren't in the dark ages of computing anymore. Forcing developers to use hardware specific code is backwards unless we are talking about drivers and assembly like development.
> Abstractions inevitably fail.
Is that Apple's argument for Metal? Abstractions don't fail. They save tons of effort for developers. Otherwise why don't you propose writing programs in machine code like in the olden days? That for sure can produce the most optimized result in theory.
Do you think game development followed the web off the performance-doesn't-matter cliff and went "welp, we're just going to go write everything in Ruby"? What exactly do you think game development is if not intensely performance-critical low-level software development? Do you somehow think they aren't writing whacks of assembly and adding code paths for specific versions of drivers because of reasons X, Y, and Z?
> Otherwise why don't you propose writing programs in machine code like in the olden days?
You literally must be trolling. What do you think game developers do when they run into hot spots in their code? Bunches of AAA games (and every engine vendor, thanks much) have one or more gurus around who eat and sleep the assembly language for every deployable platform. I know a guy--socially, we're not friends, but we've talked about this--whose entire job is rendering optimization for iOS. He owns a big whack of stiff C where every allocation is carefully considered and which has more than a little assembly in there. Because that's what you do when you need to wring performance out of a system. He digs Metal because it makes him better at his job--at making the hardware optimally do what he very badly needs it to do.
Stop trying to conflate web development on future computers from beyond the moon with game development because what you know does not hold. These games are not being written in Node, they are not being written in environments with garbage collection--hell, a lot of the time they don't even use inheritance in C++ because of the cost and complexity of vtables (this is one of the reasons the standard collection libraries in C++ are a template soup, as it happens). It's not the "olden days," it's today, now. That's why these low-level APIs are coming about: because the abstractions you think don't fail don't cut it.
"Abstractions don't fail" is one of the most unintentionally funny things I've read in a very long time and I can literally think of a dozen places just off the top of my head in my very much non-gamedev job where the abstraction layers other people put in place screwed me hard. Quit while you're very far behind.
Cross platform APIs can be native in C/C++. Ruby or Node have nothing to do with it.
> It's not the "olden days," it's today, now.
Sure, it's today now on consoles which provide low quality generic APIs because no one cared to provide high quality ones. That's not a valid reason to say "fire! we now need machine code to save the gaming industry at large". That's a reason to say that console manufacturers don't care about developers besides locking them into their platforms. Luckily this is going to change. Of course you are free to use low level code still when it's really needed.
> I can literally think of a dozen places just off the top of my head in my very much non-gamedev job
We are talking about gaming. I can think of cases where low level development is needed too. That's irrelevant to the discussion about using cross platform APIs vs using platform locked ones.
(And there's x86 and x64 assembly in UE3. For PCs, right now. But don't let that stop you from telling people how to do their jobs. It's a shame @ShitHNSays got canned.)
All that cheering for Metal is not sincere. Talk to actual developers who are forced to support many APIs because no one cared to make one cross platform work well. The bottom line, we need less of lock-in APIs promoted as the way to develop games.
This is not how the game industry works.
There are studios specialized in porting games for specific platforms.
Usually a studio focus on one specific platform and outsources the remaining platforms to such porting studios.
This is a common practice since the early days.
At one point, Sony was asking developers whether they would be interested in having PSGL conform to the OpenGL ES 2.0 specs (link here). This has unfortunately never happened however, as developers seem to have mostly preferred to go with libGCM as their main graphics API of choice on PS3. This has meant that the development environment has started becoming more libGCM-centric over the years with PSGL eventually becoming a second-class citizen – in fact, new features like 3D stereo mode is not even possible unless you are using libGCM directly.
> There is no valid reason why OpenGL can't be made to perform well on consoles except the lock-in mentality which plagues consoles market.
Game studios culture doesn't care about FOSS.
What matters is making the best game on the platforms the publishers are paying in advance for.
You're taking your ideology and trying to retrofit the world to accomodate it. Doesn't work that way. In the world of what is, rather than the world of what one might like it to be, nobody really cares. Tough.
You are talking about Apple's spin of Metal (which is lock-in ideology). In practice it's easier for developers to use one toolkit instead of using 20 locked-in incompatible APIs.
If developers use ready engines it becomes easier for them, but that burden is shifted to engine developers then. Someone will have to deal with that major mess. There is clear pragmatic benefit in cross platform APIs for gaming, and claiming that it's just ideology is nonsense.
Not when that "one toolkit" is worse.
You are conflating "lock-in" with "optimal suitability for a platform". Hardware matters. Your continual handwaving can't ignore that.
Here it's the case of "worse because it wasn't made better", not because it can't be better. That's my point. So difference in approaches with this subject like between AMD and Apple shows who cares about making it better and who cares about locking developers into their platform.
Right. Of course, the real world works nothing like the world that you have described, but ok, good luck with that.
You don't know what you don't know but it isn't stopping you from talking shit. Stop.
Poor abstractions. I'm not convinced that there can't be a well designed cross platform graphics API that is sufficient for the majority of cases. Prove that it's impossible or stop, because otherwise your claim that you don't advocate lock-in doesn't sound sincere.
The abominable snowman exists. Prove that it doesn't or shut up.
No, I need to get software written that runs well. Now, if my requirement is to run on N different platforms (where N > 1) then I will have to look at OpenGL. If it's not a requirement then I won't waste my time. You're comments reek of ideology and completely lack practicality. You make assumptions about a complex subject which smarter people than you or I have spent years working on and come to different conclusions.
So? It's not a reason not to make one or to claim that since it "failed" everyone needs to run to platform specific APIs. That was the point.
Not just the OpenGL is suffering from this, DirectX has very similar problem up to DX11, the DX12 is out to address this.
There are extensions that allow you to do the same in OpenGL but then what would be a point to bring the entire OpenGL if you are only going to use the extension that is nothing like the OpenGL and does the same the native API already does?
How so? It adds DSA which is just a different way to access global state. The global state is still the cornerstone of the 4.5. The only way it addresses performance issues is through "bindless" extension, which pretty much tosses away the entire OpenGL pipeline and leaves just a draw_indirect_multi call call with everything pushed into shaders. It's too extreme for many developers even it's been available on non-NVidia hardware.
> My point was not to say that OpenGL is perfect as is.
Never mind me then. I only replied to your claim it's not the OpenGL fault it's slow on consoles.
I mean new flush control support.
I guess now they came to a better realization of the situation or now there are more people who actually want to improve things significantly rather than avoid such issues.
Rather it originally was such API. I'm saying, why couldn't they draft a new API from the ground up as one of the previous major versions? It looks like only now they are doing exactly that. So why wait so long? That's what I mean I'm unsure of. Probably some organizational problem or lack of some major pushers for such change in the past.