What is Reddit's opinion of
OpenGL?
From 3.5 billion Reddit comments
➔ OpenGL website
By popularity on Reddit, this Service is:
100 reviews of this app found across Reddit:
CONCINDENCE ALERT! Moments ago I was reading this which is basically Apple making an OGL extension to do what D3DRS_SRGBWRITEENABLE does, which is the disgusting habit of per-drawcall gamma. But the motivation is that the Source engine does this all the fucking time.
Imagine all the possibilities of coupling that with OpenGL: glDrawElementsInstancedBaseVertexBaseInstance
I fought with this decision for a long time for my music visualizer. I built the engine to support both apis but eventually ignored the DirectX one and focused on OpenGL since it was just so much easier to get started and I didn't want to support two render engines. But I have regretted that decision. The problems I have are
- Bad documentation. The best one I have found is OpenGL wiki. Make sure you follow Common mistakes to the letter or your in a world of hurt.
- That one way to do something have been deprecated over and over and finding the right way to do it is very difficult. Just try to figure our how to correctly (With performance and compatibility in mind) render a set of triangles. It started way back with glVertex then they added another and another and another way.
- Lack of good tools. The now free gDEDebugger exists and helps but its far from the NVidia line of tools for DirectX
- But most of all is the drivers issue. You can all but forget about intel cards if you go with OpenGL. Their drivers are just horrible. The problem is that to support Windows 7 they must support DirectX. But they dont have to support OpenGL and that is exactly what some of them do. Trying to explain to a user that they need to download the latest drivers from the manufacturer to use the program is not a nice experience specially since they actually already have DirectX support from the default drivers.
Nearest neighbor works for mipmaps and OptiFine uses it.
By its nature FSAA and AF need to sample pixels outside of the current one, this is how they work.
There is a shader extension "centroid sampling" which avoids pixel sampling outside the current render coordinates, but it requires a custom shader.
That was something that was being discussed at Khronos quite some time ago. Essentially, we'd like to see a cross-platform window system binding for GL. Unfortunately, the effort failed as differing solutions were brought to market. AMD has its EGL implementation (http://developer.amd.com/tools-and-sdks/graphics-development/amd-opengl-es-sdk/), but it's proprietary, only works with AMD hardware and only for ES on the desktop. There's an extension to create ES2 contexts on desktop (http://www.opengl.org/registry/specs/EXT/wgl_create_context_es2_profile.txt) which is supported by NVIDIA at least, but it requires the setup of a desktop context first (to get the extension function pointers) and while it's not "EGL on the desktop", the ability to create an ES2 context through WGL or GLX extensions kind of squashes some of the impetus for an EGL ICD model.
The Mesa stack does expose EGL and I believe you can create desktop OpenGL contexts through it. However, there's still no cross-vendor EGL ICD model or implementation. It would be great if there were one - I would like to get out from under WGL on Windows and I think having a cross platform API for context creation and management would be great.
When you're working with a library like SFML/SDL/GLUT etc. you are still working with "raw" OpenGL. These libraries only help with creating a window that is OpenGL compatible and event handling.
If you don't want to use a library then you'll need to use your Operating System's window manager to create an OpenGL context. Here's how to create a context on Windows
Keep in mind that creating your window is only one part of the problem, after the window is created you need to handle events using your Operating System because there is no built in way for OpenGL to handle events. You will also need a sound library or again you can use your Operating System but that can be difficult because low level sound is a massive pain.
Good Luck, I hope this helped.
EDIT: That link only shows how to create a context using an existing window, you still have to create a window. Here's a link on how to do that.
EDIT 2: I didn't realize that the libraries you metioned have helper functions for OpenGL, since that's the case I would recommend reading the link /u/sufianrhazi posted.
> I don't think an extra 11ms of latency would fly when they're trying to get under 20ms
It also depends on how much latency they can reduce elsewhere. Since Oculus is implementing time warping right now it should remove a full frame of latency (11ms) when done on the CPU during scanout and nearly a full frame (9ms) when done on the GPU with the NV_delay_before_swap GL extension.
- OLED (current) : 1ms (USB) + 11ms (rendering) + 11ms (scanout) + 1ms (pixel switching) = 24ms
- OLED + time warping (GPU) : 1ms (USB) + 2ms (rendering) + 11ms (scanout) + 1ms (pixel switching) = 15ms
- LCD + time warping (GPU): 1ms (USB) + 2ms (rendering) + 11ms (scanout) + 15ms (pixel switching) = 29ms
- OLED + time warping (CPU) : 1ms (USB) + 0ms (rendering) + 11ms (scanout) + 1ms (pixel switching) = 13ms
- LCD + time warping (CPU) : 1ms (USB) + 0ms (rendering) + 11ms (scanout) + 15ms (pixel switching) = 27ms
So still not enough for LCD, but using LCD overdrive the pixel switching time can be reduced to as low as 4ms on the best LCD monitors : http://www.digitalversus.com/lcd-monitor/asus-vg248qe-p15654/test.html#full-review
Using this technology this would give a 16ms end-to-end latency with LCD + time warping (CPU). Not bad.
The problem in this model is the input lag of 13.3ms, but I don't know if it's only related to this specific model, if it can be reduced or removed and if it's related to LCD overdrive or completely independent.
>the best way to add or remove things from the buffer
The usual way is to use glMapBufferRange. It returns a pointer to the buffer, which you can modify however you want. You must call glUnmapBuffer before using the buffer again, e.g. drawing with it. This technique requires OpenGL 3 or ES 3.
Recent versions of OpenGL 4 have a new API that lets you keep the buffer mapped while using it, but you have to handle synchronization yourself. If you have to modify the buffer frequently this can be much faster.
>exclude just a few verticies from being drawn in one frame and have them re appear the next frame?
There are a lot of ways to do this. Try looking at all the available drawing functions here and see which one fits your needs best:
Nope. They say as much on their contact us page.
>Technical support for consumers or developers is available exclusively via the online message boards. We cannot answer any technical coding questions or any questions related to problems with games or OpenGL hardware.
An open source project has to be either their only choice or incredibly simple for companies to take a chance on it.
> Without buffer objects, geometry data must be sent to the GPU all the way from main memory every frame, which takes an order of magnitude longer.
Minecraft uses something called Display Lists (a sort of cached set of drawing commands), which are often stored in dedicated memory. They're deprecated now, of course, in favor of VBOs and IBOs
I have used OpenGL to make games, and I am a mod over on /r/opengl, and I have really mixed feelings about it.
1) The preferred method is to use vertex buffers to cram data to the GPU. This is all well and good, but OpenGL doesn't define any vertex formats.
2) There are lots of old functions that have been re-purposed to work with the new paradigm. Prime example being GLVertexPointer.
http://www.opengl.org/sdk/docs/man/xhtml/glVertexPointer.xml
This was originally put in place so you could define the vertex array format, for vertex arrays, but now behaves differently if there is a vertex buffer bound.
> If a non-zero named buffer object is bound to the GL_ARRAY_BUFFER target (see glBindBuffer) while a vertex array is specified, pointer is treated as a byte offset into the buffer object's data store. Also, the buffer object binding (GL_ARRAY_BUFFER_BINDING) is saved as vertex array client-side state (GL_VERTEX_ARRAY_BUFFER_BINDING).
3) GLSL shaders are icky.
There's not really a way to get around this, but until version 4, no shader sub routines, no precompiled shaders. (Here are some good GLSL tutorials anyways http://www.swiftless.com/glsltuts.html )
But you have to write all your own lighting, shading, texturing in your shaders.
You also have to decide if each shader is bound to a specific mesh or do you have a global shader with all the special cases? Writing shader code is probably my least favorite activity.
Not to forget, in addition to there being 4 versions of OpenGL, there are also 4 versions of the shader language, so you either have to go with the least common denominator, or pick your shader version at run time.
For a more modern approach, OpenGL 4.2 includes uniform subroutines. Basically they are function pointers that you switch between at runtime with very little overhead (as opposed to something like if statements).
This allows you to have 1 giant supershader that has all your sub shaders in it.
Also as of OpenGL 3.1 there are shared uniform buffer objects. Basically you make 1 block of uniforms for all your parameters and they can be shared between shaders. So you don't have to do things like upload a matrix a bunch of times.
This allows you to do things like put all your material information into an array in your shaders and just choose which one you want rather than upload the values every time.
But it's no so useful if you need to support older hardware.
Have a central Materials class that lets you choose between which shader you want to use. Ie material.usePhong() or whatever.
Implement some way to generate shader code. There is an ARB #include extension as of OpenGL 3.2. If you don't have that extension it's easy enough to fake. You will also want some basic code generation so you can generate the uniform blocks and share code between shaders.
How about GL_EXT_direct_state_access being core?
And yes, the ARB did promise the impossible with GL3. All in all I'm fine with the GL3 API... except for the lack of DSA. Bind-to-modify is an awful paradigm (though it made sense when it was first introduced)
Just use the core context.. e.g. http://www.opengl.org/wiki/Main_Page has wonderful documentation of core context only. There are a lot of great tutorials and resources speaking of only the core context (not going to pollute this comment with even more links). I honestly do not understand why people keep bringing up the old methods that exist outside of the core context, it's just not an argument. They introduced the core context precisely for this reason, so you can be done with that old cruft.
That being said, even though I like the way the new (read: core context) API works (as it lacks ridiculous indirect CPU-bound methods), even this API is gaining new features that shadow old functionality.
Now there is no question as to what method to use in the core context, there aren't a lot of different ways of doing things anymore. You simply use the newest functionality available on the running system. Which I prefer above monolithic D3D releases, as it is a lot more flexible.
But still, a new, revised API designed for modern graphics only would be very welcome. It will without doubt improve OGL a lot, get rid of some of the annoyances it is stuck with and such :)
Before you ask: yes I have used D3D/DX.
It could be a problem with interpreting the quotation marks. Have you tried using a combination of single and double quotes to ensure that they pair correctly?
Also follow the instructions here to check your open GL version. If it is in fact (1.4.0), difficulties may be had. As OpenGL's Faq explains "OpenGL is not a software product. it is a specification."
Best of luck XD
OpenGL does support compressed texture formats, but you probably have to ask for them explicitly. http://www.opengl.org/wiki/Image_Format
In your computations, in addition to width x height x bpp, throw in another x 1.33 for mipmaps.
According to the spec 1.5 has it, 1.3 does not:
http://www.opengl.org/registry/doc/GLSLangSpec.Full.1.30.10.pdf
http://www.opengl.org/registry/doc/GLSLangSpec.1.50.11.pdf
Why it works on your card, but not his, I have no clue.
Calling glutSwapBuffers() immediately after drawing is not optimal.
When you issue commands to OpenGL, they're effectively just adding onto a queue of commands to issue to the GPU, which begins executing in the background, and returns immediately. A call to glutSwapBuffers() (Or Present(), if you're on DirectX) will cause the program to stop and wait for all those operations to finish. glutSwapBuffers() calls glFinish() internally, which is a function that does not return until OpenGL is done with whatever commands it has queued up.
http://www.opengl.org/sdk/docs/man/xhtml/glFinish.xml
Additionally, any commands that read data back from OpenGL such as glReadPixels() or the result of hardware occlusion queries can cause the program on the CPU to choke while waiting for the GPU.
In order to fully utilize both processors, you should try to not have one waiting on the other all the time. I'd possibly even go as far as calling draw() before your update().
Another option is to just go multi-threaded and have one thread dedicated to feeding the GPU commands.
your question was actually rambling and incoherent, and your response to people trying to figure out what you were asking was rude.
read the extension definition like the rest of us.
Afaik, there are no books yet for OpenGL 4.x. But you'll find the specifications here: http://www.opengl.org/registry/
Trying to learn game programming and OpenGL at the same time is an awful idea. That the graphics part of a game is the biggest one, is a common misconception. The graphics code is just one piece of the puzzle. It makes no more sense to learn OpenGL while making a game, than say learning digital signal processing while making a game. Baby steps.
Also, OpenGL is just a dumb low-level API for hardware accelerated computer graphics. The stuff that takes a while to learn is not OpenGL, but the concepts from the computer graphics theory branch of computer science. Those concepts are very general and are not tied to OpenGL in any way. I recommend you buy books about computer graphics and not about OpenGL
Learning OpenGL is trivial. Learning computer graphics is difficult.
this is probably completely wrong, but doesn't texture2Dproj already do the W division step? why are you dividing again in your function?
see http://www.opengl.org/wiki/Sampler_(GLSL)#Projective_texture_access
in any case, if the w divide were wrong i'd expect different sort of errors, so this is probably not it.
You may want to know that only Mac OS 10.7 Lion and above supports OpenGL 3.2, and apparently only the 3.2 Core profile, which you have to request over the still-default-for-context-creation 2.1 Compatibility profile straight from Snow Leopard. I've heard 10.6 Snow Leopard and its OpenGL 2.1 still has a small presence, which is annoying. (I'm not too happy with Apple about all of this as a Mac user, honestly)
Personally, I would use OpenGL 3 anyway, but I'm a biased college student learning OpenGL starting with 3.2 (Internet recommendation to not get used to fixed shaders, plus using Mac 10.8).
It has been my and some of the Internet's experience that Intel graphics before the fairly recent ones sucked anyway though, so that and maybe Mac 10.6 may not be targets worth sticking with OpenGL 2 for. Future compatibility and "latest and greatest" and all that.
GLUT is very limited in what it does for OpenGL. It's primarily there to provide abstraction to the various operating system-dependent calls.
As a simplified example, say on Windows you call WindowsCreateWindow() to create a window with an OpenGL context. On Linux systems, you call LinuxCreateWindow(). On MacOS you call MacCreateWindow(). Each of these functions produce different results, have different parameters, and in general require a different setup. What GLUT does is handle all this creation for you by generalizing it. Instead of the OS-specific CreateWindow() functions, you call something like GLUTCreateWindow(), and it creates your window, regardless of the operating system. Take this, add in at least 1000 more GLUTSomething() functions that handle other things you might need when using OpenGL, and you have GLUT.
In addition, there are/were some helper functions in GLUT that offered you a simple way of creating common geometric shapes, such as cubes, pyramids, and some other stuff. You can do this in OpenGL, but it takes slightly more work than calling a function.
As for what OpenGL is, it's an API that sits right above the graphics hardware. It provides an abstraction so you can use glDrawArrays() instead of NvidiaGTX470DrawArrays(), NvidiaGTS250DrawArrays(), etc. Again, this is a bit of a simplification, but that's the general description of what OpenGL does for you. It's written in C and comes in via your operating system or graphics driver.
OS X has had VAOs as a custom extension for a long time, you don't need 3.2. Use the following:
glGenVertexArraysAPPLE glBindVertexArrayAPPLE glDeleteVertexArraysAPPLE
GLEW doesn't seem to bind these so I just put this at the beginning of files where I use them:
#ifdef APPLE #undef glGenVertexArrays #undef glBindVertexArray #undef glDeleteVertexArrays #define glGenVertexArrays glGenVertexArraysAPPLE #define glBindVertexArray glBindVertexArrayAPPLE #define glDeleteVertexArrays glDeleteVertexArraysAPPLE #endif /* APPLE */
EDIT: Also, none of the places I read about VAOs really explained them well until I found it on the OpenGL Wiki. It has a very in depth explanation of what state is stored, etc. If you're still using fixed function you can even use glVertexPointer glNormalPointer and glColorPointer to bind those attributes from your VBO. In fact I do this most of the time on Macs since modern OpenGL support is still so flaky.
> Translucent glass, dynamic torches, and flying machines are all examples of performance limiting features.
Yes, but they are not limited by Java.
Transluent glass is difficult because you have to draw all opaque blocks first, then sort all transluent vertices and draw them in back-to-front order. Read the OpenGL FAQ.
I don't know much about how chunks are loaded and light is updated in Minecraft, but while Java might have some effect on the performance, I think it mostly comes down to the amount of IO that has to be performed. Reading huge chunks of data is slow. Using C++ won't change that.
It's a shame that the GL_EXT_direct_state_access extension hasn't seen wider adoption beyond some nVidia drivers on Windows. It goes a long way toward modernizing the OpenGL API.
Shaders are, generally, independent of where all their input comes from. Their input just has to be structured and set up in a way that makes sense when the shader uses it (the right index and type for each shader input). This idea holds for pretty much everything a shader uses: vertices, textures, uniforms, linking between vertex and fragment shaders, etc.
However, note that in general usage with recent OpenGL versions, you'll create a Vertex Array Object and call glVertexAttribPointer, which will tell whatever vertex shader is active where its "in" variables come from. Somewhat confusingly, glVertexAttribPointer binds a buffer location to a VAO, but after that the bound VBO is irrelevant. You can, in fact, have no VBO bound at all when you make a draw call, so long as the VAO has been set up correctly beforehand. In other words, binding a VBO only matters when you set up a VAO.
A good tutorial on these basics is here; that page includes complete sample code.
Also note that newer versions of OpenGL support the [layout](http://www.opengl.org/wiki/Layout_Qualifier_(GLSL%29) qualifier in GLSL, which allows more control over which indexes the shader gets its inputs from.
Even more confusingly, there are other ways of using VBOs/VAOs (for example, only using one VAO in your whole application, and changing it before each draw call), but my understanding is that what I described is the "standard" and recommended way of using modern OpenGL.
I only have GL 3.3 on my system, but I have the debug extensions GL_AMDX_debug_output and GL_AMD_debug_output. In my last project I integrated those instead of using glGetError. First I tried the AMD version GL_AMD_debug_output because of having that extension. Then I renamed the functions to see if the ARB version GL_ARB_debug_output worked and it did!
What did I do:
* setting the debug-flag for OpenGL via SDL_GL_SetAttribute(SDL_GL_CONTEXT_FLAGS, SDL_GL_CONTEXT_DEBUG_FLAG); What ever you use, somehow you need to create a debug-context instead of a normal one to use this extension.
* when you have set up your window and OpenGL and and your glew is init etc. just set the function that should be called via glDebugMessageCallbackARB(handleGLDebug, nullptr);
The function looks something like this:
void handleGLDebug( GLenum source, GLenum type, uint id, GLenum severity, GLsizei length, const GLchar* message, void* userParam){ // do some tuff }
After that, whenever some error or warning occurs, the function will be called.
No need for glGetError after every suspicious line of gl-code.
I guess it's not seen often because it is "new" as most tutorials are rather GL2. Might also be a lack of using error-handling. Even in older tutorials glGetError isn't seen that much.
Your code completely lacks any error catching. I think that would be the best place to start. Call glGetError after every GL function.
edit: change URL to non-ES. Also note that GL doesn't fatally error it just shrugs and pretends to be Marvin if you're not keeping an eye on it.
It depends on the format you use. If you are using uncompressed R8B8G8A8 (8 stands for 8 bits per channel) textures, then it is indeed 4 bytes * width * height
But there are compressed formats such as the DXT formats exposed through the EXT_texture_compression_s3tc extension.
On OpenGLES/mobile other texture compression exists depending on the graphics chip in your phone. For all iOS devices the compression is PVTRC
Along with compression, there are other texture formats you can use to be more efficient, such as 16 bit color textures, but texture compression normally gives the best visual quality vs size.
Textures are uploaded using glTexImage2d() or glCompressedTexImage2D(). In the event you are uploading a texture and there is not enough VRAM left, OpenGL with respond with a GL_OUT_OF_MEMORY when you call glGetError(). Many game engines will use a pooling system such that only textures needed to render the current frame or sometimes batch are required to be in VRAM.
>the glm matrix shoves the translation values into the last row, not the last column
Glm matrices are column-major which means the columns of the matrix are contiguous in memory and elements are accessed with subscript operators in the following fashion: (src)
matrix[col][row]
So the translation values are still placed in the last column. This is a very common misconception: column-major does not mean transposed. Think of it more like the difference between big and little-endian byte ordering.
> but the main cause is delayed positional detection
No, rotational. The DK1 doesn't track position, only rotation. And Oculus said they couldn't implement time warping well for positional tracking yet.
> You simply move the pictures a couple of pixels.
Moving the pictures by some pixels is not the way to do it. You need to reproject the undistorted image in 3D for the new orientation.
> However, I don't think the roll transformation need to be compensated for
I don't see how not taking roll into account would help. The reprojection is not costly in time or performance so there is really no reason to make it incorrect.
> In OpenGL, this is difficult, as you need to find the correct point in time to temporarily suspend your normal rendering
Not really for NVIDIA GPUs thanks to the NV_delay_before_swap OpenGL extension. I don't think a similar feature exists with DirectX/3D.
Also you can write a device driver hooked to the GPU IRQ to interrupt the scheduler just before the vertical retrace (just like stereo 3D drivers did) and do whatever you want then. You could probably even race the beam to modify the rendering while it's sent to the display.
In the Oculus SDK time warping is done with busy-looping on the CPU, so it shouldn't be more difficult to do in OpenGL than DirectX/3D.
Fwiw, I found the following comment at the OpenGL site:
> An implementation is only required to define core, so compatibility is not guaranteed to be available. However, it's a safe bet that it is (unless you're using Mac OSX 10.7, in which case 3.2 core or 2.1 are your only choices).
Your video is very cool! Your implementation is really dynamic, and the visual feedback ( to the user ) is great. I am happy the whitepaper was helpful.
So, in your pseudo code above, the real problem is in the following statement:
visibilityMapTexture[currpos.x, currpos.z].r = isVisible(currpos, height, lineOfSightPoint.pos);
You can't write to a sampler in a pixel shader. As others have noted, you can use the GL_ARB_shader_image_load_store extensions to get read/write access. That would definitely work.
If you want to implement support via FBO ( as illustrated in my example ), be aware that you can do full RGBA sampling. I just sampled stuff into a float for the purposes of my example code. So you can also do stuff like:
fragColor = vec4( float_expression, float_expression, float_expression, float_expression );
and
fragColor = vec4( vec3_expression, float_expression );
You can also use layout qualifiers for more control.
layout(location = 3, index = 1) out vec4 factor;
See: http://www.opengl.org/registry/doc/GLSLangSpec.4.40.pdf ( Search for: 4.4.2 Output Layout Qualifiers )
I think this is applicable to 3.3.
> Does that sound right?
yes. to save all that glVertexAttribPointer() calls ARB created VAO.
glVertexAttribPointer() read current GL_ARRAY_BUFFER binding and store it elsewhere. after you call glVertexAttribPointer() you can even call glBindBuffer(..., 0); that mean bind no buffer and it will still draw correctly. glVertexAttribPointer() set both data format and source of the data. it is just historical reasons that last parameter is used as offset to currently bounded GL_ARRAY_BUFFER.
http://www.opengl.org/sdk/docs/man4/html/glVertexAttribPointer.xhtml http://www.opengl.org/wiki/Vertex_Specification
> Now low-latency drivers and tweaks to APIs?
There is this one already which should help with time warping (John Carmack is listed as a contributor) : http://www.opengl.org/registry/specs/NV/wgl_delay_before_swap.txt
They did, but another one is definitely needed with all the new ways there are to create buffers for CPU<->GPU communication.
Today is the first time I've heard of OpenGL Loading Libraries - practically every tutorial I've seen up until now has used the compiler-provided OpenGL header files (usually terribly out of date) and wglGetProcAddress to grab a few select extension functions. That's not really an option with newer OpenGL versions as it leaves in all the removed functions.
Maybe Loading Libraries fix the awful headers problem... I'll have to look into them next time.
I am a programmer, and I have to disagree. It can be done using a color lookup table, which is rather easy to implement in OpenGL. I suspect it's similar in DirectX.
Because it can be done in shaders efficiently it should not be a performance hog.
Yeah, doing that will stop the graphic card each frame while you read, but you need to do it eventually. However, using Framebuffer Objects, and double or triple buffering between them allows you to read the image from a buffer that's not being used without stopping anything. It's not an extension anymore, it's a pretty important part of OpenGL... except that in our sad and old GLES 1 world :P
good suggestion! I would also add some more links:
Modern OpenGL Usage: Using Vertex Buffer Objects Well, by Mark Kilgard,
and (@wiki Buffer Object)[http://www.opengl.org/wiki/Buffer_Object]
That's not true as of OpenGL 4.3.
With GL_SHADER_STORAGE_BUFFER there is more or less no limit.
As everyone has pointed out, CUDA is Nvidia only. OpenCL is poorly supported by Nvidia, and while it can be used, the performance is roughly 1/4 of OpenGL according to my tests, although that result could be a consequence of the OpenGL-OpenCL buffer sharing, however Nvidia's OpenCL also does not support 3D texture writes, preventing me from writing a pure OpenCL renderer and confirming that.
OpenGL 4.3 also adds compute shaders, so there's really nothing OpenCL can do that OpenGL can not (excluding all that "works on things other than GPU's").
IMHO, the benefit of using CUDA or OpenCL really comes about when you are using more than one GPU.
Now I feel spoiled by the OpenGL quick reference the few I opened don't do well in comparison and the css one has to be a joke.
Becasue you installeddrivers from CD/Nvidia website, some other people didn't (since Windows Vista/7/8 has some 3D hardware support OOTB).
GPU_MAX_ALLOC_PERCENT sets how much of the GPU memory you're allowed to allocate in one call. Default is 50%, but most cgminer settings use more than that - it really depends on how much memory there is on your GPU.
GPU_USE_SYNC_OBJECTS tells the AMD drivers to enable OpenCL/OpenGL object syncronization.
I believe it depends on the platform, and is set when you create your OpenGL context. What platform are you developing for, and how are you creating your context?
EDIT: Here you go:
http://www.opengl.org/registry/specs/ARB/multisample.txt Mentions wglChoosePixelFormatEXT (Windows context initialization) and glXChooseVisual (X11 linux, unix, OSX in special cases).
If you're using SDL it's pretty simple: http://sdl.beuc.net/sdl.wiki/SDL_GLattr an example of using it is here: http://www.sdltutorials.com/sdl-opengl-tutorial-basics
Hope that helps.
So there's a common confusion about renderbuffers vs framebuffers. Framebuffers don't actually contain any pixel data themselves. (I can't stress this point enough) Renderbuffers and textures contain pixel data, and you can attach these two things to framebuffers, so that when you draw into a framebuffer, the resulting pixel data ends up in the renderbuffers or textures you attached. Likewise, calling ReadPixels reads back data from the renderbuffer/texture at the attachment point in the current framebuffer indicated by the |format| argument.
Just bind the framebuffer that has the renderbuffer (which you want to read from) attached as the stencil attachment, and call glReadPixels with a format of GL_STENCIL_INDEX or GL_DEPTH_COMPONENT.
See the docs for ReadPixels here.
A display list has a major disadvantage: once a display list is compiled, it cannot be modified later. If you need frequent changes or dynamic dataset, use Vertex Array or Vertex Buffer Object instead. A Vertex Buffer Object can handle both static and dynamic dataset.
glutInitDisplayMode(GLUT_RGBA | GLUT_DOUBLE | GL_DEPTH);
<code>glutInitDisplayMode()</code> doesn't accept GL_DEPTH as an argument. Try GLUT_DEPTH.
Ack, no! Just pass the pointer from glMapBufferARB() to your secondary thread to fill, then back to your primary for glUnmapBufferARB(). Double-buffering optional.
As far as i can remember there is implementation in GLSL of this somewhere in opengl.org forums.
Edit: Ah yes: clickey
First of all: OpenGL. Learn the industry standard way of doing things, which MS blatantly ignored in creating DirectX. OpenGL works with Windows, *nix, Mac, iPhone, PS3, Wii, (get the point?) To be fair though, if you want to develop for Xbox, you'll have to do it MS's way. No way around that unfortunately... and yes, I know many PS3 dev's don't even use the OpenGL wrappers, but the fact remains that they exist.
Anyway, I would suggest working with c++, Qt, and OpenGL if you're planning on writing cross-platform desktop games. Code written in Qt can be compiled, unchanged, for Windows, Linux, Mac, and a numer of mobile platforms, and the C++/OpenGL you learn can (as I hinted at before) be applied to nearly anything which has the capacity to run videogames.
Best of luck, welcome to the horrible/wonderful world of game development. you have no idea what you're getting into >:)
The extensions WGL_ARB_create_context_robustness and GL_ARB_robustness addresses this by introducing a new OpenGL context flag to create robust contexts. They sacrifice speed for security by making the OpenGL interface "uncrashable". That is, in the event an error happens, the result is deterministic, and you will at most lose your OpenGL context. New entrypoints for Get-functions were introduced that take explicit size parameters, and accessing buffers outside bounds are guaranteed to not crash the driver.
In Windows Vista and Windows 7, the graphics adapter is considered a shared resource, so Microsoft added a watchdog timer to the GPU. If a shader program runs for too long, the driver resets. I'm not certain, but I think GL_ARB_robustness makes this case reset the context instead of resetting the whole driver. Without the watchdog, denial-of-service attacks would be possible by forging a complex WebGL shader program which never ends.
So, there you have it. With support for these two extensions, it's possible for WebGL implementors to make guaranteed behavior for 'evil' code scenarios. Also, it's more or less impossible to do stuff like privilege escalation via a shader, because as you said, this runs on the GPU, not the CPU. If it was possible, too many things had to go wrong at once.
Well, there are open source libraries such as Ogre though I'd prefer (perhaps foolishly) to implement a basic 3D engine using SDL + OpenGL. Learning about an engine as advanced as Ogre is, to me, kind of intimidating. The first prototype of the game doesn't have to be particularly advanced and programming it from the ground up (though SDL does take care of a lot of low level stuff) would be useful in understanding how it all fits together I think.
Either way, the actual game related classes (simulation, game logic and such) would have to be build from scratch.
Octrees of cubes = no.
Octrees of chunks = maybe.
You probably would store chunks in a sparse 3d grid anyway, therefore you can access every chunk at any moment. Octree as a structure may exist virtually in that case. Just test large areas of chunks against frustum and then if it passes draw chunks from x0,y0,z0 to x1,y1,z1.
16^3 is small for chunks, modern CPUs can easily handle 32^3. And that alone will make your draw call count 8 times less.
Sadly I don't know how unity works, but in OpenGL there are many fancy ways to eliminate draw calls almost completely. In OpenGL 4.2 you can do that 100%, to batch all the chunks together you'll have to generate or upload their relative positions into a shader and use ARB_base_instance to connect batched meshes with its position. In earlier versions you can end up generating a mesh once and uploading it with index/vertex position shift. It's still faster than generating the mesh from scratch. That way you can batch multiple chunks together as well. I do the second, with exception that I actually generate everything from scratch every time, leaving some space for future optimizations. Works quite fast. Given that I have a LODed terrain, LOD switches do not take more than 100ms. For more details: http://www.opengl.org/wiki/Vertex_Rendering. Sorry if it's useless for you, because of unity usage.
However if you can keep the draw call count for map under 1000, I think it'll work without any further optimizations just fine.
I use flat arrays as well, they are quicker than octrees though more memory hungry. That can be mitigated with compression however.
You seem to be doing most things right. However I noticed you are using 3 separate VBOs for normals, positions, and texcoords. Instead you should use interleaved vertex data and store it in a single VBO.
You are right that dynamic allocations can slow it down. Instead of using a vector and push back, I use an array that is large enough to store all possible combinations of vertices. Then I just index into that array and reuse it. So you never have to do any dynamic allocations, and you dont have to make the calls to push_back(), which is more expensive than a simple array assignment.
Linked lists are bad, you are right for not using them :)
I think a main reason your meshing is slow is because you are generating a collision shape from your geometry. If your voxels are cubes, you dont actually need to generate a complex collision shape since each voxel has an implicit bounding box. However if you are doing this to work with a physics engine then it may be the only way.
You should definitely do some benchmarking. Use a precise timer to time the different parts of your meshing algorithm to see what parts are slow. My guess is that the physics collision shape generation is the issue, perhaps you can figure out how to get rid of that or optimize its creation? Or perhaps you can create the collision shape in a separate pass after you remesh the chunk, so that the chunk mesh appears instantly but the collision shape updates a frame or two later?
Look into the primitives offered by OpenGL:
http://www.opengl.org/wiki/Primitive
Any geometry you want to render has to be represented using those primitives. So you could produce a wireframe by using line strips. The set of points where x = x1 is a line strip, the set of points where x = x2 is another line strip, and so on until x = xn. Then do the same with y held constant at each value on its domain (not a very good explanation, but hopefully you get the gist of it). A surface would have to be represented using triangles - more difficult than wireframes, but there are books like Real-Time Rendering that discuss techniques for subdividing surfaces. If you aren't adamant about implementing that yourself, I'm sure you could find free libraries that can do this for you.
The actual tessellator is fixed function and is just sandwiched between the control and evaluation stages. From http://www.opengl.org/wiki/Tessellation,
"The primitive generation part of the tessellation stage is completely blind to the actual vertex coordinates and other patch data."
The section "Abstract Patch" ( on the same page ) has more information on the process, in particular stating "the primitive generator evaluates a different number of tessellation levels and applies different tessellation algorithms".
To me this says you get what you get. Obviously you have some configuration options and "capability to suggest" in the control shader, but it doesn't look like you're going to be able to get the results shown in your image regardless of how you configure the tessellation values.
As I'm sure you're aware, you can do a lot to the data inside the evaluation shader, but I gather you didn't want to do this manually. I certainly wouldn't want to do it manually either, but I don't think you have much choice in this case.
At first glance, and I haven't had much time to consider this problem, it seems like ( at least for this case ) you'd be better off doing the tessellation in the geometry shader, although I know you're currently using it to do other things ( and of course, I would want to use the tessellation feature to do this were I writing it myself ).
> is the only way to manage time/seeding externally?
Basically, yes. You use shader constants to manage external state (like seeding information) that you want to update from C++/C#.
GL: http://www.opengl.org/wiki/Uniform_(GLSL)
DX11: http://msdn.microsoft.com/en-us/library/windows/desktop/bb509581(v=vs.85).aspx
There are some ways to do it almost entirely on the GPU, by setting up some compute/render to texture that then affects later frames, but generally that's going to be more trouble than it's worth.
3.0 may have dropped the whole Longs Peak templated-immutable-objects thing it was going to have, but we did get this a few minor versions down the road:
http://www.opengl.org/wiki/Core_And_Compatibility_in_Contexts
Oddly enough this is a feature in OpenGL and DirectX 11.2 (tiled resources). We should be seeing it used in games especially XBox One games in a few years. (Actual driver implementations).
You are probably aware, but it is entirely possible for the z buffer test to occur before the fragment shader has been executed, which is desirable for speed. http://www.opengl.org/wiki/Early_Depth_Test
> this seems a lot better than playing chicken with late-frame rendering and risking missing deadlines
You can use the NV_delay_before_swap GL extension to be sure to not miss the deadline. Or do it during the scanout of the framebuffer on the CPU.
> You can still implement low persistence by dynamically adjusting the illumination time. Is there any reason this scheme wouldn't work?
Flickering at lower framerates (< 85 Hz). We'll soon be able to see if the 75/76Hz of the DK2 is enough in this regard.
I'm interested to hear people saying "OpenGL is easier on Windows." One of the reasons why I'm writing my code to support OpenGL is that I was planning to port to Linux at some point. I have an Ubuntu box at work that I use for various things, and I've played with a couple other distros, so I'm fairly competent with Linux.
I looked here for more information and it says (dauntingly enough) "Linux comes with Mesa libraries, which implements the OpenGL API as a software rasterizer. Most Linux distros don't come with hardware acceleration." But then I clicked a few links to find this, which says "For most modern Linux distros (Ubuntu, Debian etc), proprietary drivers for other common graphics hardware (NVidia, ATI etc) should be available through the standard package-management system." So that seems acceptable, I think supporting the more modern user-friendly Linux distros is acceptable.
When you're dealing with Linux, it's kind of implied that the people using it are going to be tech-savvy enough to have a hardware-accelerated driver installed. So is that the major difficulty? Aside from wrangling the extensions, apparently through "GLX" (X Windows interface to OpenGL)?
Time warping can also be implemented without interpolation and without concurrent threads, using the simple and standard double-buffer rendering technique.
You would render your scene as usual, then use the NV_delay_before_swap extension to have some time just before v-sync (~2ms) to reproject then scene based on a more recent reading of the sensor. If you have a look at the details of the extension you'll see John Carmack as one of the contributors.
Another technique would be to do the reprojection on the CPU by "racing the beam", John Carmack confirmed he was working on this recently. There could be some gain :
- full GPU performance (13ms for rendering instead of 11ms + 2ms for reprojection)
- less latency (~2ms) if the reprojection can be done during the scanout
Problem is it's NVIDIA and OpenGL only for the GPU version at the moment, but if there is some benefit I guess AMD will bring their own implementation. The CPU version should (obviously) work on any GPU, but I don't see how to implement it without a driver grabbing the scheduler exactly at v-sync.
> There's no drivers to specifically benefit VR right now
There is an OpenGL extension made by NVIDIA for which John Carmack was a contributor which should allow time warping to be implemented on the GPU :
- GLX_NV_delay_before_swap for Linux
- WGL_NV_delay_before_swap for Windows
I don't know much about Wayland and have a few questions:
Is it possible for the Wayland server to give the application a bigger buffer and tell it to scale the draw operations accordingly before rasterizing so that the rotation/scaling/distortion step inside the server gives a higher quality result?
Is it possible for the Wayland server to tell the application what surface the resulting texture should be projected on so that the application can do the inverse operation first?
Can the Wayland server give the application a vertex/fragment shader that it needs to append to its own shader pipeline?
Can the Wayland server issue the actual draw calls if they were supplied by the application instead of the rendered texture?
E.g. with ARB_multi_draw_indirect
The server would then inject its own translation+rotation+scaling+distortion shader and render the whole screen in one go.
What would be the easiest way to change Wayland's protocol or API so that this problem can be solved or worked around? (not meant in a technical way but rather politically) Who needs to be convinced? What are the steps to get a new feature like your Cairo idea or the stuff I wrote above into the specification?
From what I've read about Wayland the general idea is to push as much complexity as possible from the server into the application while giving it as little information about the rest of the compositor and other windows as possible. So adding a Cairo renderer into the server will probably not be a welcome suggestion. (But I probably don't know enough about Wayland and Cairo to judge that.)
A viewport is a rectangle openGL draws things into, can be its own window or a embedded area in an application. with the glViewportArray we can give the gpu a list of viewports so we can draw on all of them with one drawcall and write shaders that control what is shown on each
man page is found at http://www.opengl.org/sdk/docs/man4/xhtml/glViewportArray.xml
Opengl is comprised of extensions. In layman's terms imagine them as individual parts of opengl. Some are for debugging, some are for tessellation ( like http://www.opengl.org/registry/specs/ARB/tessellation_shader.txt ), ect. An opengl version is made of new extensions + all the extensions from previous versions, to support 3.2 you must be supporting 3.1 and then add support for the newly released extensions; as that's all a new opengl version is, along with maybe some changes to GLSL. So an opengl 4.4 system automatically support all previous version of opengl. As new extensions are released they may provide better ways to do things then the old ones. Some of the old ones are deprecated, meaning they will still work but wont get future work on them and that you shouldn't use them in any new project, as something better is available. They're only kept to keep old software working. Now the "official" extensions are standard and must be present in a driver for it to be listed as opengl compatible, but anyone can make an opengl extension that isn't part of the standard and put in their driver. Like Nvidia or AMD specific extensions. These could be submitted to become standard in future versions.
http://www.opengl.org/archives/resources/features/OGLextensions/
you can use http://www.opengl.org/registry/specs/EXT/direct_state_access.txt if you really hate binding stuff. Then it could be rewritten as something like:
glGenTextures(1, &texture_id); // by the way if you like you can generate your own IDs glNamedTexParameterf(texture_id, GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); glNamedTexParameterf(texture_id, GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); glNamedTexEnvf(texture_id, GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE); glTextureImage2D(texture_id, GL_TEXTURE_2D, 0, GL_RGB, pixmap_height, pixmap_height, 0, GL_RGBA, GL_UNSIGNED_BYTE, (void*)(&(xim->data[0])));
putting the object as first parameter, it's almost like putting stuff into objects
in pseudo code:
draw 3D scene setup projection and/or modelmatrices for drawing in 2D or infront of camera.
glEnable(GL_BLEND); glBlendFunc(GL_ONE, GL_ONE); // additive blending float blendFactor = ...interpolate blendFactor from 1 to 0 glColor3f( blendFactor ,0,0); // when blendFactor = 0, the quad won't be visible. When blendFactor=1, the scene will be bathed in redness draw_fullscreen_quad();
All the possible arguments you can use with blendFunc. glBlendFunc
Use a timer or some timefunction to "animate" (interpolate) blendFactor from 0 to 1 or 1 to 0.
Edit: Forgot blending over time.
I have the fourth edition of the Super Bible. Good book, but fixed-pipline really doesn't help anymore.
Thanks for replying! I guess the best bet is to read whatever modern OpenGL documentation one can get, and scrounge for the rest.
What's not to understand about us people? If you saw some guy coming in here asking for some OpenGL binding for assembler wouldn't you ask him why and if he told you he thinks that's what's modern - wouldn't you gently point out to him that newer methods exists?
This way people don't have to waste their time learning something outdated.
And to answer your initial question as to where the NeHe tutorials don't comply to the latest OpenGL specification we can look at the first NeHe tutorial with code in it HERE and then read THIS. I now hope you will think twice before recommending NeHe again - if there are issues this early in the tutorial how outdated do you think the rest of the tutorials are...?
It's more the workstation GPUs are better optimised for these programs, so even though raw power might not be that different their difference in speeds within these programs (not for games mind you) is huge.
It's suspected that nVidia actually cripple their consumer GPUs via drivers to make their Quadro cards more appealing though
As a long time OpenGL user and driver engineer, I would not recommend this course of action for using extensions. I'd go with what 'burito' recommended, as far as loading all of your extensions separately in a different function, as opposed to inline with your usage of the extensions.
I would also recommend GLEW, but I also understand the desire to not use another external library (even though the cost is fairly trivial, GLEW is pretty lightweight).
Here are some OpenGL Wiki resources: http://www.opengl.org/wiki/Load_OpenGL_Functions http://www.opengl.org/wiki/OpenGL_Loading_Library
A couple comments to questions I saw scattered around the comments:
*Why load all at once? Platform specific calls tend to be slow, such as wglGetProcAddress. Platform specific calls go to an OS library, which in windows, is opengl32.dll. It then loads the vendor's OGL ICD, and most OGL calls get routed there. But the platform calls still go to the OS lib, which flushes a ton, which is bad for performance.
*Why is the extension name separate from the function? Because the function isn't the only part of an extension. Check out the FBO extension for example: http://www.opengl.org/registry/specs/ARB/framebuffer_object.txt
It has one extension name, but multiple new functions and multiple new tokens. So you check for one extension, and then you KNOW you have a ton of extra functionality.
This is the drawing mode used when calling glDrawArrays(), "7" is GL_QUADS which Minecraft uses by default.
If the value is changed to something else, like GL_TRIANGLES or GL_QUAD_STRIP, then OpenGL will try to interpret the quad data as triangles or quad strips and funny things will happen.
Here is more info: glDrawArrays
There is just as much variation in how floating point math works on different architectures, and not every CPU even has an FPU yet floating point math is still in the spec. There is a common subset of vector math that works on most every CPU that could be included in the spec, you don't need to have everything. For example the native floating point numbers on x87 are larger than what the C spec defines but nobody has had a problem with that for the last 30 years. As for the different sizes the GLSL types already handles many of them.
The reason why I want at least a subset of vector math in the language is because right now hardly anyone uses it. It's too hard to fool around with architecture and compiler specific intrinsics most of the time. So unless some one is writing a 3d game or a program that does heavy math they end up never using this hardware. If vector math was built into the language people would use it all over then place.
I'm sad that OpenGL has such crappy documentation. I should not have to dig through spec sheets to figure out how the api works. It also seems that after 3.x everyone who was making tutorials online basically gave up on it and there seems to be very few internet resources for modern OpenGL and even fewer books.
If what I have run into is any indication of the quality of the OpenGL wiki then I would suggest avoiding it.
For instance there is this page on how to create your own context here
It's been a while since I was messing around so some of this may be inaccurate.
The first thing is that glew had not been updated to work with 3.x so if you attempted to create a core profile using that code the context creation code would fail and you would end up with a lesser version context or glew would crash your program or something I don't remember. If glew has been updated then this would no longer be an issue.
The other issue here is initializing glew and then using it to make a new context. The problem if i recall correctly is that the OpenGL spec says if you get pointers to extensions on a context and then delete it your extensions are no longer valid. Of course now that I'm posting this I can't find where it says that anymore hah. So basically what this code does is create a context, initialize all the extensions, use those extensions to create a new context, delete the context, and then continue using function pointers that are no longer valid on the new context. This actually works, but as far as I can tell is not guaranteed to work and could fail at the whims of the driver.
So yeah either I am a total noob (which could actually be the case) or there are some pretty bad quality control issues on the OpenGL wiki.
Section 21.130 of the OpenGl Texture Mapping FAQ seems to imply that larger texture sizes may not necessarily be hardware accelerated -- I don't know if this is a problem in practice.
The same section is also useful for querying the maximum texture size that a graphics card will support, using a texture proxy.
Also remember to normalize your normals!
<edit> Clarification: lighting is supposed to work with normals having a magnitude of 1.0, if you are scaling your models then double-check your normals are normalized since the lighting equations assume that normals have a length of 1.0. See this document for more information on this subject.
<http://www.opengl.org/documentation/books/>
OpenGL SuperBible in particular is quite good.
Online tutorials are pretty much worthless. The API documentation is a useful reference, but certainly not concise enough for anything else.
> Rendering tons of translucent blocks is probably demanding no matter what language you code it in.
Indeed. From the OpenGL FAQ:
> When using depth buffering in an application, you need to be careful about the order in which you render primitives. Fully opaque primitives need to be rendered first, followed by partially opaque primitives in back-to-front order. If you don't render primitives in this order, the primitives, which would otherwise be visible through a partially opaque primitive, might lose the depth test entirely.
Mirrors are hard to pull off convincingly in 3D. If you want them to realistically reflect the world, it would require rendering the scene again from each mirror's POV. God help you if you want to reflect other mirrors, then it get's really ugly.
Most mirrors in games are blurry, small, and placed so that they reflect as little as possible. Often times they aren't mirrors at all, but windows looking into a backwards room.
(You can ignore the technical stuff on that page and just look at the pictures to see what I'm talking about.)
You are definitely going to be the rate limiter learning anything so no tutorial or book is going to be much faster than the next. If you understand all of the core concepts of shading languages, then I'd say you should pick up a reference book:
http://www.amazon.com/OpenGL-Shading-Language-Randi-Rost/dp/0321637631/ref=pd_sim_b_1
Or go straight to the reference documentation here:
http://www.opengl.org/documentation/glsl/
If you don't know OpenGL that well and need a more comprehensive graphics programming start I'd strongly recommend this book:
You have the C reference there. You don't need more than that to learn to program. I knew I needed to learn C/C++ so I did, I self taught from Stroustrup. I then realised I needed to learn OpenGL so I picked up the red book(free to download) and the OpenGL super bible (eugh!) and I did. I learnt DirectX from the MSDN library. I picked up books by Alan Watt on 3D computer graphics and when I got to uni I got access to the Sigraph papers (and I still miss those) and I learnt everything ever written, ever, by any mathematians or graphics guru for I am a god.
What I'm saying is learning to program is fairly straight forward, all you need to do is go to book shop (or google) and find the best resource on that subject (usually the person who invented it, like Stroustup). Learning isn't rocket science, the difficult bit is using what you've learnt.
tldr; I'm fucking amazing and it's not night time my ego is just blocking the sun. sploosh.
To quote u/jonba2 from an old thread
"There's a lot of good responses here, but I figured I'd add in one more tidbit. Minecraft runs on top of the Lightweight Java Game Library which in turn uses OpenGL for 3D graphics.
The assignment of axes to directions is arbitrary, but the convention in OpenGL is +X goes right, +Y goes up, and +Z goes behind you. Keeping with this convention allows you to:
- Avoid confusing when talking with other graphics programmers because they're used to it too
- Easily use code that other programmers have written"
Hmm, damn. Actually... seeing as I'm really only interested in trying old-ish games, I wonder if it would be worthwhile trying to use GLIntercept to add OpenGL support to Vireio / make my own open (freely available) source thing?
Orrr... if you're feeling really crazy, wrap OpenGL into DirectX 9 then use Vireio... layers of interception are the new black, right?
Is it explicitly worded such that you may not write any shaders ? According to the Redbook, vertex- and fragment shaders a the minimun in ogl >3.0. Maybe you may write shaders that only assign the gl_Position from a buffer. Then, all you need to do is manually apply the perspective to the vertex buffer. But that doesn't seem to have any didactic value... Can you please post the solution once you found out ?
Edit: According to 2.11 OpenGL spec > If there is no active program for the vertex or fragment shader stages, the results of vertex and/or fragment processing will be undefined
Not sure why I got downvoted. The 105M default driver doesn't support OlenGL 3.0, but updating the driver adds 3.0 support. See here: http://www.opengl.org/discussion_boards/showthread.php/168440-Which-netbook-cards-support-OpenGL-3-2
GL_MAX_TEXTURE_BUFFER_SIZE doesn't definitively indicate how large of textures your card might support. Use GL_PROXY_TEXTURE_2D or similar to get a definitive answer. For more information, see http://www.opengl.org/archives/resources/faq/technical/texture.htm
Also in the OpenGL Common Mistakes - Triple buffering it's said :
"You cannot control whether a driver does triple buffering. You could try to implement it yourself using a FBO. But if the driver is already doing triple buffering, your code will only turn it into quadruple buffering. Which is usually overkill."
So basically you can't even implement triple buffering in OpenGL, you need to rely on the capability of the GPU driver.
Not that it should help much anyway. From Real-Time Rendering, Third Edition :
"The drawback of triple buffering is that the latency increases up to one entire frame."
Well as of OpenGL 3.0 using doubles simply isn't recommended (my personal GPU supports them, hence why I use them for personal projects). Source.
You should probably use a library for Java which provides OpenGL bindings as this is a time consuming task especially for someone who is not familiar with OpenGL, if you still want to know how to do this you can read about it here.
Looking at google JOGL might be what you want to use to provide OpenGL bindings in Java.
Well, it goes down to semantics, really. In the end, that is because OpenGL is really a specification, not a program, so "OpenGL doesn't have any source code". My use of the term "open source" referred to the fact that it is an open specification, which can indeed be downloaded. Perhaps an abuse of semantics, then, and I apologize for any confusion it created. Thank you for pointing out the fault in my argument, though.
The differences between 4.0 and 4.3 are pretty minor from a new learning perspective: http://www.opengl.org/wiki/History_of_OpenGL#OpenGL_4.3_.282012.29 http://www.opengl.org/wiki/History_of_OpenGL#OpenGL_4.2_.282011.29 http://www.opengl.org/wiki/History_of_OpenGL#OpenGL_4.1_.282010.29
What hardware and driver do you have on your computer?
To address some common criticism of all modern OpenGL books:
I haven't read the Red Book 8th edition, but I helped on the most recent SuperBible editions, and I think they do a relatively good job of presenting the material for learning modern OpenGL.
The trouble is, anyone who is teaching legacy-free OGL has to throw you into the VERY deep end in order to anything at all.
One criticism of the SuperBible is that it uses a (provided) utility library to cover over some of the ugliness of doing legacy-free OGL on multiple platforms. Some people feel this utility library is a crutch and "hides" the way "real programmers" do things. However, the opposite criticism is also true -- many books punch you in the face repeatedly with ugly boilerplate code that has little to do with the lesson you're actually trying to learn.
Basically, you need to either abstract/hide some stuff (like glu and GLUT were used for in the past) or you will injure yourself on all the sharp pokey bits (matrix classes, VBOs, shader loaders) that make it heard to focus on learning the lesson at hand. Neither approach is perfect. I think the SuperBible does a decent job of teaching what you need to learn and abstracting the parts you don't need to focus on at the moment.
I'd be curious to hear an opinion from someone who has used and learned from the latest Red Book about how (and how well) it handles this thorny problem.
Yes, it gets a bit confusing, especially because some people use "shader" and "shader program" interchangeably. What I like to stick to is to always call the separate pieces of GLSL you write "shaders", as in "this is the vertex shader, and that the fragment shader", and only the final, linked product that actually runs on the GPU "program". It also fits the OpenGL API naming, where you glCreateShader shaders, compile them, and lastly link them into a glCreateProgram'd program.
Alas, further down the road, things will get even more complicated, because ARB_separate_shader_objects allows you to mix and match different shaders without having to explicitly link the combination into a distinct program before. As such, new vocabulary was born such as "program pipeline" and "shader stage". So be prepared for that :D
My suggestion is to look at the vertex and fragment shader first. These are the only two required ones to draw something with "modern" (but not that modern anymore) OpenGL. From there you could delve into the others.
These are also in my opinion the most interesting shaders, the fragment shader especially.
I think it is explained very well with the block diagrams you can see here: http://www.opengl.org/sdk/docs/reference_card/opengl44-quick-reference-card.pdf
But basically these shaders are different stages in the rendering pipeline that occur in a certain defined order. So the vertex shader is always run before the fragment shader for instance.
Feel free to ask some detailed questions and I could elaborate a bit.
I think you have the first parameter wrong in your VertexPointer and ColorPointer calls: http://www.opengl.org/sdk/docs/man2/xhtml/glVertexPointer.xml
The first parameter should be the number of elements per vertex, not the total number of vertices.
I don't think you got what he meant about glTexImage. It is a problem that, until recently, has also plagued buffer objects: With glTexImage, the driver has to prepare for the texture allocation to completely change at any point in time. This results in overhead in the driver even though 99% of people never reallocate texture storage after the first time.
This problem was finally solved with GL_ARB_texture_storage (core in 4.2), which allows you to allocate the backing storage of a texture once, and have any other kind of reallocation result in errors. The texture is now immutable, and as such, the driver can heavily optimize its usage (eg. no more state consistency checks before each draw). The buffer object equivalent to this is GL_ARB_buffer_storage (core in 4.4!), where with immutable buffers, you can finally have buffers mapped into client memory space indefinitely and even live update them with new data as they're being used without forcing implicit synchronization by the driver (instead, you have to ensure safety yourself via sync fences, so you don't overwrite data currently being read by the GPU).