How can you move 2D objects around in OpenGL? What is the mechanism? E.g., do we need to control frames?
An example code snippet would be welcome!
The short answer is that you can move an object by modifying the modelview matrix. This can be done in several ways and it depends on your coding preferences and which version of opengl drivers you have available.
Here's some partial code to get you started in the right direction:
The following is deprecated in Opengl 3.0+ (but even then it is still available via the compatibility profile).
// you'll need a game loop to make some opengl calls each frame
while(!done)
{
// clear color buffers, depth buffers, etc
initOpenglFrame();
glPushMatrixf();
glTranslatef(obj->getX(), obj->getY(), obj->getZ());
obj->draw();
glPopMatrixf();
// move the object 0.01 units to the left each tick
obj->setX(obj->getX() + 0.01);
// flush, swap buffers, etc
finishOpenglFrame();
}
For OpenGL 3.0 and beyond, glPushMatrixf(), glPopMatrixf(), glTranslatef(), and similar fixed function pipeline interface is all deprecated. If you need to using OpenGL 3.0 or greater, you'll want to do the same type of solution but you'll need your own implementation of matricies and a matrix stack. I think that discussion is beyond the scope of your question.
For further reading, and to get started with OpenGL, I'd recommend you check out nehe.gamedev.net. If you would like to get started with OpenGL 3.X, then I'd recommend purchasing the Opengl Superbible 5th Edition. Great book!
Related
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 want to creates a layer between any other OpenGL-based application and the original OpenGL library. It seamlessly intercepts OpenGL calls made by the application, and renders and sends images to the display, or sends the OpenGL stream to the rendering cluster.
I have completed my openg32.dll to replace the original library, I don't know what to do next,
How to convert OpenGL calls to images and what are OpenGL stream?
For an accurate description. visit the Opengl Wrapper
First and foremost OpenGL is not a libarary. It's an API. The opengl32.dll you have on your system is a library that provides the API and acts as a anchoring point for the actual graphics driver to attach to the programs.
Next it's a terrible idea to intercept OpenGL calls and turn them into something different, like multiple viewports. It may work for the fixed function pipeline, but as soon as shaders get involved it will break the program you hooked into. OpenGL is designed as an API to draw things to the screen, it's not a scene graph. Programs expect that when they make OpenGL calls they will produce an image in a pixel buffer according to their drawing commands. Now if you hook into that process and wildly alter the outcome, any graphics algorithm that relies on the visual outcome of the previous rendering for the following steps will break. For example any form of shadow mapping will be broken by what you do.
Also things like multiple viewport hacks will likely not work if the program does things like frustum culling internally, before making the actual OpenGL calls. Again this is because OpenGL is a drawing API, not a scene graph.
In the end yes you can hook into OpenGL, but whatever you do, you must make sure that OpenGL calls as made by the application get executed according to the specification. There is a authorative OpenGL specification for a reason, namely that programs rely on it to have predictable results.
OpenGL almost undoubtedly allows you to do the things you want to do without doing crazy modifications to it. Multi-viewpoints can be done by, in your render function, doing the following
glViewport(/*View 1 window coords*/0, 0, window_width, window_height / 2);
// Do all of your rendering for the first camera
glViewport(/*View 2 window coords*/0, window_height / 2, window_width, window_height);
glMatrixMode(GL_MODELVIEW);
// Redo your modelview matrix for a different viewpoint here, then re-render it all.
It's as simple as rendering twice into two areas which you specify with glViewport. If you Google around you can get a more detailed tutorial. I highly do not recommend messing with OpenGL as a good deal if it is implemented by the graphics card, and you should really just use what you're given. Chances are if you're modifying it you're doing it wrong. It probably allows you to do it a FAR better way.
Good luck!
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 know GLUT's quadrics, I used it in a few programs when I was in school. Now I'm working on a real world application and I find myself in need of drawing some geometric primitives (cubes, spheres, cylinders), but now I also know that GLUT is a no longer supported and it's last update was in like 2005. So I'm wondering if there's anything other than GLUT's quadrics to draw such geometric shapes. I'm asking if there's anything made before I go ahead and start making my own from vertices arrays.
Yes, you can! You can use the native API of the OS to create a window with OpenGL capabilities.
The advantage of GLUT is that is makes this task easier and is a cross-platform solution.
There are other cross-platform libraries that are more complex to work with but provide the same functionality, like Qt.
NeHe has a huge amount of examples that use several different technologies to accomplish what you are looking for. Check the bottom of the page.
Here is a demo for Windows that creates a window and draws a simple OpenGL triangle inside it. This demo removes all the window frame to give the impression that a triangle is floating on the screen. And here is a similar demo for Linux.
GLUT is just some conveniece framework that came to life way after OpenGL. The problem is not, that GLUT is unmaintained. The problem is, that GLUT was not and never will be meant for serious applications.
Then there's also GLU providing some primitives, but just as GLUT it's merely a companion library. You don't need either.
The way OpenGL works is, that you deliver it arrays of vertex attributes (position, color, normal, texture coordinates, etc.) and tell to draw a set of primitives (points, lines, triangles) from those attributes from a second array of indices referencing into the vertex attribute arrays.
There used to be the immediate mode in versions prior to OpenGL-3 core, but that got depreceated – good riddance. It's only use was for populating display lists which used to have a slight performance advantage if one was using indirect GLX. With VBOs (server (=GPU) side vertex attribute storage) that's no longer an issue.
While GLUT has not been maintained, FreeGLUT has. There are still several alternatives though.
GLFW is a cross-platform windowing system which is easy to get up and running, and also provides the programmer with control of the main application loop.
SFML has support for many languages and also integration capabilities with other windowing schemes, in addition to being cross-platform.
Finally, Qt is another, popular, cross-platform windowing framework.
Now I'm working on a real world application and I find myself in need of drawing some geometric primitives (cubes, spheres, cylinders),
Actually, I don't remember anything except glut that would provide generic primitives. This might have something to do with the fact that those generic primitives are very easy to implement from scratch.
You can use other libraries (libsdl, for example, or Qt) to initialize OpenGL, though.
Most likely if you find generic library for loading meshes (or anything that provides "Mesh" object), then it will have primtives.
is a no longer supported and it's last update was in like 2005
Contrary to popular belief, code doesn't rot and it doesn't get worse with time. No matter how many years ago it was written, if it still works, you can use it.
Also there is FreeGLUT project. Last update: 2012.
After googling a lot, I only have this space to ask you the next question.
I'm trying to writing a simple OpenGL 3.x sample to learn how works the new programmable pipeline (shaders). This tutorial is really helpful (and uses glut to keep things simple, as you can see) and great as a starting point. But the nightmare and questions starts when I'm trying to use the predefined glut objects (teapots i.e) and trying to move or rotate in a local way like the old and deprecated way (glScalef, glTranslatef, glRotatef, glLoadIdentity, glMultMatrixf, glPushMatrix and glPopMatrix...), but for now it's impossible for me.
If I'm trying to do that using a handy transformation matrix with a translation, it moves the whole scene globally (the two or more objects rotates, not only one, i.e.), but not local. I've found this similar question here, but still in a mess... (only works with vbos? every object in the scene has to have a unique shader?,...)
I don't know if I've explained clearly. Every tutorial I've found about this topic always uses a single object. If someone knows any well written tutorial or sample code that explains this, I'll much appreciate your help.
I will assume that, when you say "OpenGL 3.x", what you mean is core OpenGL 3.1 or greater. That is, you are not using a compatibility context.
First, you cannot use GLUT's predefined objects anymore. Nor can you use glu's predefined objects. If that's too much of a limitation for you, then I suggest you create a compatibility context.
The reason all of your objects move is because you didn't reset the uniforms between drawing the two objects. Uniforms are data in shaders that are set from OpenGL, but will not change over multiple executions of a shader within a single glDraw* call. The matrix functions in previous GL versions effectively set the equivalent of uniforms. So simply convert those functions into uniform setting.
If you want to see a tutorial series that uses GL 3.x core, then you can look at my tutorial series.
The key here is, that you need to maintain your own transfomration heirachy. glPushMatrix creates a copy of the current matrix on the active stack, then you apply some transform that's applied to the stack. Then drawing things they will recieve that transformation. glPopMatrix goes one step up in the hierachy.
In the case of Uniforms you no longer have matrix stacks. So instead of glPushMatrix you create a copy of the current transformation level matrix, apply the sub-transform and load that new matrix into the uniform.