Hello, I’m trying to create a grid solver. I’m calling redraw after I visit some cell and I want that cell to be green one by one until the goal cell. But it just makes all of the visited cells green after the function terminates. Can you help me?
My draw function is:
if state == SMALL:
process_small() # I will show this part for simplification.
elif state == LARGE:
global SMALL_GRID, W_SMALL, i
y = 0
for row in SMALL_GRID:
x = 0
for col in row:
if col == -1:
fill(255, 0, 0)
elif col == -2:
elif col == 2: # Changes color to green
x += W_SMALL
y += W_SMALL
print("here " + str(i))
My function is :
# Some algorithm
for neighbor in find_neighbors(current_node, map):
# Some code
if not current_visited[row][column]:
# More code
map[row][column] = 2 # This part is supposed to change the color to green
This is happening because you have redraw() in a while loop…
You can read about the while iteration here:
To determine if while loop is appropriate for what you are trying to accomplish.
And check out redraw here:
I checked both of them but they don’t give me an answer to my question. The code works by the way. I just simplified the code in here for readability. It makes the visited cells green after exiting the function but I want to make each cell green one by one in each iteration.
My apologies @bunal! I just realized this is a python sketch!!
Disregard earlier post…
In structuring a program, it only makes sense to call
redraw() within events such as
mousePressed() . This is because
redraw() does not run
draw() immediately (it only sets a flag that indicates an update is needed).
Is there no way to fill it with green one by one without using mousePressed() ? Because my grid is around 80x80 and if I do it that way I have to press mouse around 6000 times…
Build a rapid mouse clicker device?
You’ll have to restructure your program. Maybe something like this, where you can adjust the
frameRate() to whatever suits you:
column = 0
column += 1
# Some algorithm
circle(column*10, 10, 10)
Of course, this doesn’t quite match your program, but hopefully gives you some idea of how you could approach the problem.
Hahahahah yes I think that would solve my problem but I don’t think that is a good engineering practice If there is no way to bend the drawing rules, I can try it then. Thank you for your answers
This is a limitation/feature of the framework. Even if you are running a separate thread you are not supposed to draw to the screen, only at the end of the draw() “main loop” does the drawing occur.
Other frameworks give more control over drawing to the screen, but at the cost of much more complexity, for a friendly framework I guess this is a small limitation.
I don’t think that putting your
while body inside draw(), or inside a function called in draw(), but guarded by some conditional, would be bad