Jump to content
  • Advertisement
babaliaris

OpenGL OpenGL Transformation Is Not Working As I Expected!!

Recommended Posts

In your sprite::addBrain function can you std::cout the sprite tag and the tag of the sprite held by the brain?

In your sprite::render function can you std::cout the sprite tag and the model matrix?

Share this post


Link to post
Share on other sites
Advertisement
Posted (edited)
4 hours ago, SomeoneRichards said:

In your sprite::addBrain function can you std::cout the sprite tag and the tag of the sprite held by the brain?

In your sprite::render function can you std::cout the sprite tag and the model matrix?

As you can see everything works as i expected. The model matrix of the player is changing every time, and also i double checked the model matrices of the other two sprites (they remain Identity Matrices). Also the add brain is adding the brain to the correct sprite (Player).

Output.PNG

 

First Call Of Player's Renderer.

First Change.PNG

 

Second Call Of Player's Renderer.

Second Change.PNG

 

Third Call Of Player's Renderer.

Third Cjange.PNG

Edited by babaliaris

Share this post


Link to post
Share on other sites
Posted (edited)

I'm not entirely sure if this is clear, but when you create your sprites, you are creating a new shader for each one. However, when you render them individually, you are not binding the corresponding shaders each time. The only time you bind a shader is in your render method. So I suspect (but am not sure, as it is difficult going through multiple files, and I'm also fairly new to this) that the last sprite you build is the one whose shader is being used, and therefore is getting the model view matrix mapped to it.

I'm not sure the best way to test or eradicate this issue You could try creating a single shader and sharing it, or you could try adding a bind call in each of your sprite's render functions.

You should really remove the useShader line from the sprite creator. To save from mishaps.

And call it just before rendering.

Does that make sense?

To make it clearer, it looks like this is what you are doing:

Create player sprite, bind player shader.

Create other sprite, bind other shader.

Create other2 sprite, bind other2 shader.

Then, when you render, everything is using the other2 shader (ie the last one you bound), so only this shader (and this corresponding sprite) is getting the model matrix.

Edited by SomeoneRichards

Share this post


Link to post
Share on other sites
43 minutes ago, SomeoneRichards said:

I'm not entirely sure if this is clear, but when you create your sprites, you are creating a new shader for each one. However, when you render them individually, you are not binding the corresponding shaders each time. The only time you bind a shader is in your render method. So I suspect (but am not sure, as it is difficult going through multiple files, and I'm also fairly new to this) that the last sprite you build is the one whose shader is being used, and therefore is getting the model view matrix mapped to it.

I'm not sure the best way to test or eradicate this issue You could try creating a single shader and sharing it, or you could try adding a bind call in each of your sprite's render functions.

You should really remove the useShader line from the sprite creator. To save from mishaps.

And call it just before rendering.

Does that make sense?

To make it clearer, it looks like this is what you are doing:

Create player sprite, bind player shader.

Create other sprite, bind other shader.

Create other2 sprite, bind other2 shader.

Then, when you render, everything is using the other2 shader (ie the last one you bound), so only this shader (and this corresponding sprite) is getting the model matrix.

OMG MAN I LOVE YOU!!!!!!!!!!!!!

I wasn't binding the shaders inside the Sprite::Render() Method So i was actually setting the mvp only on the shader that was binded previously inside the renderer!!!

Problem solved!!

I literally can't thank you enough! This will prevent a lot of frustration in the future.

This forum never led me down :) 

Thank you again!

This is what i had to change in my Sprite::Render Method:

//Render.
void Sprite::Render(Window * window)
{

	//I HAD TO DO THAT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
	m_Impl->program->Bind();



	//Create the projection Matrix based on the current window width and height.
	glm::mat4 proj = glm::ortho(0.0f, (float)window->GetWidth(), 0.0f, (float)window->GetHeight(), -1.0f, 1.0f);


	//SO I CAN DO THAT ON THE RIGHT SHADER!!!!!!!!!!!!!!!!!!!
	//Set the MVP Uniform.
	m_Impl->program->setUniformMat4f("u_MVP", proj * m_Impl->model);


	std::cout << "Inside " << m_Impl->tag.c_str() << " Render() has model pointer: " << &m_Impl->model << std::endl;

	
	//Run All The Brains (Scripts) of this game object (sprite).
	for (unsigned int i = 0; i < m_Impl->brains.size(); i++)
	{

		//Get Current Brain.
		Brain *brain = m_Impl->brains[i];

		//Call the start function only once!
		if (brain->GetStart())
		{
			brain->SetStart(false);
			brain->Start();
		}

		//Call the update function every frame.
		brain->Update();
	}


	//Render.
	window->GetRenderer()->Draw(m_Impl->vao, m_Impl->ibo, m_Impl->texture, m_Impl->program);
}

 

Share this post


Link to post
Share on other sites
Posted (edited)

No worries :) I'm glad I could help.

I really don't think you want that many shaders or shader bindings though. Unless your shaders are actually doing different things.

Just put a shader in your renderer called something like SpriteRenderer, bind it at the start of the render process, and then update and draw each sprite in turn. From my understanding, shader bind calls are one of the most expensive.

Edited by SomeoneRichards

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!