Libraries. Format conversions. Also, try doing live texture manipulation (which is the basis of 3d-desktop effects for example)
Java has more libraries and a larger developer community than any other programming language or platform on the planet. Fucking google it, I'm not your mama.
"Live texture manipulation" is all done on the GPU with render to texture effects anyway. It's much slower to do it on the CPU, even if you're doing it in assembly written specifically to take advantage of the hardware.
No. What about conversion of geometric models, prunning, etc. Your experience shows through.
"conversion of geometric models" this is something you do offline anyway, even if Java was slow (which it isn't) it wouldn't matter from a "real time" or OpenGL perspective. I'm not sure what "prunning" is but it's probably because I haven't yet reached your level of programming mastery.
Talk is cheap, and marketing speak even more so.
So when I debunk the moronic, retarded things you say, that makes it "marketing speak." LOL, you're a pro.
That's not the problem, and actually Java mangles things for a good reason. But it slows things down and it takes control from the developer , like the fp control word.
What exactly is the problem then, I fail to see what you're even talking about in regard to OpenGL?
You seem to have no real understanding of performance, real time, java or even any programming concepts or techniques beyond trivial applications.
What I meant is loading a picture and using it as a texture.
Oh, so how does this even matter from a language/platform/execution standpoint? In the case of loading a texture from disk, you're going to be limited by IO wait anyway, which means even something like Bash would work initiating the transfer and waiting while it's finished.
Interesting. Still, you're going to need to read a model from a file or create its geometry.
Again, you're talking about IO wait, which isn't really limited by your application's execution speed anyway. I'm sure you knew that though, you seem like a very experienced and capable programmer.
Yeah, but I wouldn't advocate Java for 'real time' apps also the kind of geometry processing OpenGL requires. (which is what you'll probably be doing apart from the OpenGL triangle demo)
Your application doesn't usually "process" geometry, in any sane application you just send off a big chunk of data to the server and the OpenGL implementation handles it from there. Regardless, Java is fast, so if you're generating the geometry it's fine anyway. Java lets you use OO development techniques and still get great performance and it works fine for "real time" applications.
Please type 'java floating point' into google and check the first article
I hate to be the one to break this to you, but floating point is fraught with all types of these issues. It's not a data type to be used for any application requiring exact calculations, which is why fixed point alternatives exist.
Besides that, OpenGL is going to mangle your floats and turn them into yet another representation on the GPU server side anyway.
I mean look at SIMD with something like SSE on an x86 chip. It will also *mangle* your floating point values, chomping off lots of data and return skewed values. It's just the nature of floating point.
I'm sorry, yes it appears the Superbible hasn't been updated (but I'm positive about Red and Orange).
The differences are mainly superficial in terms of how you provide geometry to the GPU and the shading language itself. Buffer objects work the same way, shaders work much the same but some terminology has changed.
It's mainly been streamlined and not revamped from scratch.
You need to work with pictures, access to buffers. Also, speed.
Oh, I've used OpenGL quite a while, in a few languages. I haven't ran across the "PICTURES" extension. Could you kindly point out the api doc on that one? I'm very interested now, because you sound like a very competent programmer.
"Access to buffers," you mean VBO's? lwjgl seems to support those. And Java supports in VM buffers, as well as out of VM native buffers via NIO. Maybe I'm off here, you seem to be a pretty up to date and with it programmer.
Oh and speed, you must have missed that memo: Java is pretty fast now, faster than statically compiled OO for sure.
They've been out for a while, check the out the Superbible (covers everything), the Red book (covers the client side API) and the Orange book (which covers GLSL, the OpenGL shading language).
All the major graphics IHV's provide that extension anyway. It would nice if it was in GL's core spec, but since it's included for any device that matters, it's not a practical concern.
Actually, HotSpot is much more advanced internally than either Microsoft's or Mono's CLR implementation.
This is evidenced by the fact that HotSpot significantly outperforms them both on most independent benchmarks I've seen.
Static compilation is not a magical panache that bestows performance, in fact for most OO architectures it provides more of a hindrance than a boost.
Also, "CIL" is the intermediate language that the CLR executes, which is very, very similar to the Java bytecode executed on a JVM. Comparing CIL to a Java VM makes no sense. Also, CIL is more or less a marketing term, because if Microsoft called it ".NET bytecode that runs on the.NET virtual machine," it would be more obvious to newbies that.NET is primarily just a knockoff of Java that only runs on Microsoft platforms
Slashdot Mirror
Libraries. Format conversions. Also, try doing live texture manipulation (which is the basis of 3d-desktop effects for example)
Java has more libraries and a larger developer community than any other programming language or platform on the planet. Fucking google it, I'm not your mama.
"Live texture manipulation" is all done on the GPU with render to texture effects anyway. It's much slower to do it on the CPU, even if you're doing it in assembly written specifically to take advantage of the hardware.
No. What about conversion of geometric models, prunning, etc. Your experience shows through.
"conversion of geometric models" this is something you do offline anyway, even if Java was slow (which it isn't) it wouldn't matter from a "real time" or OpenGL perspective. I'm not sure what "prunning" is but it's probably because I haven't yet reached your level of programming mastery.
Talk is cheap, and marketing speak even more so.
So when I debunk the moronic, retarded things you say, that makes it "marketing speak." LOL, you're a pro.
That's not the problem, and actually Java mangles things for a good reason. But it slows things down and it takes control from the developer , like the fp control word.
What exactly is the problem then, I fail to see what you're even talking about in regard to OpenGL?
You seem to have no real understanding of performance, real time, java or even any programming concepts or techniques beyond trivial applications.
You are amazing.
You're a moron, you've obviously some kind of fucking opengl newbie.
AA has nothing to do with the gl interface you're using, it's an OpenGL feature (and usually by extension).
C++ a superior language? LOL WUT?
C# is slightly better than Java, but it's basically Java with some nicer features tacked on.
What I meant is loading a picture and using it as a texture.
Oh, so how does this even matter from a language/platform/execution standpoint? In the case of loading a texture from disk, you're going to be limited by IO wait anyway, which means even something like Bash would work initiating the transfer and waiting while it's finished.
Interesting. Still, you're going to need to read a model from a file or create its geometry.
Again, you're talking about IO wait, which isn't really limited by your application's execution speed anyway. I'm sure you knew that though, you seem like a very experienced and capable programmer.
Yeah, but I wouldn't advocate Java for 'real time' apps also the kind of geometry processing OpenGL requires. (which is what you'll probably be doing apart from the OpenGL triangle demo)
Your application doesn't usually "process" geometry, in any sane application you just send off a big chunk of data to the server and the OpenGL implementation handles it from there. Regardless, Java is fast, so if you're generating the geometry it's fine anyway. Java lets you use OO development techniques and still get great performance and it works fine for "real time" applications.
Please type 'java floating point' into google and check the first article
I hate to be the one to break this to you, but floating point is fraught with all types of these issues. It's not a data type to be used for any application requiring exact calculations, which is why fixed point alternatives exist.
Besides that, OpenGL is going to mangle your floats and turn them into yet another representation on the GPU server side anyway.
I mean look at SIMD with something like SSE on an x86 chip. It will also *mangle* your floating point values, chomping off lots of data and return skewed values. It's just the nature of floating point.
Yeah, but anyone using OpenGL with X is going to be using either the Nvidia proprietary drivers or ATI proprietary drivers.
The OSS offerings do not provide nearly the same level of performance, unfortunately.
So again, from a real world practical standpoint, Mesa isn't in use anyway.
It's like Ford's Model-T: You could order in any color you wanted, so long as that color was black.
How many products are shipped with Mesa as an important, primary component?
If you're using OpenGL, 99% of the products are going to want real hardware acceleration, not Mesa.
Mesa is a great project though, don't get me wrong.
I'm sorry, yes it appears the Superbible hasn't been updated (but I'm positive about Red and Orange).
The differences are mainly superficial in terms of how you provide geometry to the GPU and the shading language itself. Buffer objects work the same way, shaders work much the same but some terminology has changed.
It's mainly been streamlined and not revamped from scratch.
The fixed function api doesn't exist in 3+.
Modern OpenGL (3+) has it's roots in OpenGL ES. Many of the changes and cleanups happened in OpenGL ES first and were later applied to OpenGL.
So you really should count OpenGL ES.
You need to work with pictures, access to buffers. Also, speed.
Oh, I've used OpenGL quite a while, in a few languages. I haven't ran across the "PICTURES" extension. Could you kindly point out the api doc on that one? I'm very interested now, because you sound like a very competent programmer.
"Access to buffers," you mean VBO's? lwjgl seems to support those. And Java supports in VM buffers, as well as out of VM native buffers via NIO. Maybe I'm off here, you seem to be a pretty up to date and with it programmer.
Oh and speed, you must have missed that memo: Java is pretty fast now, faster than statically compiled OO for sure.
They've been out for a while, check the out the Superbible (covers everything), the Red book (covers the client side API) and the Orange book (which covers GLSL, the OpenGL shading language).
There are well tested, production ready OpenGL bindings for Java: http://lwjgl.org/
Java fits better with OpenGL anyway, being cross platform and open in the same vein as OpenGL.
Yeah, that's why Valve just ported their games to Mac, which only supports OpenGL.
Because it's DOA for anything but "PRO GAMERZ."
It's most similar to D3D 11.
DirectX is a larger set of development technologies and apis (most of which has been deprecated). Direct3d is it's "direct" analog to OpenGL.
It's not really a huge problem in practice.
All the major graphics IHV's provide that extension anyway. It would nice if it was in GL's core spec, but since it's included for any device that matters, it's not a practical concern.
Actually, HotSpot is much more advanced internally than either Microsoft's or Mono's CLR implementation.
This is evidenced by the fact that HotSpot significantly outperforms them both on most independent benchmarks I've seen.
Static compilation is not a magical panache that bestows performance, in fact for most OO architectures it provides more of a hindrance than a boost.
Also, "CIL" is the intermediate language that the CLR executes, which is very, very similar to the Java bytecode executed on a JVM. Comparing CIL to a Java VM makes no sense. Also, CIL is more or less a marketing term, because if Microsoft called it ".NET bytecode that runs on the .NET virtual machine," it would be more obvious to newbies that .NET is primarily just a knockoff of Java that only runs on Microsoft platforms
Achtung! Don't not throw controller at PS3's remaining good eye!
I wasn't trying to make excuses for the guy, just saying that's why the Wii is being mentioned.
Cue Jack Thompson.
"See! See! I told you these video games turn kids into killers!"
If you read the article, they had an enclosure for the Wii remote that looked like a real gun.
So more like the original Nintendo zapper, before they made it bright orange.
yeah, because her dad is probably really well right now.
He's an idiot, but I dunno if he really needs jail. I'm sure the loss of his child is punishment enough.
I can't imagine how terrible being in his situation would be, sounds worse than jail.
It's like every Mono project, half done, incompatible, doesn't really work.
Mono is the new Wine. (and that analogy goes deeper than you might think)
Yeah, it's infinitely shittier.
Kudos to the moron who modded you insightful.
That's funny because XNA is a .NET technology, .NET being Microsoft's take on Java.
Where do stupid people like you come from?