From 2961d905bbf6f4d5b96cf364a9a168b3921ed81d Mon Sep 17 00:00:00 2001 From: lawnjelly Date: Mon, 17 Aug 2020 19:12:34 +0100 Subject: [PATCH] GLES2 batching - Fix redundant transform synchronization in batches In rare circumstances an item would issue multiple transform commands before a (non rect) draw command. The command syncronization would incorrectly start from first transform, instead of the current transform in these circumstances, which could have the result of missing drawing some commands from the end of the batch. This had been shown in the wild occuring in debug collision polys. It was a benign error (sometimes visual elements would be lost), but did not cause any serious problems. This PR fixes this synchronization error. --- drivers/gles2/rasterizer_canvas_gles2.h | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gles2/rasterizer_canvas_gles2.h b/drivers/gles2/rasterizer_canvas_gles2.h index b07998333e1..11788768e1c 100644 --- a/drivers/gles2/rasterizer_canvas_gles2.h +++ b/drivers/gles2/rasterizer_canvas_gles2.h @@ -372,11 +372,18 @@ inline void RasterizerCanvasGLES2::_prefill_default_batch(FillState &r_fill_stat // another default command, just add to the existing batch r_fill_state.curr_batch->num_commands++; } else { -#ifdef DEBUG_ENABLED +#if defined(TOOLS_ENABLED) && defined(DEBUG_ENABLED) if (r_fill_state.transform_extra_command_number_p1 != p_command_num) { WARN_PRINT_ONCE("_prefill_default_batch : transform_extra_command_number_p1 != p_command_num"); } #endif + // if the first member of the batch is a transform we have to be careful + if (!r_fill_state.curr_batch->num_commands) { + // there can be leading useless extra transforms (sometimes happens with debug collision polys) + // we need to rejig the first_command for the first useful transform + r_fill_state.curr_batch->first_command += r_fill_state.transform_extra_command_number_p1 - 1; + } + // we do have a pending extra transform command to flush // either the extra transform is in the prior command, or not, in which case we need 2 batches r_fill_state.curr_batch->num_commands += 2;