You rotate the skybox in the opposite direction than you're looking. If you look down, so your pitch goes down, the skybox should rotate up. Note: You do not translate the skybox, it moves with you.

You don't see corners on a skybox. When you render a skybox, you turn off lighting, you also clamp the edges of the skybox textures so there is no gap or lines where the sides meet (like any model really).

My City3D program I linked before this uses a simple skybox I made with old opengl code. Just a textured cube. Only I reverse the winding. OpenGL uses counter clockwise winding for it's polygons, so for a skybox I switch it to clockwise winding so the front face is on the inside of each side (using the old method of OpenGL anyhow). Then I disable lighting so there are no shadows on the skybox textures and render it. I have a function I use I can probably post here that I used in the past (though there are newer ways to do them now, I haven't studied it yet).

Important, this uses older, depreciated OpenGL, but it still works. At the very least, it gives an idea on how to do it which can be converted to modern OpenGL, something I plan to do. Also, in this function, it uses a global variable which contains the IDs for the various skybox textures that are loaded elsewhere.

Edit: And this is some code I use to draw and rotate the skybox in my City3D program...

Edit2: Oh, and each side of the skybox should be a 90 degree FOV texture for it to work properly. 90x4 sides = 360 degrees, plus the top and bottom sides.

Edit3: All this talk about skyboxes, made me add a modern OpenGL Skybox to my space scene, this is what I have now.

{"name":"611216","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/4\/54a1053d5d16fcc5fcabc282328a5827.jpg","w":1280,"h":720,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/4\/54a1053d5d16fcc5fcabc282328a5827"}

I want to add in proper lighting and a new planet texture next. I also thought it would be kewl to add in a couple, random, derilect ships floating around from Star Trek, Star Wars, Apollo etc.

Edit4: Created a short video clip of my project so far with music.

I was following the Learn OpenGL tutorials and got the model and information on how to do modern Skyboxes from him. Though I understood how they work, I just didn't understand modern techniques, which have improved. Also see his section on instancing which is where I learned this. He has a link to this asteroid model, though you can use any model you wish once you get the model loading code down pat. A direct link to it is here (from his website)...

https://learnopengl.com/Advanced-OpenGL/data/models/rock.rar

If you had a normal field of view, they absolutely would be distorted. But when you create a skybox, you render each view with a 90 degree field of view (as opposed to your normal 45-60 degree FOV most games use). You have four sides plus the top and bottom. In order to get a perfect 360 degree panaramic view, you need to have each of the four sides (plus top and bottom) be 360/4=90 degrees. So once you combine them all, you get what appears to be a panaramic, perfect 360 view you can look around and no corners. The 90 degree FOV textures actually look a little distorted until you put them on the inside of a cube for the skybox.

Now if you JUST make a cube with the 90 degree FOV textures, you will see the corners. You need to turn off lighting which will shade the sides and show shadows in the corners and just light the entire texture evenly by setting a colour as I did as pure white to light up the entire texture. You also turn off things like fog etc when you render the skybox. You clamp the edges (see my previous older code which contains code for clamping that is still valid), what that does is it ensure the texture goes all the way to the edge so no seams are visible between textures.

What you see when you see a corner is shadowing, lighting etc... plus if your textures are views which are less than 90 degree FOV, than you notice it. Think about it, if you try and fit a 45 degree FOV image onto a side which is a 90 degree FOV, you will get distortion unless the view was 90 degrees ahead of time.

Also, check out the Java tutorial Chris posted above, it explains modern skyboxes very nicely. Even though it is Java, it translates over to C/C++ easily. But the concepts are the same.

Learn OpenGL does a great job explaining this and even provides code if you get stuck. This is the modern method which is more involved, but well worth it.

https://learnopengl.com/Advanced-OpenGL/Cubemaps

If you followed along with these tutorials, I basically just needed to insert this code (though I had to alter some of it as he had errors in it, easy fix)...

I of course created my own space skybox textures and re-organized their loading order as his was flawed. See his tutorials for other functions mentioned here.

Now for drawing the skybox, he had some great optimizations. Normally, using the old OPenGL (see my code again above) you would disable depth testing and draw the skybox first (back to front). But in this newer code, you actually leave depth testing on and draw the skybox last, which one might think would overwrite the foreground objects, but what you do is adjust settings for the depth testing so that it only draws the parts of the skybox that are visible without overwriting foreground objects. As a result, this makes it FASTER to render it as you can skip over entire fragments which are not visible. Kewl beans!

// draw skybox as last
    glDepthFunc(GL_LEQUAL);  // change depth function so depth test passes when values are equal to depth buffer's content
    skyboxShader.use();
    view = glm::mat4(glm::mat3(camera.GetViewMatrix())); // remove translation from the view matrix
    skyboxShader.setMat4("view", view);
    skyboxShader.setMat4("projection", projection);
    // skybox cube
    glBindVertexArray(skyboxVAO);
    glActiveTexture(GL_TEXTURE0);
    glBindTexture(GL_TEXTURE_CUBE_MAP, cubemapTexture);
    glDrawArrays(GL_TRIANGLES, 0, 36);
    glBindVertexArray(0);
    glDepthFunc(GL_LESS); // set depth function back to default

There are separate shader programs you use for the asteroids. The fragment shaders (which are loaded and compiled when you run the game then sent to the video card).

Fragment shader for asteroids...

#version 330 core
out vec4 FragColor;

in vec2 TexCoords;

uniform sampler2D texture_diffuse1;

void main()
{
    FragColor = texture(texture_diffuse1, TexCoords);
}

Vertex shader for asteroids...

It really is well worth just following along those tutorials, in order and you will understand all of this. They're very well explained, probably the best on the net that I have seen.

Okay, I created a trimmed down version with just a skybox and nothing else, in part to make it easier to follow and also to cut down on the filesize. I also copied the needed libs and includes etc... into one folder and then adjusted the solution properties so it will compile right out of the folder it is all zipped in.

This just has a skybox, nothing else. But all the libs and includes that are needed to do most of the Learn OpenGL tutorials are included so all you would need to do in order to do more is just add in the appropriate code, shaders and resources, which are all easily available from those tutorials.

This may help anyhow. The skybox textures are the ones the tutorial author used (except he had the front and back textures mixed up), it should make it easier to understand which direction you're looking. It was created using Terragen, you can make your own, just set the field of view to 90 degrees for each compass direction as well as up and down.

This is a Visual Studio 2017 solution by the way, I don't know how it will compile with older versions.

https://www.dropbox.com/s/8apyjnph5nnqeue/Moden%20OpenGL%20-%20Skybox.7z?dl=0

I posted more than enough tutorials to answer the question.

Well, this post, which I started, is all about modern opengl. If you don't want to use shaders, than you won't be doing modern opengl. I felt the same as you at one time, but if you follow the tutorials you will learn that shaders are awesome and actually a lot simpler than I thought.

The project I shared, you just need to compile it up, you don't need to know anything about GLFW, it will compile up for you as I already got everything put together for it.

I don't plan to use GLFW either, I can't stand it to be honest, but it is what those tutorials use and is, in the end, not important at all as it is just the framework which creates the window and opengl context, which you can just as easily do with anything else. I haven't done it with Allegro myself, so you're barking up the wrong tree here. I'll probably end up switching my entire project to another framework besides GLFW and I'll switch all the code to C from C++, but the important thing here is to learn modern opengl, everything else is depreciated.

I already posted OLDer code as well which shows the older, non-shader way to do it and there isn't any other way to explain skyboxes. It's just a 360 field of view, with four sides, each side is a texture, an image that was photographed or rendered with 90 degree field of view for each side totaling 360. Forget all the rest of your terminology and projections etc... it's a lot simpler than that. It's exactly what I just said. Just take four 90 degree views and paste them on the inside of a cube, plus the top and bottom view. THAT'S IT!!!

If you want an older game that did it, check out Myst 3, it used a cube/skybox for ALL of it's stuff. When you looked around, you were rotating a cube around you, each side animated in that case, but the same thing. PLus Chris already posted an excellent video on it (I watched it, and more myself, great find Chris!). There's nothing more to understand.

Old OpenGL and non-opengl: create a cube, paste textures on each side that are all created with a 90 degree FOV and you're done.

New OpenGL: Use a cubemap, which is basically the same, except newer opengl treats all 6 textures for it like one large texture and then uses a direction vector from the center and your view to determine which fragment to render.

If you do not like shaders, than you will never use modern OpenGL. Period. That is what they are all about, it's all done via shaders now, you write simple programs for the video card and tell it where to find your variables. It sounds more complicated than it actually is. I was VERY resistant to learning it, but I am glad I did as it is not hard at all and you can do some amazing things with them with very little effort.

I suggest you follow the tutorials using the software they use JUST to learn the OpenGL stuff, then you can get a full understanding of it and be better equipped to apply it to Allegro, perhaps make your own tutorial series once you do for the Allegro community.

There's nothing else I can say. I sat here working on making a self contained project you could easily open and compile right out of the box without setup and you didn't appreciate it one bit.

Edit: as for the asteroid program, if you didn't like the simple skybox program I packaged up, what would you possibly get out of the rest of a more complex program? The rest is just loading the planet and asteroid models and displaying them using similar techniques and there is no way in hell I will even try to explain them if you don't understand skyboxes which are about as simple as one can get. Again, FOLLOW THE TUTORIALS. These tutorials are, quite frankly, the best I have ever seen on modern opengl. They could have used Allegro, or SDL2 or whatever... and it wouldn't make a lick of difference with regard to opengl, the opengl code is STILL the same, and the methods are STILL the same. If it was Allegro, you would STILL BE USING THE SAME CODE, and you would be using SHADERS unless you want to use older, depreciated opengl, which still works and is even simpler and I already shared that code above (minus anything Allegro, which honestly, doesn't matter).

Exactly, they're awesome. I thought they would be more complicated, and once I learned them I was like... this is amazing! You basically write simple code on how to treat each fragment it renders, but you can do amazing things with them.

Heck, most of the shaders look like this...

Skybox vertex shader:
(vertex shaders operate on each vertex sent to it, it is the first stage on the video card)

#version 330 core
layout (location = 0) in vec3 aPos;

out vec3 TexCoords;

uniform mat4 projection;
uniform mat4 view;

void main()
{
    TexCoords = aPos;
    vec4 pos = projection * view * vec4(aPos, 1.0);
    gl_Position = pos.xyww;
}

Skybox fragment shader:
The vertex shader passes information to the fragment shader on the video card to process "fragments" or potential pixels, you can do things to each "pixel" (though technically, they are not pixels but for simplicity) creating special effects, anti-aliasing, you name it, quite amazing...

#version 330 core
out vec4 FragColor;

in vec3 TexCoords;

uniform samplerCube skybox;

void main()
{    
    FragColor = texture(skybox, TexCoords);
}

All modern OpenGL programs REQUIRE at LEAST a vertex shader and a fragment shader. There are other shader types as well, but these two are required. So, either you learn to use shaders, or you use depreciated opengl, fixed pipeline code or stick to 2D. And if this annoys you, don't even think about looking into a modern replacement for OpenGL called Vulcan, it's even worse (I won't bother with it myself).

Edit: Let me go over the vertex shader above and maybe I can make it more clear so you are not intimidated by them so much...

#version 330 core
^^ This tells the shader which version of opengl we are making it for, in this case, version 3.3. If you wanted to program some opengl 4.0 stuff, it would be #version 400 perhaps.

layout (location = 0) in vec3 aPos;
This tells the shader that we will be receiving a position vector, a 3D vector stored in the variable aPos, it will have X, Y and Z co-ordinates.

out vec3 TexCoords;
This tells our shader it will be outputting a 3D vector called TexCoords to the fragment shader we will make later, you will notice it takes this as an input in the example I posted above.

uniform mat4 projection;
uniform mat4 view;
Uniforms are like Global variables for shaders. This tells us we have two of them, a 4D projection matrice and a 4D view matrice.

Like C/C++, all shaders require a main() function...

void main()
{
    TexCoords = aPos;
    vec4 pos = projection * view * vec4(aPos, 1.0);
    gl_Position = pos.xyww;
}

...in this case, this main is simple, it applies the position vector we inputted to the TexCoords output vector and sends it along to the fragment shader, doing nothing with it. Remember, a vertex shader is required, even if it does nothing to this. This also takes a 4D vector pos variable and calculates the position of the skybox and sets it using a shader variable.

There's nothing much to it honestly. The fragment shader is similar except it sets the colour of a fragment, and you can do things with it, per pixel, this is where some neat special effects are possible (a fragment is a "potential pixel", it will be converted into screen co-ordinates by your video card later on and become a pixel).

Edit: Note, this is the GLSL shader language. Microsoft has their own, similar called HLSL and no doubt Java probably has their own, I don't know. They're all fairly similar.

Yeah, but what's the problem you're trying to solve? They all look like that:

https://www.google.com/search?q=opengl+cube+map&rlz=1C1CHBD_enUS771US771&source=lnms&tbm=isch&sa=X&ved=0ahUKEwiv3cODl-zYAhVFQ6wKHUBKDdIQ_AUICigB&biw=1000&bih=893

Are you trying to figure out how to GENERATE the cubemap texture itself, or RENDER it?

http://www.nvidia.com/object/cube_map_ogl_tutorial.html

https://www.khronos.org/opengl/wiki/Cubemap_Texture

(Make sure you have recent drivers if you use that as some people mention failures/artifacts on older cards or very old drivers.)

I guess I just don't understand wtf a 90^ FOV is. Or why it looks so distorted. You can see how the corners of the images for the -X, +Z, +X, -Z directions along the middle of the image stretch up at the corners.

Take this image for example : 4 X 5 Panorama Negative

{"name":"4x5negative_panorama123_bc_small_jpeg70_by_nemonameless-d9m8n6c.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/4\/54b1826c266c95f8d6da0d9dda860ac6.jpg","w":6312,"h":2227,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/4\/54b1826c266c95f8d6da0d9dda860ac6"}

It's only got like a 120^ wide FOV and its aspect is 3 to 1. I would have to cram another 150^ into the same image to get one of these skybox textures I've been seeing to match the same aspect ratio.

I understand the concept of a skybox and a cube map. They omit the seventh square (because it is really the same as the back texture rotated 180 degrees.
{"name":"611220","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/4\/04b5b2677530d54e338e03117a08bc44.png","w":800,"h":800,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/4\/04b5b2677530d54e338e03117a08bc44"}

But if you take a distorted texture, and map it onto a cube, it still looks distorted. Take this annotated image for example :
{"name":"611223","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/3\/a326f6fc7cedda7d5aefb3228409242b.png","w":800,"h":800,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/3\/a326f6fc7cedda7d5aefb3228409242b"}

Each individual image is terribly distorted spherically. Render that distortion onto a cube, and it will still look like crap.

I don't remember this. Kindly provide a linky for me to clicky on quickly?

The 4 x 5 camera I used must not have a very wide FOV. I can't remember what focal length the lens on it was either.

Thanks for pointing me to a 18 year out of date web page.

You didn't answer any of my questions about the distortion though.

Side note: Intel HD can even do modern OpenGL and comes included in even the lowest of mobile chipsets.

My humble ~2013 chromebook with a Celeron and only 2 GB of RAM supports OpenGL 4.5. (Acer C720) And you can get the FOUR GB model for $89.

I think my last netbook with an old 1st gen Atom CPU still has OpenGL ~3.0.

The only other thing I can think is maybe Edgar's got the wrong texture WRAPPING/clamping mode set?

Ala example here, which should be enough code for him to use:

https://www.opengl.org/discussion_boards/showthread.php/170050-Cube-Mapping-Using-OpenGL

[edit] Well, maybe it's not the perfect example thread, but it shows the wrap calls.

[edit] WOW, I was poking around my OpenGL supported extensions and found this gem:

https://github.com/KhronosGroup/OpenGL-Registry/blob/master/extensions/INTEL/INTEL_performance_query.txt

Tons of hardware performance counters for debugging/profiling. I know their CPUs have tons of that stuff too. But it's neat to know you can get statistics on number of shader calls, etc--even if it's on a piece-of-crap integrated intel graphics card.

It may come in handy later to tweak my games for low end systems.

[edit] Okay, so nVidia (and AMD) also have Perf kits!

https://developer.nvidia.com/nvidia-perfkit

Of course it only runs on Windows... because nVidia is a bunch of @!#$!'s.

Meanwhile, AMD's does.

https://developer.amd.com/gpuperfapi/

And not only that, they're OPEN SOURCE:

https://gpuopen.com/gaming-product/gpuperfapi/

I'm in the middle of a long post and Windoze decides to pull it's forceful shutdown and update mode on me. It's been working for half an hour and it's only 25% done. Lame. ;P It's holding my computer hostage.

I'm coding a skybox from scratch with allegro and "old" OpenGL. If it's really as simple as rendering a cube, I'll shit myself.

May take me a while though. Sigh.