MarkS

This is a tricky legal area. You may not be doing anything illegal if all you do is strictly hack the ROM to make it do what you want, but if you copy its contents (which, BTW, is required to hack the ROM), you're breaking the law.

Spiro, I'd suggest you take a vacation. Bad/stupid/poorly formatted questions are bound to happen. You're taking this WAY to seriously. You've clearly assisted this member in how to ask questions in an intelligent manner on multiple occasions. At this point, maybe it is time to start reporting the posts? ;)

I don't think there is a quick reference. The documentation leaves a lot to be desired. The manual is sparse and the API specification (http://glm.g-truc.net/api-0.9.4/index.html) is based on the glm modules, few of which are very descriptive. I find myself spending quite a bit of time digging through the specification and source. Very frustrating.

I was trying to extract the view frustum from matrices made via glm. I was having no luck with it and finally got it to work by transposing the mvp matrix before extracting the planes. I find this odd as I have done this before using the fixed function pipeline and I have never had to transpose the combined modelview and projection matrix.

 

This is the frustum extraction code I'm using. I got it from: http://www.crownandcutlass.com/features/technicaldetails/frustum.html , and modified it to use glm. I've gone over the code and I cannot see anything wrong. Any ideas? It works now, but shouldn't, and I am not sure why.

 

The mvp matrix is defined as:

projection = glm::perspective(fov,aspect,0.1f,1000.0f);
view = glm::lookAt(glm::vec3(0.0,0.0,10.0),glm::vec3(0.0,0.0,-10.0),glm::vec3(0,1,0));
mvp = projection * view * glm::mat4(1.0f);

 

 
float InvSqrt(float x)
{
float xhalf;
int i;
 
xhalf = 0.5f * x;
i = *(int*)&x;
i = 0x5f3759df - (i >> 1);
x = *(float*)&i;
x = x * (1.5f - xhalf * x * x);
return x;
}
 
void frustum::CalculateFrustum(glm::mat4 mvp)
{
float t;
float m00,m01,m02,m03;
float m10,m11,m12,m13;
float m20,m21,m22,m23;
float m30,m31,m32,m33;
 
mvp = glm::transpose(mvp);
 
m00 = mvp[0][0];
m01 = mvp[0][1];
m02 = mvp[0][2];
m03 = mvp[0][3];
 
m10 = mvp[1][0];
m11 = mvp[1][1];
m12 = mvp[1][2];
m13 = mvp[1][3];
 
m20 = mvp[2][0];
m21 = mvp[2][1];
m22 = mvp[2][2];
m23 = mvp[2][3];
 
m30 = mvp[3][0];
m31 = mvp[3][1];
m32 = mvp[3][2];
m33 = mvp[3][3];
 
planes[0].x = m30 - m00;
planes[0].y = m31 - m01;
planes[0].z = m32 - m02;
planes[0].w = m33 - m03;
 
t = InvSqrt(planes[0].x * planes[0].x + planes[0].y * planes[0].y + planes[0].z * planes[0].z);
 
planes[0].x *= t;
planes[0].y *= t;
planes[0].z *= t;
planes[0].w *= t;
 
planes[1].x = m30 + m00;
planes[1].y = m31 + m01;
planes[1].z = m32 + m02;
planes[1].w = m33 + m03;
 
t = InvSqrt(planes[1].x * planes[1].x + planes[1].y * planes[1].y + planes[1].z * planes[1].z);
 
planes[1].x *= t;
planes[1].y *= t;
planes[1].z *= t;
planes[1].w *= t;
 
planes[2].x = m30 - m10;
planes[2].y = m31 - m11;
planes[2].z = m32 - m12;
planes[2].w = m33 - m13;
 
t = InvSqrt(planes[2].x * planes[2].x + planes[2].y * planes[2].y + planes[2].z * planes[2].z);
 
planes[2].x *= t;
planes[2].y *= t;
planes[2].z *= t;
planes[2].w *= t;
 
planes[3].x = m30 + m10;
planes[3].y = m31 + m11;
planes[3].z = m32 + m12;
planes[3].w = m33 + m13;
 
t = InvSqrt(planes[3].x * planes[3].x + planes[3].y * planes[3].y + planes[3].z * planes[3].z);
 
planes[3].x *= t;
planes[3].y *= t;
planes[3].z *= t;
planes[3].w *= t;
 
planes[4].x = m30 - m20;
planes[4].y = m31 - m21;
planes[4].z = m32 - m22;
planes[4].w = m33 - m23;
 
t = InvSqrt(planes[4].x * planes[4].x + planes[4].y * planes[4].y + planes[4].z * planes[4].z);
 
planes[4].x *= t;
planes[4].y *= t;
planes[4].z *= t;
planes[4].w *= t;
 
planes[5].x = m30 + m20;
planes[5].y = m31 + m21;
planes[5].z = m32 + m22;
planes[5].w = m33 + m23;
 
t = InvSqrt(planes[5].x * planes[5].x + planes[5].y * planes[5].y + planes[5].z * planes[5].z);
 
planes[5].x *= t;
planes[5].y *= t;
planes[5].z *= t;
planes[5].w *= t;
}

I tried this and failed. It is easy, as Daaark says, but in the end I just had to admit that I am not an artist. I followed any tutorial I could find, but my mind doesn't work in the manor required. I tend to focus on mechanical details and can model mechanical objects with ease, but cannot get the hang of organic modeling.
 
I'm not saying that to discourage you, but typically artistic talent appears early in life. If you have it, you know. Try it though. You may find a hidden talent.

My only concern with Blender is that it is open source meaning it evolves very quickly, so what I learn now, many not be the same in a year or 2. Unless, the changes aren't so drastic.  The thing is I am taking courses for graphics, like learning OpenGL and some aspects of how to create a simple game engine

Blender does change frequently, typically every other minor version release. However, this is usually a GUI change or added features. The program has changed significantly since 2.48 (the version I first downloaded), but the techniques still apply.

Buttons 3 and 4 overlap buttons 1 and 2.

 

See pic...

I would spend the time to come up with three different religions that have no basis in the real world, like in the Elder Scrolls series. That is unless your game is based in the real world.

The question is not whether it is faster to calculate the final MVP matrix on the CPU or the GPU, but whether it is faster to calculate it matrix once per model on the CPU or once per vertex on the GPU. But maybe the compiler could, theoretically, precompute the product just before the program is executed, but who knows.

 

 

Once per VERTEX? OK then. Question answered...

What samoth said. Besides, OpenGL is still widely used for scientific visualization and CAD/CAM work. If Microsoft gimped OpenGL, we'd be hearing about it from more sources than a book. Not to mention that someone would have figured a work around by now.

I don't fully understand templates, but I do know that they are agnostic of the purpose of your code. Game development or otherwise, if a part of your code will benefit from their use, use them. They are commonly used in resource management in game development.

Just make sure to use them where they make sense and for their intended purpose. Overuse is bad. Just because you can, doesn't mean you should.

It happens.   At least you learned something.

A better suggestion is to return a integer value depending on the reason for the failure, i.e., 0 for no error, 1 for allocation error, 2 for file not found, etc.
 
You should also be doing exception handling:
 

try{
	m_Terrain = new TerrainHandle;
}
catch(std::bad_alloc)
{
	MessageBox(hwnd, L"Could not create TerrainHandle object.", L"Error", MB_OK);
	return false;
}

That is really poor error handling in the Initialize function. It tests for two different things, file loading and vertex buffer creation, and returns false from either case upon failure. How do you know if the file failed to load or the vertex buffer failed to be created? More over, how can you tell why the file failed to load or why the vertex buffer failed to be created?
 
You need to know specifics before you can debug. I'm going to guess that the textures are not in the directory with the executable and cannot be found. But that is just a guess.

I just got done playing with his code. I took out the multiple calls to srand (now a single call: srand(iseed);), the do nothing for loop and various other oddities ((2 / 1) ?). It now creates very regular terrains. The generated terrains show a very strong rotational symmetry. Each 1/4 of the image is nearly an exact copy of each other, rotated 90°. 

 

I think the entire algorithm needs to be rewritten.

Why do the textures need to be in a manager?

Because most tile-based games use a small subset of textures, but those textures are drawn hundreds of times per level. If I load the same texture for each tile that needs it, the memory demands of this engine will be astronomical. By putting the resources in a manager, only one instance of a texture is loaded and it can then be accessed by any tile and/or sprite that needs it.