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”
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.
@theagentd - Might find this interesting: http://fgiesen.wordpress.com/2014/06/01/bindless-chain-letter/
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:
- App Store. The only place you can buy applications.
- Replacing Obj-C (and, for that matter, C) with Swift. Useless anywhere else*
- 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.
Every console (or embedded device), steam, google play? Money’s in software. Even better if you can get a cut of everybody elses. Win!
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. >_>
I’ve only been skimming…see how stuff falls out later probably makes sense (also comparing DX vs GL land)…Another is here: http://www.joshbarczak.com/blog/
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.
Cas
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.
Cas
“Dear JGO: I’m working on a game and everything has been hunky-dorky until recently. I’ve found that adding new features to my game is getting harder and more and more bugs are appearing. What I’m I doing wrong???”
Here’s my game:
And there’s one class file that looks something like this:
public class Game
{
final static int MAX_ENTITY_ARGS = 5;
final static int MAX_ENTITIES = 100000;
static int[] activeEntity = new int[MAX_ENTITY_ARGS];
static int currentError;
static int[] entityX = new int[MAX_ENTITIES];
static int[] entityY = new int[MAX_ENTITIES];
final static int ERROR_SLOT = 0x0123123;
public static int getError()
{
return currentError;
}
public static int getActiveEntity(int slot)
{
if (slot <MAX_ENTITY_ARGS)
return activeEntity[slot];
currentError = ERROR_SLOT;
return -1;
}
public static void setActiveEntity(int entity, int slot)
{
if (slot < MAX_ENTITY_ARGS) {
activeEntity[slot] = entity;
return;
}
currentError = ERROR_SLOT;
}
public static void setActiveEntity0(int entity)
{
activeEntity[0] = entity;
}
public static void setActiveEntity1(int entity)
{
activeEntity[1] = entity;
}
public static boolean isLineOfSight()
{
int e0 = activeEntity[0];
int e1 = activeEntity[1];
int x0 = entityX[e0];
int y0 = entityX[e0];
int x1 = entityX[e1];
int y1 = entityX[e1];
// <snip>
}
public static boolean canEntitySeeEntity(int e0, int e1)
{
setActiveEntity0(e0);
setActiveEntity1(e1);
return isLineOfSight();
}
}
Sure. Because there isn’t another viable option. Life would be alot easier with an API that does what you say and doesn’t suck. We could make the same argument for about anything. We could program huge apps in C and if that was the only option we’d do it. C is great, but it scales like crap.
Well programming to only one platform and then getting a specific lib for just that platform… thats specific.
would be the same deal if there was an android specific graphic lib.
The rest you say is super valid but only targeting one system, almost only one console - well sure in that case you can have a very powerful direct API. The point of opengl is that it works on so many platforms and hardware
Didn’t Apple originally create opengl?
Nope but they were a big supporter of it and they have used it since practically the beginning, In fact at the time when hardware acceleration was a new thing, Apple jumped on it and made their windows hardware accelerated using OpenGL.
Seriously, people. Apple is not going to drop support for OpenGL. Do you know how many games would instantly go kaput on the App Store if they did that? What Apple is doing is supporting a new API which they claim allows developers to access the power of the A7 chip on their mobile devices more easily and effectively. This is an iOS-centric thing, in other words. I’m not sure why every single announcement Apple makes has to be treated like this big travesty by many in the (largely non-Apple) programming community.
The bigger news at WWDC is that Apple is now using a new programming language. For those who argue that this is all part of Apple’s big plan to make everything proprietary … well, Objective-C was already a de facto proprietary language. It was, quite literally, only used for Apple development, and Apple was the only entity maintaining it. What Swift does is reassure Apple developers that they’ve made a good choice to stick with the platform, not only because the App Store ecosystem is far better than Android’s, but because they now get a truly modern language to work with that isn’t just some updated version of Objective-C with “modern features” chunked onto it. This is simply great for Apple developers, any which way you cut it. Oh, and you can include Objective-C and C code right alongside Swift, because they all use the same compiler. And the Swift development environment is absurdly cool.
Really not seeing the problem in any of this.
Thanks…this is a massive improvement:
public static boolean isLineOfSightEXT(int e0, int e1)
{
if (isValidEntity(e0) && isValidEnity(e1)) {
// <snip>
}
setError(ERROR_ENTITY_SLOT);
return false;
}
public static boolean canEntitySeeEntity(int e0, int e1)
{
boolean r = isLineOfSight();
if (getError() == ERROR_NONE) {
//<snip>
}
I can’t tell if you’re being sarcastic or not but… Yes. Yes, it is a huge improvement.
It depends on what point of view I’m taking. Yes direct access to a given item is much better than to an implied item. My joke example is intended to highlight how awful the API design is for today’s world. Ignoring the bigger picture it require minor inefficiencies everywhere and ones that aren’t too nice to the limited branch prediction tables.
Seriously think about both sides, what’s required to happen in the driver and application side. If someone where to design a game engine in the same manner you’d tell them it’s the stupidest idea on the planet.
Evolution over revolution eh.
I suspect the issue they’re dealing with is more to do with making it language agnostic and easier bindings to other things. As it is OpenGL is relatively easy to map to OOP languages in whatever style you’d like to do it, whereas an existing OOP style mandated by OpenGL would remove the choices.
Cas