Khronos Releases OpenGL 4.2 Specification
jrepin tips news that the Khronos Group has announced the release of the OpenGL 4.2 specification. Some of the new functionality includes:
"Enabling shaders with atomic counters and load/store/atomic read-modify-write operations to a single level of a texture (These capabilities can be combined, for example, to maintain a counter at each pixel in a buffer object for single-rendering-pass order-independent transparency); Capturing GPU-tessellated geometry and drawing multiple instances of the result of a transform feedback to enable complex objects to be efficiently repositioned and replicated; Modifying an arbitrary subset of a compressed texture, without having to re-download the whole texture to the GPU for significant performance improvements; Packing multiple 8 and 16 bit values into a single 32-bit value for efficient shader processing with significantly reduced memory storage and bandwidth, especially useful when transferring data between shader stages."
PARENT LINK IS GOATSE
And the reason for all of this new stuff is, what exactly? Playing the devils advocate: I can render tits just fine already, so why do I need this feature bloat as well? From a practical perspective: The old standard is ruining fine on games I love, and a new standard will just complicate things and force people to upgrade to hardware since it looks like some of this stuff would be difficult at best to do in software only and get good perf. From a commercial perspective: Great, now I have increased development costs as a result of a new standard that everybody will want to target just because its new, even if my game doesn't need any of the new fluff. From a open source perspective: I worry about the open source stack as a result, its already hard enough to develop games that matter for linux, and impossible to get a dev house to take it seriously that's not an Indy. It looks to me that somebody - the standards body - is just - in the paraphrased words of a popular song about airplanes "spec'n to stay relevant". Can somebody with more free time tell the rest of us the value this actually gives? Or is it so aparent - and I so old - that as the "old guy" I am just being bitter?
- d
It took me a good 30 seconds or so before I realized that I wasn't looking at some real-world DirectX code written in C++.
Warning, parent is goatse.cx troll.
WARNING Parent is GOATSE troll!
- d
Soviet Russia no longer exists. Were you expecting something else?
In Soviet Russia, something else expects you!
Have you heard about SoylentNews?
Yeah, it looks like C# to me.
Not only that, but the exact same post from dev346, dev347 and dev348.
If only all those efforts went into something productive.
I don't know what delusion planet you are posting from but here in the Real World OpenGL has left DirectX in the dust in both features and performance a long time ago.
Khronos is absolutely on fire with giving developers what they want as quickly as possible. OpenGL developers have access to the absolute bleeding edge features of new graphics cards that people who are stuck still using DirectX have to wait around for Microsoft to get off their ass and implement.
It shouldn't be surprising OpenGL has won the API war with Microsoft:
210 Million OpenGL ES based Android devices a year.
150 Million OpenGL ES based iOS devices a year.
Every Linux, Mac,and Windows machine
The dying PC games market and the last place Xbox 360 are the only places left in the world still using the dead end DirectX API.
Perhaps somebody in the know can enlighten me about this.
I see many fairly advanced features and functions in both the DX and OpenGL APIs , but I was under the impression that a modern graphics cards were basically designed to do a few fairly primitive operations very well and in parallel. So basically, how much of these APIs actually deal with interfacing the graphics card and it's hardware accelerated features, and how much of it is more along the lines of just a standard library that contains frequently used graphics algorithms?
Maybe my view of how programming is done these days is a bit naive, but I've always sort of felt there was a difference between the APIs that are there in order to let you use the hardware without mucking around with terribly low level and platform dependent stuff like interupts and so on, and on the other hand just standard libraries that is pretty much things where the code would be more or less the same on most platforms, but you just don't want to write it all over again whenever you make a new program ( things like some container class for C++ ).
My idea of what OpenGL and DirectX did was to let you access the features of the video card without having to worry about all the little differences between one card and another. So you could send the card a bunch of textures or something without having to rewrite the code for every card you wanted to run on.
Am I missing a lot here? Do the OpenGL and DirectX APIs also deal with a load of stuff that is just generally handy to have around when writing graphics programs?
But DirectX is no better.
The future lies in directly programming the hardware with a classical programming language, building your own renderers in software, hopefully not limited by outdated polygon technology.
Warning: Parent is GOATSE Troll.
- d
In case you missed his first post, this is a goatse troll.
Another goatse warning, here.
Slashdot should out anonymous posters that reach -1
I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
Warning: Parent is GOATSE Troll..
- d
Who owns the OpenGL spec? Previously, it was SGI, but once they threw it open, isn't it up to a SIG, or something like that? Or is Khronos the sole owner now? If not, how do they release any OpenGL spec?
VRRP, philosophically,
must ipso facto standard be
But standard it
needs to be free
vis a vis
the IETF
you see?
But can VRRP
be said to be
or not to be
a standard, see,
when VRRP can not be free,
due to some Cisco patentry.. s/VRRP/O
We are already at 4.2...
Wow, GL moves fast, but who cares, when you need to force your users to update their drivers so you can have the bare minimum "new" features.
Seriously, what's the rate of adoption? Perhaps it was never labeled properly but don't all default installs of GL support like 1.x? What drivers and cards provide support for GL 2.0+?
And most importantly why should I bother developing in a newer version of GL, if I don't know if the user will be able to update to the right version to run a game of mine? Better stick with the lower standards...
I find GL worse than trying to develop multiplatform with C99...
Looks like the MichaelKristopeit troll decided to move to a shorter username. :)
That's funny, Wine doesn't seem to be on the Android market....
You're missing the point. PC gaming is irrelevant. As it is, even dedicated portable gaming consoles seem to be becoming irrelevant. What is relevant are millions of small form factor devices, all of which use OpenGL and none of which run Windows. That is where gaming is going.
Maxim: People cannot follow directions.
Increases in truth directly with the length of time spent explaining them
I see they added optional extension to aIlow DirectX coexistence as far as using same texture in both apis in same appIication in same time....
Why?