See this web search for discussion on that question:
Having your car move continuously makes edge detection tricky.
An easier alternative would be to just keep row and column number addresses for the cells,
not pixel addresses, and calculate the pixels from the rows, columns, screen height and width values.
That would let you scale your maze to different device sizes and orientations dynamically.
It would also help you to draw your maze walls dynamically,
and it would simplify the storage of maze designs in csv tables.
For example, in your Level1 maze, your man starts at row 7 column 4,
with available move directions Right and Down.
Each move direction results in a corresponding change to the row or column number:
dX("Right") = +1, dY("Right") = 0,
dX("Left") = -1,dY("Left") = 0,
dX("Up") = 0, dY("Up") = -1,
dX("Down") = 0, dY("Down") = +1
Each different 7 by 7 maze could have up to 4 * 7 * 7 moves,
4 possible moves per cell. If there is a wall between 2 cells, do not include that
move in the move table.
Moves:
1,1,Right
1,1,Down
1,2,Left
1,3,Right
1,3,Down
1,4,Up
1,4,Left,
1,4,Right
1,5,Left
1,5,Right
1,7,Left
1,7,Down
2,1,Up
2,1,Down
2,2,Right
2,2,Down
...
You can keep the move table as a simple list,
with each item a JOIN of ROW,COLUMN,MOVE (with comma between parts)
and use the is in list block to test if a particular move direction
is allowed from a particular row and column each time that button is pressed.
You can also use the move table to draw your maze, if you start with a solid black
canvas and draw a fat white line from the edge of a cell to its next cell in the direction
of the move for that entry in the move table. Each move breaks down a wall when painting
the maze.
The move table is simple enough to read from a file,
one per maze, saving you on screens.
You will run out of screens almost immediately otherwise.
ABG