Jump to content

  • Log In with Google      Sign In   
  • Create Account

staticVoid2

Member Since 06 Jan 2008
Offline Last Active Dec 14 2014 04:10 AM

Posts I've Made

In Topic: someone help me ID this pattern?

03 November 2014 - 02:46 PM

I think the closest Software Design pattern to what you are describing is the Command Pattern


In Topic: Good books on mathematics

22 October 2014 - 01:10 PM

Thanks


In Topic: OpenGL, RAII and Multi-threading

26 August 2014 - 09:51 AM

Thanks for the replies. All of the sugested methods work, I was just looking for the best way to structure this for scalability.

 

 

This is what we do in our very huge in-house game engine.
It saves a lot of trouble, prevents retarded bugs, etc.

 

Can I ask, do you abstract the entire rendering interface? Or is this just for resource allocation? I have no intention of creating a layer between the application code and OpenGL but for the case I have stated it poses a lot of benefits.

 

I'll try some of the suggests methods and see which one fits best.

 

Thanks.


In Topic: OpenGL, RAII and Multi-threading

26 August 2014 - 06:04 AM

I could do that but it means breaking RAII and moving the initialization of those objects into the initializeGL method, the OpenGL is also mixed in with normal code so for example:

class TerrainManager
{
	float* mHeightData[128][128];
	
	GLuint mIndexBuffer;
	
	TerrainManager()
	{
		for(int x = 0; x < 128; ++x)
		{
			for(int y = 0; y < 128; ++y)
			{
				mHeightData[x][y] = /* some value */;
			}
		}
	}
	
	
	void InitGL()
	{
		glGenBuffers(1, &mIndexBuffer);
		...
	}
	
	void DestroyGL()
	{
		glDeleteBuffers(1, &mIndexBuffer);
		...
	}
}

class Application
{
	QGLWidget* mGLWidget;
	
	TerrainManager mTerrainManager;
}

The mHeightData, even though initialized in the constructor, would not be accessible until the initializeGL callback method was called. Adding the InitGL and DestroyGL methods is a suitable solution but I feel it just adds a lot of code. I was wondering if abstracting the rendering interface to be something like:

class TerrainManager
{
	float* mHeightData[128][128];
	
	IndexBuffer* mIndexBuffer;
	
	TerrainManager()
	{
		for(int x = 0; x < 128; ++x)
		{
			for(int y = 0; y < 128; ++y)
			{
				mHeightData[x][y] = /* some value */;
			}
		}
		
		mIndexBuffer = new IndexBuffer(...);
	}
}

class IndexBuffer
{
	vector<int> mIndices;
	GLuint mIndexBuffer;

	void InitGL()
	{
		glGenBuffers(1, &mIndexBuffer);
		...
	}
	
	void DestroyGL()
	{
		glDeleteBuffers(1, &mIndexBuffer);
		...
	}
}

might be a better solution.


In Topic: Java and JOGL for serious Game development?

07 August 2014 - 01:55 PM

 

Ok, so I'm running OpenGL 3.0, one of the first things I do in code is check my GL version number to make sure it is compatible through GLEW:

	if(!GLEW_VERSION_2_1)
	{
		cerr << "OpenGL version 2.1 or higher required" << endl;
		return false;
	}
When I compile my shaders I get the error:
 
error: 'in' qualifier in declaration of 'position' only valid for function parameters in GLSL 1.10.
 
> in vec3 position;
 
Even though the GLSL version should be at least 1.20.8 according to this: (for OpenGL 2.1)
 
http://en.wikipedia.org/wiki/OpenGL_Shading_Language#Versions
 
This is what is causing my headaches, I'm not sure if this is an error on my part or an error with GLEW.

 


It is most likely an error on your part, the in qualifier is only valid in the global scope (with some restrictions) and in function parameters, i would guess that the error is caused by you using the in qualifier in a local scope. (Allthough its just a guess, i havn't seen your code so ...)

 

 

It was defined in global scope, although I updated my drivers and it seemed to fix the problem. It was using an incorrect version of GLSL.


PARTNERS