Closed Kovak closed 11 years ago
Thanks for finding this issue Jacob, I will get these fixed tomorrow. I am heading out to dinner with some friends for the night but will continue on the list in the morning. Kerby
On Sat, Jan 12, 2013 at 3:33 PM, Kovak notifications@github.com wrote:
While I was changing some other code I noticed that in the enemy _advance_time code something weird happens lines 674-677
elif enemy.killed == False: self.enemies_dict[enemy]['translate'].xy = (enemy.x, enemy.y) enemy.texture, enemy.size = enemy.animation_controller.get_frame() self.enemies_dict[enemy]['Quad'].texture = enemy.texture
the lines dealing with translate and quad will be automatically handled in the following _render call, so we technically should not need to perform these particular commands inside the advance time code.
I was just hoping to get some clarification behind the reasoning on this code.
Ok on looking into the render code it is missing the else statement common to other _render methods.
There's 2 steps to the render code: the first is if this is the first time the object is being rendered, we do a with canvas and perform the initial setup of the graphics
and then there is an else statement for any other time that performs the update of the position mostly but could also update texture, rotation or size if need be
Our goal is to keep the logic performed in _advance_time that sets the various values separate from the open gl instructions that are performed in the _render method.
It looks like world object actually has this same issue
Kerby think you can take care of fixing these?
— Reply to this email directly or view it on GitHubhttps://github.com/Kovak/CBL_SECRET_PROTOTYPE_RUNNING_GAME/issues/32.
This has been fixed, both the enemy code and world object code have been moved from their advance_time to their render methods.
Just one last little nitpick:
the line enemy.texture, enemy.size = enemy.animation_controller.get_frame()
actually should be in advance_time and not _render
sorry I wasn't to clear on that
that particular part of the code is logic instead of opengl code
While I was changing some other code I noticed that in the enemy _advance_time code something weird happens lines 674-677 in master_candidate
elif enemy.killed == False: self.enemies_dict[enemy]['translate'].xy = (enemy.x, enemy.y) enemy.texture, enemy.size = enemy.animation_controller.get_frame() self.enemies_dict[enemy]['Quad'].texture = enemy.texture
the lines dealing with translate and quad will be automatically handled in the following _render call, so we technically should not need to perform these particular commands inside the advance time code.
I was just hoping to get some clarification behind the reasoning on this code.
Ok on looking into the render code it is missing the else statement common to other _render methods.
There's 2 steps to the render code: the first is if this is the first time the object is being rendered, we do a with canvas and perform the initial setup of the graphics
and then there is an else statement for any other time that performs the update of the position mostly but could also update texture, rotation or size if need be
Our goal is to keep the logic performed in _advance_time that sets the various values separate from the open gl instructions that are performed in the _render method.
It looks like world object actually has this same issue
Kerby think you can take care of fixing these?