my player moves 16 pixels so each time i change the positiion it adds 16 to x or y or removes 16 if i go back, so i m having a problem bcz the player moves by 16 and the 2d array in which i wanna use to find if there is walls is by 1
Since you are using a 2D array to store the state of your game map, the player location should be integers (x and y) that store the row and the column you are currently in.
So if you want to move on the next tile, you need to move your player by 1 unit not 16 pixels which is linked to how you display your game (what if you increase the size of the tiles? Youāll always want to split the logical part from the graphical part of your game)
I will try to do that now, I think my problem is that I am moving the person using pixels not my grid i will see if i can find a solution or do it again
example how i am moving :
void Down(){
if (PosX != 64){
PosX = 64;
} if(PosY !=0){
PosY = 0;
}
y = y+16;
}
Yes this is not exactly the right way to move the player 
Are you using classes and objects in your game as shown by @TfGuy44 ? If not you should because this greatly increase the quality of your code and itās flexibility!
Because in your code I see a mix of posX, posY : what do they represent?
I also suppose you want the player to loop when reaching the borders of the map is that right?
Lastly be careful to respect indentations and spaces in your code (press Ctrl+T in the Processing editor to do that automatically ) :
void down(){
if (PosX != 64) {
PosX = 64;
}
if (PosY != 0) {
PosY = 0;
}
y = y + 16;
}
Ok Thank you i will do it again, can u give me a small example how to use grid to move the player ? sorry im annoying but im new to this and its driving me crazy haha.
posX, posY are for the image not the person but i think its wrong to use it also.
and Thank you for the Ctrl + T helps alot.
Ok so basically the idea is that you have a Player class that represents your player. It has two values : x and y which are respectively the column and row indices where the player is.
If you are new to objects, I recommend you take a look at this tutorial :
https://processing.org/tutorials/objects/
Here is the skeleton of the class :
class Player {
int x, y;
Player(int startX, int startY) {
// The player starting location
x = startX;
y = startY;
}
void move(int dx, int dy) {
// As described above...
}
void left() {
move(-1, 0);
}
void down() {
move(0, 1);
}
// Same for other directions
}
So the player class is holding the data but you need to display it on the grid. For this, add a display method to it :
class Player {
void display() {
// Compute the position of the image according to the tile size
int spriteX = x * tileSize;
int spriteY = y * tileSize;
image(playerSprite, spriteX, spriteY);
}
}
In this method, I assume that tileSize (the size of a tile in pixels, in your case 16) and playerSprite (a PImage holding the image of the player) are both global variables accessible from everywhere (declared outside of draw and setup).
For now this is a simple approach but later you might consider passing those variables to the method or display the player from outsideā¦
Thank you really much for this I appreciate the help. I will try to do it now.
Very good explanation 
1 Like
What logic should i put ? what should inside my if to prevent this problem ?
Itās well explained here : since your player is moving using two indices x and y, then if itās located at the origin (0, 0) then calling the method left() on the player will result in this :
// Start at origin (top left of the map)
Player myPlayer = new Player(0, 0); // x = 0, y = 0
myPlayer.left(); // x = -1, y = 0
myPlayer.display(); // Will display the player outside of the map!!
So you need to prevent this kind of behavior by not alowing the player to move up / right / left or down when situated at the borders of the screen. (hint: use conditions, try to write down a way to tell if the player can move or not) 
simple grid and movement
float playerPosX,playerPosY,x,y,rectWidth,rectHeight;
int rows,cols;
boolean keyDown;
void setup(){
size(400,400);
cols = 10;
rows = 10;
rectWidth = width / cols;
rectHeight = height / rows;
};
void draw(){
logic();
for(int i=0;i<rows;i++){
for(int j=0;j<cols;j++){
stroke(0);
fill(255,0,0);
rect(x+rectWidth*i,y+rectHeight*j,rectWidth,rectHeight);
}
}
fill(255);
rect(playerPosX,playerPosY,rectWidth,rectHeight);
fill(0);
text(playerPosX/rectWidth + " ," + playerPosY/rectHeight,10,10);
};
void logic(){
if(keyPressed&&keyCode == 39&&!keyDown){
if(playerPosX<width - rectWidth)playerPosX += rectWidth;
keyDown = true;
}
if(keyPressed&&keyCode == 37&&!keyDown){
if(playerPosX>0)playerPosX -= rectWidth;
keyDown = true;
}
if(keyPressed&&keyCode == 38&&!keyDown){
if(playerPosY>0)playerPosY -= rectHeight;
keyDown = true;
}
if(keyPressed&&keyCode == 40&&!keyDown){
if(playerPosY<height - rectHeight)playerPosY += rectHeight;
keyDown = true;
}
if(!keyPressed)keyDown = false;
};
You have to release the keys and press again to move;
take note of how the position of your character is calculated in the text function. This should give you a hint as to how to test if your character is moving to a legal tile.
this is the part that needs to be amended and you would need to test if tile at playerPosX+rectWidth is legal. Account for the direction you are heading in.
if(playerPosX<width - rectWidth)playerPosX += rectWidth;
if you are using a 2d array to store your tile config, then you could just call the calculation in the text on your predicted value and voila, if legal increment, else do nothing.
I donāt really agree with the fact of storing the player position x and y as pixel values. In this example, the rectWidth and rectHeight variables are not going to change because they are computed inside the setup() function.
Nevertheless here are few reasons why :
-
What if you can resize the window like this? : setResizable() / Reference / Processing.org
Then the player is not going to react to itā¦ -
What if you want to display the grid smaller, you need to change the tile size so the player is no longer aligned
-
Also what if you change the number of rows and cols at runtime?
This is trivial as they can be amended in draw.