I want to write cross-platform 3D app (maybe game, who knows) with SFML and OpenGL 3.3 with the main purpose to learn C++.
SFML provides cool event model, handles textures, texts, inputs etc. I've done simple demo with cube (still in old glBegin/glEnd way, but I'll fix it when I'll find a way to attach OpenGL extensions).
The first problem which I got is a double bufferization. As you must know, usual (and logic) way to perform rendering uses two buffers, display buffer and render buffer. Rendering cycle performed on render buffer and when it ends, the result coping to display buffer (or maybe there's two same buffers just switching roles per cycle, don't know). That's prevents flickering and artifacts.
The trouble is that at any OpenGL example which I see authors using GLUT and functions like glutSwapBuffers. If I understand correct, double buffering is platform-specific (and that's strange for me, because I think it must be done on OpenGL part) and things like GLUT just hides platform-specific points. But I'm already using SFML for context and OpenGL initialization.
Is there any cross-platform way to deal with OpenGL double-buffering in pair with SFML? I'm not using SFML graphics in this project, but target is a RenderWindow.
SFML can handle double buffering, but if you are not using the SFML Graphics library you must use an sf::Window instance.
Double buffering is handled by calling sf::Window::setActive to set the window as the OpenGL rendering target, drawing content using OpenGL functions, and then calling sf::Window::display to swap the back buffer. More information can be found in the SFML API (linked version is v2.3.2).
Related
I'm trying to make a SDL2 adapter for a graphics library. I believe this library assumes that all the things it draws in the screens stay in the screen as long as it never draws something in top of it. (See the end of the question for details about this)
What would be the best way to do it?
I've come across multiple solutions, including:
Hardware rendering without calling SDL_RenderClear. The problem with this is that SDL uses a double buffer, so the contents can end up in either of them, and I end up seing only a subset of the render at a time.
Software rendering, in which if I'm understanding SDL correctly, it would mean having a surface that I mapped to a texture, so I can render the texture, and I would edit the pixels field of the surface in main memory. This would be very slow, and also as the library expects everything rendered instantly and has no notion of frames would mean to send the data to the gpu every time there's an update (even single pixels).
I'm probably missing something about SDL2 and definitely about the library (Adafruit-GFX-Library). What does transaction api means in this context? I've not been able to find any information about it, and I feel like it could be something important.
In my understanding of SDL2 and general rendering application programming, SDL2 is designed that you draw a complete frame every time, meaning you would clear your "current window" either by OpenGL API calls
glClearColor(0, 1.0, 0, 0);
glClear(GL_COLOR_BUFFER_BIT);
which clears the current OpenGL context i.e. frame buffer, of which you would have 2 or by using the SDL2 renderer which I am not familiar with.
Then you would swap the buffers, and repeat. (Which fits perfectly with this architecture proposal I am relying on)
So either you would have to replay the draw commands from your library for the second frame somehow, or you could also disable the double frame buffering, at least for the OpenGL backend, by
SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 0);
(For the other OpenGL SDL2 setup code see this GitHub repository with a general helper class of mine
I my collage i have to do a assignment in opengl and they intimidate us to do that in pure opengl. What it is just simply create and shown a transparent cube and put table inside it all of the model must create by the program they can't import by other modeling software like blender, 3dmax etc. And also they expect very high level lighting atmosphere in that cube. I am new to side and i heard that SDL is a game engine.
I wonder if i use SDL in my assignment may i end up with zero mark if it is not contain opengl? If there is good way to do this simple task please let me know!
Well, SDL is not a game engine and it is not pure OpenGL. However, you can build pure OpenGL applications using the windowing API that SDL gives you. SDL is just one of many options for window management and GL context creation.
SDL can set up a window for you, can set up the OpenGL context, and handle user input. From there, you can write pure OpenGL and render your cube or whatever. If you have not used OpenGL or SDL before, then you probably have a lot of work ahead of you.
As another difference, SDL does have an additional 2D rendering API. If your assignment is to do 3D with OpenGL, then obviously DO NOT use this 2D API.
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 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.
I'm writing an OpenGL game, and want native looking GUI elements. I was wondering if anyone has successfully hacked GTK+ using GtkOffscreenWindow and gtk_offscreen_window_get_pixbuf to render to an OpenGL texture, and whether this would have reasonable performance, considering repeated re-uploading of texture data every time the GUI is updated
While this is certainly possible, I'd instead use a real OpenGL widget toolkit like Clutter. If you want to render GTK+ with OpenGL, I'd start by creating a new GDK backend (X11/OpenGL or something like that), that (re-)implements all the GDK drawing functions using OpenGL. A nice side effect would be, that all GTK+ windows would allow for ordinary OpenGL rendering, too, i.e. no more need for a GtkGLWidget class.