One thing that is important is, if you want a programmer to do something, make sure it is something that's possible. Think it through to the end.
I worked on a project once on a system for a boarding house where beds were assigned to patients. Sometimes patients would check in before other patients would check out, and they would be assigned the same room. The customer wanted to have a report which would show all of the patients in the rooms. They wanted it to show the patient that was already checked in to the room some times, and in others they wanted to know the patients that were newly checked into the room at other times. They didn't want to see both names at once, and they couldn't provide me with a reasonable explanation of when they would want to see which. They just wanted the computer to mystically understand what their intention is when they went to open that report. They didn't want additional options or controls or reporting options because that was too complicated.
In the end I wasn't able to implement it as they wanted because what they wanted was only half-conceived, the rest was just magic. They needed to either compromise on the amount of information they were willing to put in to the system, or in the amount of information they were willing to be served by the system, but they couldn't expect the system to magically determine what was in their mind.
c++ doesn't do graphics. It depends on what libraries or whatnot you use to do your graphics.
When you change your resolution, generally some kind of event is triggered carrying information about the new resolution. You then respond to that event by changing your layout to appropriately deal with the change. Do you show more? Do you scale up? Do you do neither and paint it on top of a background?
A good way to deal with variable resolutions might be to use relative screen space coordinates instead of absolute pixel coordinates. For instance, x=0 would be the leftmost side of the window, x=0.5 would be the middle, and x=1 would be the rightmost edge. This would make your image always fill the screen, but as the above poster mentioned, you'd have distortion when the aspect ratio changed. You could then worry about detecting and correcting that distortion.
But in all, exactly how you do it is really dependent on what tools you are using to get anything to show up on the screen at all.
You are using immediate mode, which is deprecated.
Is GLuint LoadTextures(const char* filename) returning successfully? You have it return false when it fails, but you never test to see if it failed, you just assume that it succeeds.
It could be something as simple as not having the correct file path or format of the texture being loaded, and since you just ignore it and try not to set the texture if it fails, you never know. I don't know enough about the bmp format you're using for "Crate.bmp", how SOIL is used, or where the file is located to make a judgment, however I am certain that if you were to fail to load the texture properly and SOIL_load_OGL_texture returned 0, you would experience the issue you are noticing.
1: Design around concepts that you have been taught to demonstrate understanding of those concepts. Consider your data structures and why you might use one over the other, explain the reasoning.
2: Design around a concept that you've been taught, but improve or customize it to your use case to demonstrate mastery of the concept, or extension of the concept.
In my own university experience I was asked to write an AI bot that mapped a maze given only local cues to its surroundings (IE: you couldn't look at the whole map). My implementation did better than pretty much anyone else in the class, however, I only got a marginal score because many of the heuristics I used, when asked "why" I couldn't give a great answer. Often it was just "I tried doing it these 3 ways, and of them, the third worked better". And while I did well on any maze generated, I couldn't explain exactly why. Later I realized that I was using certain concepts, some properly, some less effectively than I could have been. I am certain that if I had been able to demonstrate my understanding of those concepts I would have received a better grade.
University isn't about making it work, it's about understanding concepts.
You have the model, which keeps track of the state of the game that you're making. This is going to be where you would manage things like your physics and AI.
You have the view, which is the component that takes what information is stored and generated in the model and displays it for the user. This would be things like your renderer and sound system.
You have the controller, which is where you're going to be taking inputs from the player, and deciding how you're going to manipulate the model based on those inputs, or how the view describes the model.
Generally, you have a main loop. This loop repeats until the game is ended. What happens in the loop is you capture inputs from keys, you perform any ongoing calculations based on the state of the game and the inputs recieved, and you update the view to reflect the current state of the game.
An map of it might look like this
DoPhysics (affected objects fall based on time elapsed since last call)
MoveCharacter (based on keypresses recorded maybe? Check for collisions? Whatever.)
The tricky part honestly comes down to doing those things efficiently. If you want to run at even just 30 frames per second, you have to spend no more than 33ms on calculations between frames. When you want to work with voxels, you have a large amount of data, so you need to find ways to work on that efficiently, when you want to work physics into it, then you have a large amount of points interacting with a large amount of points, which gets even harder.
If you want to start, find out how to make a 3d scene that accepts inputs. Use OpenGL or DirectX. Just getting stuff on the screen is a challenge if you've never done it before. Then come up with a way to represent your data, put that data on the screen, come up with a way to handle user input, use that input to change the data or move the camera. Finally, find a way to do it quickly enough to be acceptable, and eventually write it to (and read it from) permanent storage if you want to be able to save games.