Hi !
Featured games (85)
games approved by the League of Dukes
Games in Showcase (616)
Games in Android Showcase (173)
games submitted by our members
Games in WIP (659)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  C++ for Modern OpenGL  (Read 1554 times)
0 Members and 1 Guest are viewing this topic.
Offline Joshua Waring
« Posted 2013-01-20 14:40:52 »

I have to ask, but I've noticed the majority of tools with the intent of debugging shaders and OpenGL are targeted at C++. which makes me question, maybe OpenGL in C++ is better for getting the ropes on modern OpenGL. I was wondering if anyone agrees or what your thoughts on this are.

The world is big, so learn it in small bytes.
Offline ctomni231

JGO Wizard

Medals: 99
Projects: 1
Exp: 7 years

Not a glitch. Just have a lil' pixelexia...

« Reply #1 - Posted 2013-01-20 14:48:52 »

To be honest, OpenGL is made for C/C++. Java is just "borrowing" the code so we can have access to faster graphics bindings and API. This is the main reason why natives are needed, so you can run OpenGL bindings on all the different systems. (C has to compile different source code for different OS.)

To answer your question, just code what you feel most comfortable in. You are able to do pretty much everything you can in Java as you can in C/C++, if you just look for the right tutorials or mess around with it enough.

Offline greenOwl

Junior Devvie

Medals: 1

from Germany

« Reply #2 - Posted 2013-01-20 18:02:03 »

OpenGL is no programming language (its a specification) neither is it "made" for any particular language. Fact is that (the common) implementation(s) for OpenGL are written in C and thereby making it much easier to use these implementations in C / C++ (see the pointer-problem in Java).

The fact that most tools are written for C / C++ is that most applications that make use of OpenGL are traditionally written in C / C++.
To use modern OpenGL you need a modern implementation (and a wrapper for it if you cannot use that implementation dircetly). So feel free to use the JNI and the implementation dircetly or choose a modern wrapper framework like LWJGL or JOGL (for java).

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline sproingie

JGO Kernel

Medals: 202

« Reply #3 - Posted 2013-01-20 18:05:11 »

OpenGL was absolutely made for C, from the flat namespace to the datatypes to the non-overloaded function names.  It happens to be usable in other languages because C glues to everything, but don't kid yourself that the creators of OpenGL were envisioning any kind of language-agnostic API.
Offline greenOwl

Junior Devvie

Medals: 1

from Germany

« Reply #4 - Posted 2013-01-20 18:07:16 »

How can an specification be "made for" a language?

Offline sproingie

JGO Kernel

Medals: 202

« Reply #5 - Posted 2013-01-20 18:07:47 »

(Editing like the Ministry of Truth here, I guess I am interested in having this argument)

All right, they did actually write a rather language-agnostic API largely by sticking to the subset of C that ports everywhere, and using their own GL_* datatypes (that happen to map exactly to C's small set of types).  Other than that, the specification and the API are largely one and the same in a great many areas.  I'll give them another thing, they did avoid the use of structs, which made the task of gluing it to other languages immensely easier.  A shame we got such pervasive statefulness in the bargain...
Offline Best Username Ever

Junior Devvie

« Reply #6 - Posted 2013-01-20 18:23:27 »

OpenGL is an API. APIs with bindings for multiple languages typically define a C interface as their "official" interface. Calling conventions in C define the size of parameter types, the order that parameters get pushed onto the stack, and how values get returned. You could use the API just as easily in assembly language as Java, C, C++, C#, Objective-C, Javascript, Python, assembly code, etc. Using a consistent calling convention is all that matters and C function headers are a good human readable format for conveying that information.

The program behind the API and the program using the API do not need to be C. You could have a Java program communicate with a Visual Basic API using an interface defined in C but with the actual wrapper code written in assembly - if all you were doing was passing around primitives, array pointers, and buffer pointers, like with OpenGl.

C++ is sometimes used because of it's operator overloading and because it's value based object variable types make certain operations easier. I don't know how something like LWJGL does it or what options Java has for communicating with native code, but if you could do something like inline assembly then there would be no performance hit on calls to OpenGL compared to any other language.
Offline sproingie

JGO Kernel

Medals: 202

« Reply #7 - Posted 2013-01-20 18:46:29 »

Any language with direct memory access (which includes Java if you dig into the sun.misc.unsafe namespace) can glue any other language, but there's limits on what's practical and sensible to do.  

Java's notion of "inline assembly" would be the JIT compiler, which doesn't take long to kick in for the average LWJGL app.  Unfortunately, largely because of things like memory management, JNI can't optimize away a lot of calls.  LWJGL uses a lot of DirectByteBuffers to minimize that overhead, but the price is paid at allocation time, since each one requires a rather expensive malloc() to create.  Even then, OpenGL, being a client-server design, copies everything you pass to it and that adds its own overhead even in the face of modern MMUs.  At least that overhead is democratic though -- even C pays for it.

Call overhead is not really that significant in modern APIs though.  Look at DirectX's performance, and that has to go through the COM machinery to do everything.
Pages: [1]
  ignore  |  Print  
You cannot reply to this message, because it is very, very old.

Coldstream24 (18 views)
2015-09-03 00:41:28

Andrew_3ds (29 views)
2015-09-01 19:08:10

afikri (20 views)
2015-08-31 09:30:22

afikri (27 views)
2015-08-31 09:30:07

afikri (14 views)
2015-08-31 09:27:24

afikri (17 views)
2015-08-31 09:26:40

Roquen (30 views)
2015-08-29 11:30:54

GamerC4 (38 views)
2015-08-22 20:38:50

GamerC4 (36 views)
2015-08-22 20:37:18

GamerC4 (42 views)
2015-08-22 20:37:01
HotSpot Options
by Roquen
2015-08-29 11:33:11

Rendering resources
by Roquen
2015-08-17 12:42:29

Rendering resources
by Roquen
2015-08-17 09:36:56

Rendering resources
by Roquen
2015-08-13 07:40:51

Networking Resources
by Roquen
2015-08-13 07:40:43

List of Learning Resources
by gouessej
2015-07-09 11:29:36

How Do I Expand My Game?
by bashfrog
2015-06-14 11:34:43

List of Learning Resources
by PocketCrafter7
2015-05-31 05:37:30 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‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!