I have an application using OpenGL code. Now I want to convert it into JOGL code. Is it possible to convert OpenGL code to JOGL? What are the changes we have to do?
There are the famous suit of Nehe Tutorials for OpenGL, as mentioned above. The best part of this tutorial is that you can view JOGL and Ogl side by side. In Jogl you basically get a thin wrapper around OpenGL with Java syntax, garbage collection and all other libraries available. Making streaming objects and textures over the net and rendering them via OpenGL a breeze, you can also play around with shaders and perform array calculations faster in java using Jogl.
This tutorial might be handy. Basically you need to make all the OpenGL global function calls into calls on the proper object instance. This goes for constants too:
glBegin(GL_WHATEVER);
becomes
gl.glBegin(GL.GL_WHATEVER);
Most opengl functions are named the same in jogl and reside in the GL class. If you know opengl then it will be very easy for you to port it to jogl.
the first steps are:
GL gl = arg0.getGL();
GLU glu = arg0.getGLU();
Have a look at some tutorial on the web which will help you to get started.
Related
I'm currently developing a GameEngine API/framework so far I have an OpenGL 4.6 context where I load all the functions by myself (no OpenGL wrapper). The Engine is still under heavy construction, but some 3D stuff is already possible. Now the Engine was targeted to primarily draw 3D objects, but I'm also considering 2D stuff (though I haven't started yet to implement it).
Right now I'm creating kind of a user interface framework (which can be used instead of the 3D or 2D engine and likewise) "like" MFC, WinForms... you name it. For that, I'm using Windows's OpenGL 1.1 implementation, and that's where we get to my actual question.
Is using such an old OpenGL, or any legacy OpenGL version, considered as a bad practice? I know this question may be opinion-based, but especially in my case, I think it's the easiest way to create reusable controls; besides from that it's super interesting to create controls like a button all by myself, you have to think about everything. And I don't think Microsoft will remove it soon from their API if so, this would mean, we wouldn't be able to get an OpenGL context at all if I'm not completely wrong on that.
Additional information:
The way people/I should use the framework is, you would need to choose one of the types, the Engine can provide, such as 3D, 2D or creating a "normal" user-interface.
The reason I choose Windows's OpenGL implementation for the user-interface is, that it would also be possible to create a user-interface for Windows XP.
I currently use functions like glBegin(), glEnd(), glVertex2f() and glColor3f() to draw a button and wglUseFontBitmaps(), glPushAttrib(), glListBase(), glCallLists(), glPopAttrib() to draw the text.
Regarding the OpenGL context, I use Nehe's way to get a context:
http://nehe.gamedev.net/tutorial/creating_an_opengl_window_(win32)/13001/
So for the user-interface, I don't use the 4.6 context but 1.1
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.
What graphics engine Maya uses, OpenGL or DirectX? Does it at all use any? Since maya is written in C++.
For going deep into Maya, is it proper to learn to use OpenGL or one should go with DirectX?
My questions specially are associated with adding super new functionalities, such as new edge-system for a certain geometry in Maya.
What graphics engine Maya uses
Its own.
Neither OpenGL nor Direct3D are graphics engines. They're drawing APIs. You push in bunches of data and parameters and shaders to make sense of that data, and rasterized points, lines and triangles on a 2D framebuffer come out on the other side. That's it.
Maya, like every other graphics program out there implements its own engine or uses a graphics engine library that maybe uses Direct3D or OpenGL as a backend. In the case of Maya OpenGL is used for the interactive display. But the offline renderer is independent from that.
For going deep into Maya, is it proper to learn to use OpenGL or one should go with DirectX?
As long as you don't want to write lower-level-ish Maya plug-ins, you don't have to learn either.
My questions specially are associayted with adding super new functionalities, such as new edge-system for a certain geometry in Maya.
You surely want to make that available to the offline renderer as well. As such neiter OpenGL nor Direct3D are of use for you. You have to implement this using the graphics pipeline functions offered by Maya and its renderer. Note that you might also have to patch into external renderers if you want to use those with your news edge features.
I'm interested in converting to Haxe as my primary programming language, and it's been awesome so far, however one of my requirements is that I can use OpenGL 3.3 with the C++ target for some 3D game work.
However, this seems to be an odd thing to do as I can find very little info online about using OpenGL in Haxe. I've found some libraries, especially hx-ogl and foo3d (abstracted ogl-like) but they're all unmaintained and I can't get them to work. I've also found some 3D engines but I'd like to use pure OpenGL. Also, I only need to target C++ so cross-platformness isn't required.
Has anyone successfully got OpenGL working with Haxe C++?
Haxe guys work on OpenGL wrapper continuously but at the moment Haxe (NME) supports the OpenGL ES 2.0 API for both desktop and mobile, which means you can use a programmable shader pipeline on both desktop and mobile. You can see a code example here.
But if you say:
I only need to target C++ so cross-platformness isn't required
Then why won't you use just C++ with whatever OpenGL version you want?
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.