Jump to content
  • Advertisement

C++ Problem With Room Generation For Rougelike Game

Recommended Posts

Hello,

I'm programming a simple rougelike video game for fun. I'm running into a very difficult problem with my room generation code, specifically the part that deals with the maze-like hallway to connect the randomly placed rooms inside a dungeon, using the depth-first search method. The code I've written is kinda long and probably hard to read, but I seriously cannot figure out what is causing the issue so try to bear with me please.

Below is the header file for the Floor class, which generates the floor of the dungeon.

#ifndef FLOOR_H_
#define FLOOR_H_

#include <iostream>
#include <vector>
#include <algorithm>
#include "Cell.h"

class Floor {
private:
	int attempts; //Amount of attempts it tries to place a room before giving up. More attempts = more cramped.
	int maxdoor; //Maximum amount of doors on each room
	int maxroom; //Maximum number of rooms. 0 for 999.

	int maxheight, minheight;
	int maxwidth, minwidth;

	int maxbigroom;

	std::vector<std::vector<Cell> > region; //A collection of regions. A region is a collection of cells (rooms & hallway)
	std::vector<Cell> temp_region; //Used to fill the region.
	std::vector<Cell> temp_maze;
	std::vector<Cell> maze;


public:
	Floor();
	void init(int attempts, int maxdoor, int maxroom, int maxwidth, int minwidth, int maxheight, int minheight, int maxbigroom);
	void gen(Cell cell[120][60], SDL_Texture* tex);
	bool check_walls(Cell cell[120][60], int* x, int* y);
};




#endif

The main thing that is important in this header is the temp_maze vector, which is used to keep track of the current section of the maze that has been carved out, so that when the maze hits a dead end it can back track. is the Cell is a class that represents a cell in the 2D grid that the player can move on. For the issue of this post, just think of each Cell as having an X integer, a Y integer, and a Bool to keep track of whether or not the cell is opened up. 

Below is the part of the gen function that deals with the hallway generation.

//Hallway Generation

	int cur_x, cur_y; //Current cell being tested
	bool time_to_break;

	for (int i = 1; i < 119; i++) {
		for (int j = 1; j < 59; j++) {

			if (cell[i][j].return_blockade() == true
					&& cell[i + 1][j].return_blockade() == true
					&& cell[i][j + 1].return_blockade() == true
					&& cell[i - 1][j].return_blockade() == true
					&& cell[i][j - 1].return_blockade() == true) { //Start of a path

				cur_x = i;
				cur_y = j;

				while (true) {

					cell[cur_x][cur_y].set_bloc(false); //Opens up cell
					cell[cur_x][cur_y].set_tex(tex);
					cell[cur_x][cur_y].set_default_tex(tex);

					temp_maze.push_back(cell[cur_x][cur_y]);

					if (check_walls(cell, &cur_x, &cur_y) == false) {

						std::cout << "Entering nospace" << std::endl;
						std::cout << "Size of k: " << temp_maze.size()
								<< std::endl;

						for (int k = temp_maze.size() - 1; k > -1; k--) {

							int xte = temp_maze[k].return_rect().x / 15;
							int yte = temp_maze[k].return_rect().y / 15;

							std::cout << "k: " << k << std::endl;

							std::cout << "rect_x: "<< temp_maze[k].return_rect().x<< " rect_y : "<< temp_maze[k].return_rect().y<< std::endl;
							std::cout << "x_te: " << xte << " y_te: " << yte << std::endl;

							if (check_walls(cell, &xte, &yte) == true) {
								cur_x = xte;
								cur_y = yte;
								std::cout << "Exiting nospace via newblock"
										<< std::endl;
								break;
							}

							if (k == 0) {
								time_to_break = true;
								std::cout << "Exiting nospace via noviableblock"
										<< std::endl;
								break;
							}

						}
					}

					if (time_to_break == true) {
						time_to_break = false;
						temp_maze.clear();
						break;
					}

				}

			}

		}
	}

The broad idea is that, starting from the top-left cell, we scroll through them until we find a cell that is not blocked, nor has any neighbors that are blocked. Than we open that cell up, add it to the temp_maze vector, and check whether it has any viable neighbors. If it does, it moves cur_y and cur_x to that new cell and repeats. If it doesn't have any viable neighbors, than it goes through the temp_maze vector until either it finds a cell that has viable neighbors, or it reaches the end of the vector. This is accomplished with the check_walls function.

bool Floor::check_walls(Cell cell[120][60], int* x, int* y) {

	int ori_x = *x;
	int ori_y = *y;

	std::cout << "Entering checkwalls with x: " << ori_x << " y: " << ori_y
			<< std::endl;

	if (cell[ori_x][ori_y].return_blockade() == true) {
		std::cout << "Checkwalls returns false due to being blocked"
				<< std::endl;
		return false;
	}

	while (true) {

		*x = ori_x;
		*y = ori_y;

		bool upblock, rightblock, downblock, leftblock;
		int sidecount = 0;

		int dir = rand() % 4;

		if (dir == 0) {
			*y = (*y) - 1;
		} else if (dir == 1) {
			*x = (*x) - 1;
		} else if (dir == 2) {
			*y = (*y) + 1;
		} else if (dir == 3) {
			*x = (*x) + 1;
		}

		if (*x <= 0 || *y <= 0) {
			sidecount = 8;
			dir = 5;
			*x = ori_x;
			*y = ori_y;
		}

		if (cell[*x + 1][*y].return_blockade() == false) {
			sidecount++;
		}
		if (cell[*x - 1][*y].return_blockade() == false) {
			sidecount++;
		}
		if (cell[*x][*y + 1].return_blockade() == false) {
			sidecount++;
		}
		if (cell[*x][*y - 1].return_blockade() == false) {
			sidecount++;
		}

		if (sidecount <= 1) {
			std::cout << "Checkwalls returns true" << std::endl;
			return true;

		} else {
			if (dir == 0) {
				upblock = true;
			} else if (dir == 1) {
				leftblock = true;
			} else if (dir == 2) {
				downblock = true;
			} else if (dir == 3) {
				rightblock = true;
			}
		}

		if (upblock == true && leftblock == true && downblock == true
				&& rightblock == true) {
			*x = ori_x;
			*y = ori_y;
			std::cout << "Checkwalls returns false" << std::endl;
			return false;
		}

	}

}

The basic idea here is that if one of the neighbors are available, than it moves x & y to that cell and return true, and if there are none, than return false.

 

The problem is that when I run this the temp_maze  function seems to get filled with the same cell, and time_to_break never gets set to true, as the vector seems to never end. Once again I understand this is kind of a lot but I have looked at this for a couple days now and have no idea what i am doing wrong, so any help would be very much appreciated.

Share this post


Link to post
Share on other sites
Advertisement

Are you able to provide source code that I can compile and run? (People are usually more willing to assist if they can compile your code and see exactly what is going on.)

Normally when you're dealing with such an issue you should be running your debugger to see why temp_maze isn't getting filled with different cells, then step through it. You will also find out what condition is being set that allows it to skip time_to_break.

You also should make it a habit to always set variables. I can see the following: bool time_to_break; I do not see where you've set time_to_break to false by default. Assuming I'm reading your code right, you need to set bool time_to_break = false; It's just a good habit to get into.

You should also set cur_x, cur_y to 0. Always set your variables, do not assume they will be 0, it's simply not true, they hold garbage, and will have unintended effects if you're trying to use them prior to re-setting.

Are you using Visual Studio by chance? Normally you would get a flag on compile if your bool isn't set.

If you're able to reply back with something I can compile, I will run it through and let you know the problem.

Share this post


Link to post
Share on other sites
5 hours ago, Rutin said:

Are you able to provide source code that I can compile and run? (People are usually more willing to assist if they can compile your code and see exactly what is going on.)

Normally when you're dealing with such an issue you should be running your debugger to see why temp_maze isn't getting filled with different cells, then step through it. You will also find out what condition is being set that allows it to skip time_to_break.

You also should make it a habit to always set variables. I can see the following: bool time_to_break; I do not see where you've set time_to_break to false by default. Assuming I'm reading your code right, you need to set bool time_to_break = false; It's just a good habit to get into.

You should also set cur_x, cur_y to 0. Always set your variables, do not assume they will be 0, it's simply not true, they hold garbage, and will have unintended effects if you're trying to use them prior to re-setting.

Are you using Visual Studio by chance? Normally you would get a flag on compile if your bool isn't set.

If you're able to reply back with something I can compile, I will run it through and let you know the problem.

Thanks for replying Rutin! 

Here is the github repository for the project: https://github.com/Starfruit64/Paladin

Im not 100% if this is what you were asking for, so if it's not just say. And no, I'm not using Visual Studio, I'm using Eclipse. (p.s I'll keep what you said about initializing variables in mind)

Share this post


Link to post
Share on other sites

Thank you for posting the code. I need to setup my SDL2 to run this, but I did take a quick look and got a basic running version up.

Just to clarify, are you saying that temp_maze.push_back(cell[cur_x][cur_y]); will always add the same entry?

I looked briefly at your code, and it appears you have a few problems.

1. I noticed you do set every cell to true for blockade, but all your functions appear to use set_bloc(false); without ever setting it to true again. This becomes a problem for the #2.

2. In your Hallway Generation you have the following method called if (check_walls(cell, &cur_x, &cur_y) == false) once you enter this function you will never be able to return false because the following block of code is never met.

if (cell[ori_x][ori_y].return_blockade() == true) {
  std::cout << "Checkwalls returns false due to being blocked"
    << std::endl;
  return false;
}

 and lower down

if (upblock == true && leftblock == true && downblock == true
    && rightblock == true) {
  *x = ori_x;
  *y = ori_y;
  std::cout << "Checkwalls returns false" << std::endl;
  return false;
}

Because you can never satisfy check_walls to false, it essentially just continues to loop forever through your functions.

3. This is extremely important. Do not use while(true) loops without breaking! This is not proper, and if you're going to use something like this, you forgot to use break; by using any return statement you're leaving the function right away. Use something like while(looping).

Once this code hits:

if (sidecount <= 1) {
  std::cout << "Checkwalls returns true" << std::endl;
  return true;

}

It will just return out of the function as true, which again will not satisfy: if (check_walls(cell, &cur_x, &cur_y) == false)

This is why you can never satisfy that statement to go deeper. You never can return false in check_walls, and all your blockades being checked are always false because it appears to be set prior to false.

Let me know if I'm on to something here, it's been a long day so I couldn't go too much in depth with your code.

EDIT: I forgot to mention, in Floor.cpp you also did not initialize your boolean variables again.

bool upblock, rightblock, downblock, leftblock;

Edited by Rutin

Share this post


Link to post
Share on other sites
On 1/29/2018 at 9:28 PM, Rutin said:

Thank you for posting the code. I need to setup my SDL2 to run this, but I did take a quick look and got a basic running version up.

Just to clarify, are you saying that temp_maze.push_back(cell[cur_x][cur_y]); will always add the same entry?

I looked briefly at your code, and it appears you have a few problems.

1. I noticed you do set every cell to true for blockade, but all your functions appear to use set_bloc(false); without ever setting it to true again. This becomes a problem for the #2.

2. In your Hallway Generation you have the following method called if (check_walls(cell, &cur_x, &cur_y) == false) once you enter this function you will never be able to return false because the following block of code is never met.


if (cell[ori_x][ori_y].return_blockade() == true) {
  std::cout << "Checkwalls returns false due to being blocked"
    << std::endl;
  return false;
}

 and lower down


if (upblock == true && leftblock == true && downblock == true
    && rightblock == true) {
  *x = ori_x;
  *y = ori_y;
  std::cout << "Checkwalls returns false" << std::endl;
  return false;
}

Because you can never satisfy check_walls to false, it essentially just continues to loop forever through your functions.

3. This is extremely important. Do not use while(true) loops without breaking! This is not proper, and if you're going to use something like this, you forgot to use break; by using any return statement you're leaving the function right away. Use something like while(looping).

Once this code hits:


if (sidecount <= 1) {
  std::cout << "Checkwalls returns true" << std::endl;
  return true;

}

It will just return out of the function as true, which again will not satisfy: if (check_walls(cell, &cur_x, &cur_y) == false)

This is why you can never satisfy that statement to go deeper. You never can return false in check_walls, and all your blockades being checked are always false because it appears to be set prior to false.

Let me know if I'm on to something here, it's been a long day so I couldn't go too much in depth with your code.

EDIT: I forgot to mention, in Floor.cpp you also did not initialize your boolean variables again.

bool upblock, rightblock, downblock, leftblock;

I appreciate your help, but I don't think this is the issue. if(check_walls(cell, &cur_x, &cur_y) == false is actually satisfied. Whenever i run the program, in fact, it seems always returns false. The check_walls function is used to test if there are any available neighbors of the current cell. If there are it changes cur_x and cur_y. If there are none, it is supposed to iterate through vector until it wither finds a cell that returns true when passed into check_walls, or until it runs out of cells. 

if (upblock == true && leftblock == true && downblock == true
    && rightblock == true) {
  *x = ori_x;
  *y = ori_y;
  std::cout << "Checkwalls returns false" << std::endl;
  return false;
}

I don't understand why you say this can't be satisfied. If all four of the cells surrounding the current cell are blocked, it should set all four of those bools to true and return false.

Share this post


Link to post
Share on other sites

I ran your code through a debugger, and this is the information I got from each break point. I set several breaks with condition checks throughout your code, and I can never satisfy if(check_walls(cell, &cur_x, &cur_y) == false

Essentially your program never leaves the method floor.gen(board, floor_tex); in Main.cpp, it gets stuck while looping through. When I'm stating your arguments are not being satisfied, it's based on running over 20,000+ loops through if(check_walls(cell, &cur_x, &cur_y) == false I was not able to hit any of the return false blocks.

If you're getting different results, then I really don't know what to say as my debugging is telling me another story. Unless you can re-package this for Visual Studio and upload. Maybe something is going wrong when I ported it over to Visual Studio, but none of your code was altered, and I have SDL2 with all your extended libraries loading just fine.

Are you able to hit the draw code on your version?

Edited by Rutin

Share this post


Link to post
Share on other sites

  • Advertisement
  • Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • By chiffre
      Introduction:
      In general my questions pertain to the differences between floating- and fixed-point data. Additionally I would like to understand when it can be advantageous to prefer fixed-point representation over floating-point representation in the context of vertex data and how the hardware deals with the different data-types. I believe I should be able to reduce the amount of data (bytes) necessary per vertex by choosing the most opportune representations for my vertex attributes. Thanks ahead of time if you, the reader, are considering the effort of reading this and helping me.
      I found an old topic that shows this is possible in principal, but I am not sure I understand what the pitfalls are when using fixed-point representation and whether there are any hardware-based performance advantages/disadvantages.
      (TLDR at bottom)
      The Actual Post:
      To my understanding HLSL/D3D11 offers not just the traditional floating point model in half-,single-, and double-precision, but also the fixed-point model in form of signed/unsigned normalized integers in 8-,10-,16-,24-, and 32-bit variants. Both models offer a finite sequence of "grid-points". The obvious difference between the two models is that the fixed-point model offers a constant spacing between values in the normalized range of [0,1] or [-1,1], while the floating point model allows for smaller "deltas" as you get closer to 0, and larger "deltas" the further you are away from 0.
      To add some context, let me define a struct as an example:
      struct VertexData { float[3] position; //3x32-bits float[2] texCoord; //2x32-bits float[3] normals; //3x32-bits } //Total of 32 bytes Every vertex gets a position, a coordinate on my texture, and a normal to do some light calculations. In this case we have 8x32=256bits per vertex. Since the texture coordinates lie in the interval [0,1] and the normal vector components are in the interval [-1,1] it would seem useful to use normalized representation as suggested in the topic linked at the top of the post. The texture coordinates might as well be represented in a fixed-point model, because it seems most useful to be able to sample the texture in a uniform manner, as the pixels don't get any "denser" as we get closer to 0. In other words the "delta" does not need to become any smaller as the texture coordinates approach (0,0). A similar argument can be made for the normal-vector, as a normal vector should be normalized anyway, and we want as many points as possible on the sphere around (0,0,0) with a radius of 1, and we don't care about precision around the origin. Even if we have large textures such as 4k by 4k (or the maximum allowed by D3D11, 16k by 16k) we only need as many grid-points on one axis, as there are pixels on one axis. An unsigned normalized 14 bit integer would be ideal, but because it is both unsupported and impractical, we will stick to an unsigned normalized 16 bit integer. The same type should take care of the normal vector coordinates, and might even be a bit overkill.
      struct VertexData { float[3] position; //3x32-bits uint16_t[2] texCoord; //2x16bits uint16_t[3] normals; //3x16bits } //Total of 22 bytes Seems like a good start, and we might even be able to take it further, but before we pursue that path, here is my first question: can the GPU even work with the data in this format, or is all I have accomplished minimizing CPU-side RAM usage? Does the GPU have to convert the texture coordinates back to a floating-point model when I hand them over to the sampler in my pixel shader? I have looked up the data types for HLSL and I am not sure I even comprehend how to declare the vertex input type in HLSL. Would the following work?
      struct VertexInputType { float3 pos; //this one is obvious unorm half2 tex; //half corresponds to a 16-bit float, so I assume this is wrong, but this the only 16-bit type I found on the linked MSDN site snorm half3 normal; //same as above } I assume this is possible somehow, as I have found input element formats such as: DXGI_FORMAT_R16G16B16A16_SNORM and DXGI_FORMAT_R16G16B16A16_UNORM (also available with a different number of components, as well as different component lengths). I might have to avoid 3-component vectors because there is no 3-component 16-bit input element format, but that is the least of my worries. The next question would be: what happens with my normals if I try to do lighting calculations with them in such a normalized-fixed-point format? Is there no issue as long as I take care not to mix floating- and fixed-point data? Or would that work as well? In general this gives rise to the question: how does the GPU handle fixed-point arithmetic? Is it the same as integer-arithmetic, and/or is it faster/slower than floating-point arithmetic?
      Assuming that we still have a valid and useful VertexData format, how far could I take this while remaining on the sensible side of what could be called optimization? Theoretically I could use the an input element format such as DXGI_FORMAT_R10G10B10A2_UNORM to pack my normal coordinates into a 10-bit fixed-point format, and my verticies (in object space) might even be representable in a 16-bit unsigned normalized fixed-point format. That way I could end up with something like the following struct:
      struct VertexData { uint16_t[3] pos; //3x16bits uint16_t[2] texCoord; //2x16bits uint32_t packedNormals; //10+10+10+2bits } //Total of 14 bytes Could I use a vertex structure like this without too much performance-loss on the GPU-side? If the GPU has to execute some sort of unpacking algorithm in the background I might as well let it be. In the end I have a functioning deferred renderer, but I would like to reduce the memory footprint of the huge amount of vertecies involved in rendering my landscape. 
      TLDR: I have a lot of vertices that I need to render and I want to reduce the RAM-usage without introducing crazy compression/decompression algorithms to the CPU or GPU. I am hoping to find a solution by involving fixed-point data-types, but I am not exactly sure how how that would work.
    • By babaliaris
      Well i found out Here what's the problem and how to solve it (Something about world coordinates and object coordinates) but i can't understand how ti works. Can you show me some examples in code on how you implement this???
       
      Scaling Matrix:
      m_Impl->scale = glm::mat4(1.0f); m_Impl->scale = glm::scale(m_Impl->scale, glm::vec3(width, height, 0)); Verticies:
      //Verticies. float verticies[] = { //Positions. //Texture Coordinates. 1.0f, 1.0f, 0.0f, 0.0f, 2.0f, 1.0f, 1.0f, 0.0f, 2.0f, 2.0f, 1.0f, 1.0f, 1.0f, 2.0f, 0.0f, 1.0f }; Rendering:
      //Projection Matrix. glm::mat4 proj = glm::ortho(0.0f, (float)window->GetWidth(), 0.0f, (float)window->GetHeight(), -1.0f, 1.0f); //Set the uniform. material->program->setUniformMat4f("u_MVP", proj * model); //model is the scale matrix from the previous code. //Draw. glDrawElements(GL_TRIANGLES, material->ibo->GetCount(), GL_UNSIGNED_INT, NULL);  
      Shader:
      #shader vertex #version 330 core layout(location = 0) in vec4 aPos; layout(location = 1) in vec2 aTexCoord; out vec2 texCoord; uniform mat4 u_MVP; void main() { gl_Position = u_MVP*aPos; texCoord = aTexCoord; } #shader fragment #version 330 core out vec4 colors; in vec2 texCoord; uniform sampler2D u_Texture; void main() { colors = texture(u_Texture, texCoord); }  
      Before Scaling (It's down there on the bottom left corner as a dot).

       
      After Scaling

       
      Problem: Why does the position also changes?? If you see my Verticies, the first position starts at 1.0f, 1.0f , so when i'm scaling it should stay at that position
    • By Bret Marisnick
      Hey guys!

      Ok so I have been developing some ideas to get to work on and I have one specifically that I need some assistance with. The App will be called “A Walk On the Beach.” It’s somewhat of a 3D representation of the Apple app “Calm.” The idea is that you can take a virtual stroll up and down a pier on the beach. Building the level of a pier seems self explanatory to me... but my question is this.... How could I make it so that players can leave notes on the pier for other users to read and or respond to? I was thinking something like a virtual “peg board” at the end of the pier where players can “pin up” pictures or post it’s.

      Any advice on how I could accomplish this would be helpful!
    • By babaliaris
      Hello Everyone!
      I'm learning openGL, and currently i'm making a simple 2D game engine to test what I've learn so far.  In order to not say to much, i made a video in which i'm showing you the behavior of the rendering.
      Video: 
       
      What i was expecting to happen, was the player moving around. When i render only the player, he moves as i would expect. When i add a second Sprite object, instead of the Player, this new sprite object is moving and finally if i add a third Sprite object the third one is moving. And the weird think is that i'm transforming the Vertices of the Player so why the transformation is being applied somewhere else?
       
      Take a look at my code:
      Sprite Class
      (You mostly need to see the Constructor, the Render Method and the Move Method)
      #include "Brain.h" #include <glm/gtc/matrix_transform.hpp> #include <vector> struct Sprite::Implementation { //Position. struct pos pos; //Tag. std::string tag; //Texture. Texture *texture; //Model matrix. glm::mat4 model; //Vertex Array Object. VertexArray *vao; //Vertex Buffer Object. VertexBuffer *vbo; //Layout. VertexBufferLayout *layout; //Index Buffer Object. IndexBuffer *ibo; //Shader. Shader *program; //Brains. std::vector<Brain *> brains; //Deconstructor. ~Implementation(); }; Sprite::Sprite(std::string image_path, std::string tag, float x, float y) { //Create Pointer To Implementaion. m_Impl = new Implementation(); //Set the Position of the Sprite object. m_Impl->pos.x = x; m_Impl->pos.y = y; //Set the tag. m_Impl->tag = tag; //Create The Texture. m_Impl->texture = new Texture(image_path); //Initialize the model Matrix. m_Impl->model = glm::mat4(1.0f); //Get the Width and the Height of the Texture. int width = m_Impl->texture->GetWidth(); int height = m_Impl->texture->GetHeight(); //Create the Verticies. float verticies[] = { //Positions //Texture Coordinates. x, y, 0.0f, 0.0f, x + width, y, 1.0f, 0.0f, x + width, y + height, 1.0f, 1.0f, x, y + height, 0.0f, 1.0f }; //Create the Indicies. unsigned int indicies[] = { 0, 1, 2, 2, 3, 0 }; //Create Vertex Array. m_Impl->vao = new VertexArray(); //Create the Vertex Buffer. m_Impl->vbo = new VertexBuffer((void *)verticies, sizeof(verticies)); //Create The Layout. m_Impl->layout = new VertexBufferLayout(); m_Impl->layout->PushFloat(2); m_Impl->layout->PushFloat(2); m_Impl->vao->AddBuffer(m_Impl->vbo, m_Impl->layout); //Create the Index Buffer. m_Impl->ibo = new IndexBuffer(indicies, 6); //Create the new shader. m_Impl->program = new Shader("Shaders/SpriteShader.shader"); } //Render. void Sprite::Render(Window * window) { //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); //Set the MVP Uniform. m_Impl->program->setUniformMat4f("u_MVP", proj * m_Impl->model); //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); } void Sprite::Move(float speed, bool left, bool right, bool up, bool down) { if (left) { m_Impl->pos.x -= speed; m_Impl->model = glm::translate(m_Impl->model, glm::vec3(-speed, 0, 0)); } if (right) { m_Impl->pos.x += speed; m_Impl->model = glm::translate(m_Impl->model, glm::vec3(speed, 0, 0)); } if (up) { m_Impl->pos.y += speed; m_Impl->model = glm::translate(m_Impl->model, glm::vec3(0, speed, 0)); } if (down) { m_Impl->pos.y -= speed; m_Impl->model = glm::translate(m_Impl->model, glm::vec3(0, -speed, 0)); } } void Sprite::AddBrain(Brain * brain) { //Push back the brain object. m_Impl->brains.push_back(brain); } pos *Sprite::GetPos() { return &m_Impl->pos; } std::string Sprite::GetTag() { return m_Impl->tag; } int Sprite::GetWidth() { return m_Impl->texture->GetWidth(); } int Sprite::GetHeight() { return m_Impl->texture->GetHeight(); } Sprite::~Sprite() { delete m_Impl; } //Implementation Deconstructor. Sprite::Implementation::~Implementation() { delete texture; delete vao; delete vbo; delete layout; delete ibo; delete program; }  
      Renderer Class
      #include "Renderer.h" #include "Error.h" Renderer::Renderer() { } Renderer::~Renderer() { } void Renderer::Draw(VertexArray * vao, IndexBuffer * ibo, Texture *texture, Shader * program) { vao->Bind(); ibo->Bind(); program->Bind(); if (texture != NULL) texture->Bind(); GLCall(glDrawElements(GL_TRIANGLES, ibo->GetCount(), GL_UNSIGNED_INT, NULL)); } void Renderer::Clear(float r, float g, float b) { GLCall(glClearColor(r, g, b, 1.0)); GLCall(glClear(GL_COLOR_BUFFER_BIT)); } void Renderer::Update(GLFWwindow *window) { /* Swap front and back buffers */ glfwSwapBuffers(window); /* Poll for and process events */ glfwPollEvents(); }  
      Shader Code
      #shader vertex #version 330 core layout(location = 0) in vec4 aPos; layout(location = 1) in vec2 aTexCoord; out vec2 t_TexCoord; uniform mat4 u_MVP; void main() { gl_Position = u_MVP * aPos; t_TexCoord = aTexCoord; } #shader fragment #version 330 core out vec4 aColor; in vec2 t_TexCoord; uniform sampler2D u_Texture; void main() { aColor = texture(u_Texture, t_TexCoord); } Also i'm pretty sure that every time i'm hitting the up, down, left and right arrows on the keyboard, i'm changing the model Matrix of the Player and not the others.
       
      Window Class:
      #include "Window.h" #include <GL/glew.h> #include <GLFW/glfw3.h> #include "Error.h" #include "Renderer.h" #include "Scene.h" #include "Input.h" //Global Variables. int screen_width, screen_height; //On Window Resize. void OnWindowResize(GLFWwindow *window, int width, int height); //Implementation Structure. struct Window::Implementation { //GLFW Window. GLFWwindow *GLFW_window; //Renderer. Renderer *renderer; //Delta Time. double delta_time; //Frames Per Second. int fps; //Scene. Scene *scnene; //Input. Input *input; //Deconstructor. ~Implementation(); }; //Window Constructor. Window::Window(std::string title, int width, int height) { //Initializing width and height. screen_width = width; screen_height = height; //Create Pointer To Implementation. m_Impl = new Implementation(); //Try initializing GLFW. if (!glfwInit()) { std::cout << "GLFW could not be initialized!" << std::endl; std::cout << "Press ENTER to exit..." << std::endl; std::cin.get(); exit(-1); } //Setting up OpenGL Version 3.3 Core Profile. glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3); glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3); glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE); /* Create a windowed mode window and its OpenGL context */ m_Impl->GLFW_window = glfwCreateWindow(width, height, title.c_str(), NULL, NULL); if (!m_Impl->GLFW_window) { std::cout << "GLFW could not create a window!" << std::endl; std::cout << "Press ENTER to exit..." << std::endl; std::cin.get(); glfwTerminate(); exit(-1); } /* Make the window's context current */ glfwMakeContextCurrent(m_Impl->GLFW_window); //Initialize GLEW. if(glewInit() != GLEW_OK) { std::cout << "GLEW could not be initialized!" << std::endl; std::cout << "Press ENTER to exit..." << std::endl; std::cin.get(); glfwTerminate(); exit(-1); } //Enabling Blending. GLCall(glEnable(GL_BLEND)); GLCall(glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)); //Setting the ViewPort. GLCall(glViewport(0, 0, width, height)); //**********Initializing Implementation**********// m_Impl->renderer = new Renderer(); m_Impl->delta_time = 0.0; m_Impl->fps = 0; m_Impl->input = new Input(this); //**********Initializing Implementation**********// //Set Frame Buffer Size Callback. glfwSetFramebufferSizeCallback(m_Impl->GLFW_window, OnWindowResize); } //Window Deconstructor. Window::~Window() { delete m_Impl; } //Window Main Loop. void Window::MainLoop() { //Time Variables. double start_time = 0, end_time = 0, old_time = 0, total_time = 0; //Frames Counter. int frames = 0; /* Loop until the user closes the window */ while (!glfwWindowShouldClose(m_Impl->GLFW_window)) { old_time = start_time; //Total time of previous frame. start_time = glfwGetTime(); //Current frame start time. //Calculate the Delta Time. m_Impl->delta_time = start_time - old_time; //Get Frames Per Second. if (total_time >= 1) { m_Impl->fps = frames; total_time = 0; frames = 0; } //Clearing The Screen. m_Impl->renderer->Clear(0, 0, 0); //Render The Scene. if (m_Impl->scnene != NULL) m_Impl->scnene->Render(this); //Updating the Screen. m_Impl->renderer->Update(m_Impl->GLFW_window); //Increasing frames counter. frames++; //End Time. end_time = glfwGetTime(); //Total time after the frame completed. total_time += end_time - start_time; } //Terminate GLFW. glfwTerminate(); } //Load Scene. void Window::LoadScene(Scene * scene) { //Set the scene. m_Impl->scnene = scene; } //Get Delta Time. double Window::GetDeltaTime() { return m_Impl->delta_time; } //Get FPS. int Window::GetFPS() { return m_Impl->fps; } //Get Width. int Window::GetWidth() { return screen_width; } //Get Height. int Window::GetHeight() { return screen_height; } //Get Input. Input * Window::GetInput() { return m_Impl->input; } Renderer * Window::GetRenderer() { return m_Impl->renderer; } GLFWwindow * Window::GetGLFWindow() { return m_Impl->GLFW_window; } //Implementation Deconstructor. Window::Implementation::~Implementation() { delete renderer; delete input; } //OnWindowResize void OnWindowResize(GLFWwindow *window, int width, int height) { screen_width = width; screen_height = height; //Updating the ViewPort. GLCall(glViewport(0, 0, width, height)); }  
      Brain Class
      #include "Brain.h" #include "Sprite.h" #include "Window.h" struct Brain::Implementation { //Just A Flag. bool started; //Window Pointer. Window *window; //Sprite Pointer. Sprite *sprite; }; Brain::Brain(Window *window, Sprite *sprite) { //Create Pointer To Implementation. m_Impl = new Implementation(); //Initialize Implementation. m_Impl->started = true; m_Impl->window = window; m_Impl->sprite = sprite; } Brain::~Brain() { //Delete Pointer To Implementation. delete m_Impl; } void Brain::Start() { } void Brain::Update() { } Window * Brain::GetWindow() { return m_Impl->window; } Sprite * Brain::GetSprite() { return m_Impl->sprite; } bool Brain::GetStart() { return m_Impl->started; } void Brain::SetStart(bool value) { m_Impl->started = value; } Script Class (Its a Brain Subclass!!!)
      #include "Script.h" Script::Script(Window *window, Sprite *sprite) : Brain(window, sprite) { } Script::~Script() { } void Script::Start() { std::cout << "Game Started!" << std::endl; } void Script::Update() { Input *input = this->GetWindow()->GetInput(); Sprite *sp = this->GetSprite(); //Move this sprite. this->GetSprite()->Move(200 * this->GetWindow()->GetDeltaTime(), input->GetKeyDown("left"), input->GetKeyDown("right"), input->GetKeyDown("up"), input->GetKeyDown("down")); std::cout << sp->GetTag().c_str() << ".x = " << sp->GetPos()->x << ", " << sp->GetTag().c_str() << ".y = " << sp->GetPos()->y << std::endl; }  
      Main:
      #include "SpaceShooterEngine.h" #include "Script.h" int main() { Window w("title", 600,600); Scene *scene = new Scene(); Sprite *player = new Sprite("Resources/Images/player.png", "Player", 100,100); Sprite *other = new Sprite("Resources/Images/cherno.png", "Other", 400, 100); Sprite *other2 = new Sprite("Resources/Images/cherno.png", "Other", 300, 400); Brain *brain = new Script(&w, player); player->AddBrain(brain); scene->AddSprite(player); scene->AddSprite(other); scene->AddSprite(other2); w.LoadScene(scene); w.MainLoop(); return 0; }  
       
      I literally can't find what is wrong. If you need more code, ask me to post it. I will also attach all the source files.
      Brain.cpp
      Error.cpp
      IndexBuffer.cpp
      Input.cpp
      Renderer.cpp
      Scene.cpp
      Shader.cpp
      Sprite.cpp
      Texture.cpp
      VertexArray.cpp
      VertexBuffer.cpp
      VertexBufferLayout.cpp
      Window.cpp
      Brain.h
      Error.h
      IndexBuffer.h
      Input.h
      Renderer.h
      Scene.h
      Shader.h
      SpaceShooterEngine.h
      Sprite.h
      Texture.h
      VertexArray.h
      VertexBuffer.h
      VertexBufferLayout.h
      Window.h
    • By 3dmodelerguy
      So in the few different tutorials that I have seen for using C++ / SDL, the implementation of the camera does not effect how the player is rendered but how the the rest of the world is rendered. Instead of changing the position / offset of where the player is rendered, you change the position / offset of where the map and other entities are renderer.
      Out of curiosity, is this the standard (or maybe only) way of doing things when working with lower level code like C++ / SDL?
      While it makes logical sense to me, my experience in game dev has always been high level abstractions (game engines like Unity or even libraries like Love) so it just feels wrong but maybe all of those engines / tools do it the same way and the abstraction they provide just hides that fact.
  • Advertisement
×

Important Information

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

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!