From b590f5ff52ba068eed51563da1708df0ee3f2e5d Mon Sep 17 00:00:00 2001 From: lawnjelly Date: Thu, 11 Mar 2021 15:53:43 +0000 Subject: [PATCH] Batching - large FVF forces non-hardware transform This is something that I missed from the initial implementation of large FVF. In large FVF the transform is sent per vertex in an attribute, and the vertex position is the original vertex position. This is so that the original vertex position can be read and modified in a custom shader. This whole system is therefore incompatible with the legacy hardware transform method, whereby the transform is sent in a uniform. The shader already correctly ignores the uniform transform, but there are some parts of the CPU side logic that can be confused treating large FVF batches as if they were hardware transform. This PR completes the logic by making the CPU treat large FVF as though it was software transform. --- drivers/gles_common/rasterizer_canvas_batcher.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gles_common/rasterizer_canvas_batcher.h b/drivers/gles_common/rasterizer_canvas_batcher.h index d183c3ffe9a..56dd4252e65 100644 --- a/drivers/gles_common/rasterizer_canvas_batcher.h +++ b/drivers/gles_common/rasterizer_canvas_batcher.h @@ -227,7 +227,7 @@ public: // we are always splitting items with lots of commands, // and items with unhandled primitives (default) - bool use_hardware_transform() const { return num_item_refs == 1; } + bool use_hardware_transform() const { return (num_item_refs == 1) && !(flags & RasterizerStorageCommon::USE_LARGE_FVF); } }; struct BItemRef {