In trying to work through tutorials on JOGL, I run into trouble when entering this part of the code:
#Override
public void display(GLAutoDrawable glad) {
GL gl = glad.getGL();
gl.glClear(GL.GL_COLOR_BUFFER_BIT);
gl.glBegin(GL.GL_TRIANGLES);
This doesn't compile because glBegin is not a method in GL even though the online tutorials use it that way. By digging around in the JOGL javadoc I found that I could get the tutorial to work by doing this:
GL2 gl = (GL2) glad.getGL();
Then all the methods are there. My questions are:
Can I expect a different interface to be returned by getGL on different platforms? This is on MacOS 10.9. What controls what version of the interface is used?
Since it appears that the tutorials are out of date, did this work under a different version of OpenGL?
Please look at our Java documentation and our overview of OpenGL evolution. The GL interface you get depends on the GLProfile you use and the GL interface your machine supports. It doesn't depend on your operating system but rather on what is supported by your graphics card. All methods were in GL in JOGL 1 whereas there are several GL interfaces and implementations in JOGL 2. user3256930's answer is incomplete. A desktop machine can support both OpenGL (backward and forward compatible profiles) and OpenGL ES. Then, there are at least 3 GL implementations that you can get and it depends on your profile, you can call GLProfile.getMaxFixedFunc(boolean), GLProfile.getMaxProgrammable(boolean), getDefault(), ...
As glBegin is only in the fixed pipeline and not in OpenGL ES, you'll get it only if the GL interface you get is GL2 or another interface that extends it, for example GL4bc (bc = backward compatible).
Please rather post your questions specific to JOGL on our official forum.
Your question is very similar to Can't find GL.glColor3f in JOGL?. The reason why you were not able to use glBegin without casting to GL2 is because glBegin (and many other functions) were deprecated in OpenGL 3. This is known as immediate mode where you specify vertices between glBegin and glEnd. In OpenGL 3 and higher the way to draw primitives is by storing the vertices in a buffer and drawing with glDrawArrays or glDrawElements. You will get different versions of OpenGL on different platforms and different computers. It depends on what version of OpenGL is supported on that computer. Newer computers with newer graphics cards will be able to support the latest version of OpenGL while older computers might be stuck on an older OpenGL version.
Related
If I am currently developing a game for windows using SDL and GLEW (for OpenGL 3.0+) and I later want to port my game to Android, will I have to rewrite the majority of my code to convert from OpenGL 3.0 to OpenGL ES 2.0? Are there any programs that do this for me? Is it a big deal switching from OpenGL to OpenGL ES?
Not at all, it is very easy to convert.
Only differences are shader variables and constants, and suffixes like GL_RGBA8 to GL_RGBA8_OES. However, there are limits in OpenGL ES. For instance, you can use only GL_UNSIGNED_BYTE or GL_UNSIGNED_SHORT as indices data type GL_UNSIGNED_INT. Which means, you can not draw more than 65,535 indices at one go. It is not a big deal although you should refer to the official OpenGL ES manual, https://www.khronos.org/opengles/sdk/docs/man/
Refer to the link OpenGL ES 2.0 vs OpenGL 3 - Similarities and Differences by coffeeandcode
It really depends on your code
OpenGL ES 2.0 (and 3.0) is mostly a subset of Desktop OpenGL.
The biggest difference is there is no legacy fixed function pipeline in ES. What's the fixed function pipeline? Anything having to do with glVertex, glColor, glNormal, glLight, glPushMatrix, glPopMatrix, glMatrixMode, etc... in GLSL using any of the variables that access the fixed function data like gl_Vertex, gl_Normal, gl_Color, gl_MultiTexCoord, gl_FogCoord etc...
If you use any of those features you'll have some work cut out for you. OpenGL ES 2.0 and 3.0 are just plain shaders. No "3d" is provided for you. You're required to write all projection, lighting, texture references, etc yourself.
If you're already doing that (which most modern games probably do ) you might not have too much work. If on the other hand you've been using those old deprecated OpenGL features which from my experience is still very very common (most tutorials still use that stuff). Then you've got a bit of work cut out for you as you try to reproduce those features on your own.
There is an open source library, regal, which I think was started by NVidia. It's supposed to reproduce that stuff. Be aware that whole fixed function system was fairly inefficient which is one of the reasons it was deprecated but it might be a way to get things working quickly.
I am developing a project using modern OpenGL through OpenTK. I want to use Gwen dot net GUI library in my project. Unfortunately, Gwen dot net uses old OpenGL for its widget rendering. I have tried merging both modern OpenGL and Gwen dot net and so far, have been unsuccessfull. Before I waste my time debugging my code, I would like to know, is it possible to merge both old OpenGL and modern OpenGL?
If you create a compatibility profile context, it should support all all legacy functionality. From OpenGL 4.3 compatibility spec, 1.2.4:
Older generations of graphics hardware were not programmable using shaders,
although they were configurable by setting state controlling specific details of their
operation. The compatibility profile of OpenGL continues to support the legacy
OpenGL commands developed for such fixed-function hardware, although they
are typically implemented by writing shaders which reproduce the operation of
such hardware. Fixed-function OpenGL commands and operations are described
as alternative interfaces following descriptions of the corresponding shader stages.
These days mixing old style and new style OpenGL is best avoided. On MS Windows and Linux you can, but weird stuff tends to happen.
For MacOS, Apple have declared that they're not going to support compatibility contexts at all, so you can't mix.
Since you're stuck with the GUI toolkit, I would try to isolate all your new style OpenGL code in a separate context and render to an offscreen target, then blit that to the main display.
OpenTK render for GWEN is a separate class. Just rewrite it modern way. There's no problem with that.
I just started programming in OpenGL a few weeks ago, and as people suggested to me, I used GLFW as my window handler. I also used GLEW as my extensions handler. So I go through the whole process of making a vertex buffer with three points to draw a triangle and passing it to OpenGL to draw it and I compile and run. No triangle draws, presumably because I didn't have any shaders. So I think to myself "Why don't I lower my OpenGL version through the context creation using GLFW?" and I did that. From OpenGL 3.3 to 1.1 and surely enough, there's a triangle. Success, I thought. Then I remember an article saying that vertex buffers have only been introduce in OpenGL 3, so how have I possibly used an OpenGL 3 feature in a 1.1 context?
The graphics driver is free to give you a context which is a different version than what you requested, as long as they are compatible. For example, you may get a v3.0 context even if you ask for a v1.1 context, as OpenGL 3.0 does not change or remove any features from OpenGL 1.1.
Additionally, often times the only difference between OpenGL versions is what extensions that the GPU must support. If you have a v1.1 context but ARB_vertex_buffer_object is supported, then you will still be able to use VBOs (though you may need to append the ARB suffix to the function names).
I am currently taking a Game Console Programming module at Sunderland University.
What they are teaching in this module is OpenGL and Phyre Engine to develop PS3 game.
The fact that PS3 SDK kit is not available for free (it is quite expensive) makes it really difficult for me to get around when a problem arises.
Apparently, PS3 framework doesn't support most of the gl function calls like glGenList, glBegin, glEnd and so on.
glBegin(GL_QUADS);
glTexCoord2f(TEXTURE_SIZE, m_fTextureOffset);
glVertex3f(-100, 0, -100);
//some more
glEnd();
I get errors when debugging with PS3 debug mode at glBegin, glEnd and glTexCoord2f.
Is there any way to get around it?
like a different way of drawing object, perhaps?
Most games developed for the PS3 don't use OpenGL at all, but are programmed "on the metal" i.e. make direct use of the GPU without an intermediate, abstrace API. Yes, there is a OpenGL-esque API for the PS3, but this is actually based on OpenGL-ES.
In OpenGL-ES there is no immediate mode. Immediatate Mode is this cumbersome method of passing geometry to OpenGL by starting a primitive with glBegin and then chaining up calls of vertex attribute state setting, concluded by submitting the vertex by its position glVertex and finishing with glEnd. Nobody wants to use this! Especially not on a system with limited resources.
You have the geometry data in memory available anyway. So why not simply point OpenGL to use what's already there? Well, that's exactly what to do: Vertex Arrays. You give OpenGL pointers to where find data (generic glVertexAttribPointer in modern OpenGL, or in old fixed function the predefined, fixed attributesglVertexPointer, glTexCoordPointer, glNormalPointer, glColorPointer) and then have it draw a whole bunch of it using glDrawElements or glDrawArrays.
In modern OpenGL the drawing process is controlled by user programmable shaders. In fixed function OpenGL all you can do is parametize a inflationary number of state variables.
The OpenGL used by the PlayStation 3 is a variant of OpenGL ES 1.0 (according to wikipedia with some features of ES 2.0).
http://www.khronos.org/opengles/1_X
Has the specification. There doesn't seem to be glBegin/glEnd functions there. Those (as in, fixed pipeline functions) are deprecated (and with OpenGL 4.0 and OpenGL ES 2.0, removed) in favor of things like VBO's anyway though, so there probably isn't much point in learning how to work with these.
If you are using PhyreEngine, you should generally avoid directly calling the graphics API directly, as PhyreEngine sits on top of different APIs on different platforms.
On PC it uses GL (or D3D), but on PS3 it uses a lower-level API. So even if you used GL-ES functionality, and even if it compiles, it will likely not function. So it's not surprising you are seeing errors when building for PS3.
Ideally you should use PhyreEngine's pipeline for drawing, which is platform-agnostic. If you stick to that API, you can in principle compile your code for any supported platform.
There is a limit to how much I can comment on PhyreEngine publicly (sorry), but if you are on a university course, your university should have access to the official support forums where you could get more specific help.
If you really must target the underlying graphics API directly, be aware that you may need to write/modify your code per-platform, and that you will need to 'play nice' with any contextual state that PhyreEngine may rely on.
I'm writing an implementation for OpenVG and OpenGL|ES in Go, both of which depend on the Khronos EGL API, supposedly to ease portability I guess.
I'm writing an implementation of OpenVG on top of OpenGL ES for fun and educational reasons - I haven't done a lot of rendering work and I'd like to learn more about the open APIs and practice implementing well defined standards (easier to see if I got the right results).
As I understand it, EGL provides a standard API for retrieving a drawing context (or what ever it's rightly called,) instead of using one of the multiple OS provided APIs (GLX, WGL etc)
I have a hard time believing Khronos would go through such effort and leave the standard OpenGL out of the loop but the thing is, I haven't found how or if OpenGL (the real deal) interfaces with EGL or if it's only OpenGL ES. If OpenGL ES can use the drawing context from EGL, would standard OpenGL also work?
I'm really new to all of this which is why I'm excited but the real project I'm doing is a Go widget toolkit that utilizes OpenVG for its drawing operations and uses hardware acceleration wherever possible.
If OpenVG, OpenGL and OpenGL ES depend on EGL, I think my question can be answered with "yes" or "no". Just keep in mind that I dove into this subject head-first last night.
Does OpenGL use or depend on EGL?
Off topic, but there is no EGL tag. Should there be?
You can bind EGL_OPENGL_API as the current API for your thread, via the eglBindAPI(EGLenum api); a subsequent eglCreateContext will create an OpenGL rendering context.
From the EGL spec, p42:
Some of the functions described in this section make use of the current rendering API, which is set on a per-thread basis
by calling
EGLBoolean eglBindAPI(EGLenum api);
api must specify one of the supported client APIs , either EGL_OPENGL_API,
EGL_OPENGL_ES_API, or EGL_OPENVG_API
The caveat is that the EGL implementation is well within its rights not support EGL_OPENGL_API and instead generate an EGL_BAD_PARAMETER error if you try to bind it.
It's also hard to link to libGL without picking up the AGL/WGL/GLX cruft; the ABI on these platforms require that libGL provides those entry points. Depending on what platform you're playing with this may or may not be a problem.
Does OpenGL use or depend on EGL?
No. You can run OpenGL without EGL.
But is possible to have EGL implementation capable to create desktop OpenGL context. That's because EGL's eglBindAPI(int api) allows EGL_OPENGL_API, EGL_OPENGL_ES_API, or EGL_OPENVG_API.
But if you ask:
Does OpenGL-ES use or depend on EGL?
The answer is yes, but there are exceptions.
Currently (2015), you have several implementations of OpenGL-ES that rely on EGL to create graphics context: Google ANGLE, PowerVR, ARM MALI, Adreno, AMD, Mesa, etc.
But on recent releases of NVIDIA and Intel drivers you can also request OpenGL-ES contexts directly, where extensions WGL_EXT_create_context_es_profile and WGL_EXT_create_context_es2_profile are available (Windows). Same thing on Unix platforms where GLX_EXT_create_context_es_profile and GLX_EXT_create_context_es2_profile extensions are available.
The intent of EGL is to ease developers' lives by creating a portable and standard way to initialize and get context of supported graphics API, without worrying about platform specific issues, as WGL, GLX, etc. That is a problem of EGL implementers, not final programmer.
There is no relationship between OpenGL and EGL. EGL generally does not run on desktops, and there is no ability to create a desktop OpenGL context through EGL.
OpenGL contexts are instead created and managed by platform-specific APIs. On Windows, the WGL API is used. On X11-based platforms, GLX is used. And so forth.
There was some noise last year from Khronos about creating a version of EGL that could work on the desktop and make OpenGL contexts, but thus far, nothing came of it.