Tilemap: Use vertex shader based autotile animation strategy
Previously, we would just stuff the entire tilemap vertex data
four times into the buffers, with only the autotile vertices
offset according to the animation frame. This meant we could
prepare the buffers once, and then just bind a different offset
for each animation frame without any shader changes, but it also
lead to a huge amount of data being duplicated (and blowing up
the buffer sizes).
The new method only requires one buffer, and instead animates by
recognizing vertices belonging to autotiles in a custom vertex
shader, which offsets them on the fly according to the animation
index.
With giant tilemaps, this method would turn out to be a little
less efficient, but considering the Tilemap is planned to be
rewritten to only hold the range of tiles visible on the screen
in its buffers, the on the fly offsetting will become neglient,
while at the same time the amount of data we have to send to the
GPU everytime the tilemap is updated is greatly reduced; so a
net win in the end.
2014-07-06 17:44:19 +00:00
|
|
|
|
|
|
|
uniform mat4 projMat;
|
|
|
|
|
|
|
|
uniform vec2 texSizeInv;
|
|
|
|
uniform vec2 translation;
|
|
|
|
|
|
|
|
uniform float aniIndex;
|
|
|
|
|
2019-05-12 15:52:05 +00:00
|
|
|
uniform float t1Ani;
|
|
|
|
uniform float t2Ani;
|
|
|
|
uniform float t3Ani;
|
|
|
|
uniform float t4Ani;
|
|
|
|
uniform float t5Ani;
|
|
|
|
uniform float t6Ani;
|
|
|
|
uniform float t7Ani;
|
|
|
|
|
Tilemap: Use vertex shader based autotile animation strategy
Previously, we would just stuff the entire tilemap vertex data
four times into the buffers, with only the autotile vertices
offset according to the animation frame. This meant we could
prepare the buffers once, and then just bind a different offset
for each animation frame without any shader changes, but it also
lead to a huge amount of data being duplicated (and blowing up
the buffer sizes).
The new method only requires one buffer, and instead animates by
recognizing vertices belonging to autotiles in a custom vertex
shader, which offsets them on the fly according to the animation
index.
With giant tilemaps, this method would turn out to be a little
less efficient, but considering the Tilemap is planned to be
rewritten to only hold the range of tiles visible on the screen
in its buffers, the on the fly offsetting will become neglient,
while at the same time the amount of data we have to send to the
GPU everytime the tilemap is updated is greatly reduced; so a
net win in the end.
2014-07-06 17:44:19 +00:00
|
|
|
attribute vec2 position;
|
|
|
|
attribute vec2 texCoord;
|
|
|
|
|
|
|
|
varying vec2 v_texCoord;
|
|
|
|
|
|
|
|
const float atAreaW = 96.0;
|
|
|
|
const float atAreaH = 128.0*7.0;
|
|
|
|
const float atAniOffset = 32.0*3.0;
|
|
|
|
|
|
|
|
void main()
|
|
|
|
{
|
|
|
|
vec2 tex = texCoord;
|
2014-12-23 18:00:14 +00:00
|
|
|
|
|
|
|
lowp float pred = float(tex.x <= atAreaW && tex.y <= atAreaH);
|
2019-05-12 15:52:05 +00:00
|
|
|
|
|
|
|
highp int tileIndex = int(tex.y / 128.0) + 1;
|
|
|
|
|
|
|
|
if ((tileIndex == 1 && t1Ani >= 1.0) ||
|
|
|
|
(tileIndex == 2 && t2Ani >= 1.0) ||
|
|
|
|
(tileIndex == 3 && t3Ani >= 1.0) ||
|
|
|
|
(tileIndex == 4 && t4Ani >= 1.0) ||
|
|
|
|
(tileIndex == 5 && t5Ani >= 1.0) ||
|
|
|
|
(tileIndex == 6 && t6Ani >= 1.0) ||
|
|
|
|
(tileIndex == 7 && t7Ani >= 1.0))
|
2014-12-23 18:00:14 +00:00
|
|
|
tex.x += aniIndex * atAniOffset * pred;
|
Tilemap: Use vertex shader based autotile animation strategy
Previously, we would just stuff the entire tilemap vertex data
four times into the buffers, with only the autotile vertices
offset according to the animation frame. This meant we could
prepare the buffers once, and then just bind a different offset
for each animation frame without any shader changes, but it also
lead to a huge amount of data being duplicated (and blowing up
the buffer sizes).
The new method only requires one buffer, and instead animates by
recognizing vertices belonging to autotiles in a custom vertex
shader, which offsets them on the fly according to the animation
index.
With giant tilemaps, this method would turn out to be a little
less efficient, but considering the Tilemap is planned to be
rewritten to only hold the range of tiles visible on the screen
in its buffers, the on the fly offsetting will become neglient,
while at the same time the amount of data we have to send to the
GPU everytime the tilemap is updated is greatly reduced; so a
net win in the end.
2014-07-06 17:44:19 +00:00
|
|
|
|
|
|
|
gl_Position = projMat * vec4(position + translation, 0, 1);
|
|
|
|
|
|
|
|
v_texCoord = tex * texSizeInv;
|
|
|
|
}
|