2017-12-04 13:41:34 +01:00
|
|
|
/*************************************************************************/
|
|
|
|
/* rasterizer_canvas_gles2.h */
|
|
|
|
/*************************************************************************/
|
|
|
|
/* This file is part of: */
|
|
|
|
/* GODOT ENGINE */
|
|
|
|
/* https://godotengine.org */
|
|
|
|
/*************************************************************************/
|
2021-01-01 20:13:46 +01:00
|
|
|
/* Copyright (c) 2007-2021 Juan Linietsky, Ariel Manzur. */
|
|
|
|
/* Copyright (c) 2014-2021 Godot Engine contributors (cf. AUTHORS.md). */
|
2017-12-04 13:41:34 +01:00
|
|
|
/* */
|
|
|
|
/* Permission is hereby granted, free of charge, to any person obtaining */
|
|
|
|
/* a copy of this software and associated documentation files (the */
|
|
|
|
/* "Software"), to deal in the Software without restriction, including */
|
|
|
|
/* without limitation the rights to use, copy, modify, merge, publish, */
|
|
|
|
/* distribute, sublicense, and/or sell copies of the Software, and to */
|
|
|
|
/* permit persons to whom the Software is furnished to do so, subject to */
|
|
|
|
/* the following conditions: */
|
|
|
|
/* */
|
|
|
|
/* The above copyright notice and this permission notice shall be */
|
|
|
|
/* included in all copies or substantial portions of the Software. */
|
|
|
|
/* */
|
|
|
|
/* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, */
|
|
|
|
/* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF */
|
|
|
|
/* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.*/
|
|
|
|
/* IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY */
|
|
|
|
/* CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, */
|
|
|
|
/* TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE */
|
|
|
|
/* SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */
|
|
|
|
/*************************************************************************/
|
2019-01-01 12:46:36 +01:00
|
|
|
|
2017-12-04 13:41:34 +01:00
|
|
|
#ifndef RASTERIZERCANVASGLES2_H
|
|
|
|
#define RASTERIZERCANVASGLES2_H
|
|
|
|
|
2020-10-14 09:32:05 +02:00
|
|
|
#include "drivers/gles_common/rasterizer_canvas_batcher.h"
|
2020-03-27 10:19:37 +01:00
|
|
|
#include "rasterizer_canvas_base_gles2.h"
|
2017-12-04 13:41:34 +01:00
|
|
|
|
|
|
|
class RasterizerSceneGLES2;
|
|
|
|
|
2020-10-14 09:32:05 +02:00
|
|
|
class RasterizerCanvasGLES2 : public RasterizerCanvasBaseGLES2, public RasterizerCanvasBatcher<RasterizerCanvasGLES2, RasterizerStorageGLES2> {
|
2017-12-04 13:41:34 +01:00
|
|
|
|
2020-10-14 09:32:05 +02:00
|
|
|
friend class RasterizerCanvasBatcher<RasterizerCanvasGLES2, RasterizerStorageGLES2>;
|
2017-12-04 13:41:34 +01:00
|
|
|
|
2020-03-27 10:19:37 +01:00
|
|
|
public:
|
2020-04-12 14:52:25 +02:00
|
|
|
virtual void canvas_render_items_begin(const Color &p_modulate, Light *p_light, const Transform2D &p_base_transform);
|
|
|
|
virtual void canvas_render_items_end();
|
2017-12-04 13:41:34 +01:00
|
|
|
virtual void canvas_render_items(Item *p_item_list, int p_z, const Color &p_modulate, Light *p_light, const Transform2D &p_base_transform);
|
2020-04-17 09:44:12 +02:00
|
|
|
virtual void canvas_begin();
|
GLES2 2D batching - item reordering, light joining and light modulate fix
Although 2D draws in painters order with strict ordering, in certain circumstances items can be reordered to increase batching / decrease state changes, without affecting the end result. This can be determined by an overlap test.
In situation with item:
A-B-A
providing the third item does not overlap the second, they can be reordered:
A-A-B
Items already contain an AABB which can be used for this overlap test.
1)
To utilise this, I have implemented item reordering (only for single rects for now), with the lookahead adjustable in project settings. This can increase performance in situations where items may not be grouped in the scene tree by texture. It can also be switched off (by setting lookahead to 0).
2)
This same trick can be used to help join items that are lit. Lit items previously would prevent joining completely, thus missing out on performance gains other than multi-command items such as tilemaps.
In this PR, lights are assigned as bits in a bitfield (up to 64, the optimization is disabled above this), and on each try_item (for joining), the bitfield for lights and shadows is constructed and compared with the previous items. If these match the 2 items can potentially be joined. However, this can only be done without changing the rendered result if an overlap test is successful.
This overlap test can be adjusted to join items up to a specific number of item references, selectable in project settings, or turned off.
3)
The legacy uniform single rect drawing routine seems to have been identified as the source of flicker, particularly on nvidia. However, it can also be up to 2x as fast. Because of the speed the batching contains a fallback where it can use the legacy single rect method, but I have now added a project setting to make this switchable. In most cases with batching it should not be necessary (as single rects are drawn less frequently) and thus the flickering can be totally avoided.
4)
This PR also fixes a color modulate bug when drawing light passes, in certain situations (particularly custom _draw routines with multiple rects).
5)
This PR also fixes #38291, a bug in the legacy renderer where light passes could draw rects in wrong position.
2020-04-29 09:24:43 +02:00
|
|
|
virtual void canvas_end();
|
2017-12-04 13:41:34 +01:00
|
|
|
|
2020-03-27 10:19:37 +01:00
|
|
|
private:
|
|
|
|
// legacy codepath .. to remove after testing
|
2020-10-14 09:32:05 +02:00
|
|
|
void _legacy_canvas_render_item(Item *p_ci, RenderItemState &r_ris);
|
2020-03-27 10:19:37 +01:00
|
|
|
|
|
|
|
// high level batch funcs
|
|
|
|
void canvas_render_items_implementation(Item *p_item_list, int p_z, const Color &p_modulate, Light *p_light, const Transform2D &p_base_transform);
|
|
|
|
void render_joined_item(const BItemJoined &p_bij, RenderItemState &r_ris);
|
|
|
|
bool try_join_item(Item *p_ci, RenderItemState &r_ris, bool &r_batch_break);
|
2021-04-12 17:55:59 +02:00
|
|
|
void render_batches(Item *p_current_clip, bool &r_reclip, RasterizerStorageGLES2::Material *p_material);
|
2020-08-15 15:31:16 +02:00
|
|
|
|
2020-03-27 10:19:37 +01:00
|
|
|
// low level batch funcs
|
|
|
|
void _batch_upload_buffers();
|
2020-11-12 20:16:33 +01:00
|
|
|
void _batch_render_generic(const Batch &p_batch, RasterizerStorageGLES2::Material *p_material);
|
2020-10-14 09:32:05 +02:00
|
|
|
void _batch_render_lines(const Batch &p_batch, RasterizerStorageGLES2::Material *p_material, bool p_anti_alias);
|
GLES2 2D batching - item reordering, light joining and light modulate fix
Although 2D draws in painters order with strict ordering, in certain circumstances items can be reordered to increase batching / decrease state changes, without affecting the end result. This can be determined by an overlap test.
In situation with item:
A-B-A
providing the third item does not overlap the second, they can be reordered:
A-A-B
Items already contain an AABB which can be used for this overlap test.
1)
To utilise this, I have implemented item reordering (only for single rects for now), with the lookahead adjustable in project settings. This can increase performance in situations where items may not be grouped in the scene tree by texture. It can also be switched off (by setting lookahead to 0).
2)
This same trick can be used to help join items that are lit. Lit items previously would prevent joining completely, thus missing out on performance gains other than multi-command items such as tilemaps.
In this PR, lights are assigned as bits in a bitfield (up to 64, the optimization is disabled above this), and on each try_item (for joining), the bitfield for lights and shadows is constructed and compared with the previous items. If these match the 2 items can potentially be joined. However, this can only be done without changing the rendered result if an overlap test is successful.
This overlap test can be adjusted to join items up to a specific number of item references, selectable in project settings, or turned off.
3)
The legacy uniform single rect drawing routine seems to have been identified as the source of flicker, particularly on nvidia. However, it can also be up to 2x as fast. Because of the speed the batching contains a fallback where it can use the legacy single rect method, but I have now added a project setting to make this switchable. In most cases with batching it should not be necessary (as single rects are drawn less frequently) and thus the flickering can be totally avoided.
4)
This PR also fixes a color modulate bug when drawing light passes, in certain situations (particularly custom _draw routines with multiple rects).
5)
This PR also fixes #38291, a bug in the legacy renderer where light passes could draw rects in wrong position.
2020-04-29 09:24:43 +02:00
|
|
|
|
2020-10-14 09:32:05 +02:00
|
|
|
// funcs used from rasterizer_canvas_batcher template
|
|
|
|
void gl_enable_scissor(int p_x, int p_y, int p_width, int p_height) const;
|
|
|
|
void gl_disable_scissor() const;
|
2020-04-17 09:44:12 +02:00
|
|
|
|
2020-03-27 10:19:37 +01:00
|
|
|
public:
|
2017-12-04 13:41:34 +01:00
|
|
|
void initialize();
|
|
|
|
RasterizerCanvasGLES2();
|
|
|
|
};
|
|
|
|
|
|
|
|
#endif // RASTERIZERCANVASGLES2_H
|