2013-09-01 14:27:21 +00:00
|
|
|
/*
|
|
|
|
** tilemap.cpp
|
|
|
|
**
|
|
|
|
** This file is part of mkxp.
|
|
|
|
**
|
|
|
|
** Copyright (C) 2013 Jonas Kulla <Nyocurio@gmail.com>
|
|
|
|
**
|
|
|
|
** mkxp is free software: you can redistribute it and/or modify
|
|
|
|
** it under the terms of the GNU General Public License as published by
|
|
|
|
** the Free Software Foundation, either version 2 of the License, or
|
|
|
|
** (at your option) any later version.
|
|
|
|
**
|
|
|
|
** mkxp is distributed in the hope that it will be useful,
|
|
|
|
** but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
** MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
** GNU General Public License for more details.
|
|
|
|
**
|
|
|
|
** You should have received a copy of the GNU General Public License
|
|
|
|
** along with mkxp. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "tilemap.h"
|
|
|
|
|
|
|
|
#include "viewport.h"
|
|
|
|
#include "bitmap.h"
|
|
|
|
#include "table.h"
|
|
|
|
|
2013-10-09 10:30:33 +00:00
|
|
|
#include "sharedstate.h"
|
2013-09-01 14:27:21 +00:00
|
|
|
#include "glstate.h"
|
|
|
|
#include "gl-util.h"
|
2014-07-11 06:31:12 +00:00
|
|
|
#include "gl-meta.h"
|
2014-07-11 00:09:53 +00:00
|
|
|
#include "global-ibo.h"
|
2013-09-01 14:27:21 +00:00
|
|
|
#include "etc-internal.h"
|
|
|
|
#include "quadarray.h"
|
|
|
|
#include "texpool.h"
|
|
|
|
#include "quad.h"
|
2014-07-13 12:03:18 +00:00
|
|
|
#include "vertex.h"
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
#include "tileatlas.h"
|
2014-10-26 19:00:56 +00:00
|
|
|
#include "flashmap.h"
|
2013-09-01 14:27:21 +00:00
|
|
|
|
2013-12-04 16:48:37 +00:00
|
|
|
#include <sigc++/connection.h>
|
2013-09-01 14:27:21 +00:00
|
|
|
|
|
|
|
#include <string.h>
|
|
|
|
#include <stdint.h>
|
2013-12-08 12:19:22 +00:00
|
|
|
#include <algorithm>
|
2013-12-26 19:18:33 +00:00
|
|
|
#include <vector>
|
2013-09-01 14:27:21 +00:00
|
|
|
|
2013-12-04 16:48:37 +00:00
|
|
|
#include <SDL_surface.h>
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
|
2013-09-01 14:27:21 +00:00
|
|
|
extern const StaticRect autotileRects[];
|
|
|
|
|
2013-12-26 19:18:33 +00:00
|
|
|
typedef std::vector<SVertex> SVVector;
|
2013-09-01 14:27:21 +00:00
|
|
|
|
|
|
|
static const int tilesetW = 8 * 32;
|
|
|
|
static const int autotileW = 3 * 32;
|
|
|
|
static const int autotileH = 4 * 32;
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
|
|
|
|
static const int autotileCount = 7;
|
|
|
|
|
|
|
|
static const int atAreaW = autotileW * 4;
|
|
|
|
static const int atAreaH = autotileH * autotileCount;
|
|
|
|
|
|
|
|
static const int tsLaneW = tilesetW / 2;
|
2013-09-01 14:27:21 +00:00
|
|
|
|
2014-07-10 23:07:18 +00:00
|
|
|
/* Map viewport size */
|
|
|
|
static const int viewpW = 21;
|
|
|
|
static const int viewpH = 16;
|
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
static const size_t zlayersMax = viewpH + 5;
|
2014-07-10 23:07:18 +00:00
|
|
|
|
2013-09-01 14:27:21 +00:00
|
|
|
/* Vocabulary:
|
|
|
|
*
|
|
|
|
* Atlas: A texture containing both the tileset and all
|
|
|
|
* autotile images. This is so the entire tilemap can
|
|
|
|
* be drawn from one texture (for performance reasons).
|
|
|
|
* This means that we have to watch the 'modified' signals
|
|
|
|
* of all Bitmaps that make up the atlas, and update it
|
|
|
|
* as required during runtime.
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
* The atlas is tightly packed, with the autotiles located
|
|
|
|
* in the top left corener and the tileset image filing the
|
|
|
|
* remaining open space (below the autotiles as well as
|
|
|
|
* besides it). The tileset is vertically cut in half, where
|
|
|
|
* the first half fills available texture space, and then the
|
|
|
|
* other half (as if the right half was cut and pasted below
|
|
|
|
* the left half before fitting it all into the atlas).
|
|
|
|
* Internally these halves are called "tileset lanes".
|
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
|
|
|
* There is a 32 pixel wide empty buffer below the autotile
|
|
|
|
* area so the vertex shader can safely differentiate between
|
|
|
|
* autotile and tileset vertices (relevant for autotile animation).
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
*
|
|
|
|
* Tile atlas
|
|
|
|
* *-----------------------*--------------*
|
|
|
|
* | | | | | ¦ |
|
2014-08-17 01:58:01 +00:00
|
|
|
* | AT0 | AT0 | AT0 | AT0 | ¦ |
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
* | FR0 | FR1 | FR2 | FR3 | | ¦ | |
|
|
|
|
* |-----|-----|-----|-----| v ¦ v |
|
|
|
|
* | | | | | ¦ |
|
|
|
|
* | AT1 | | | | ¦ |
|
|
|
|
* | | | | | ¦ |
|
|
|
|
* |-----|-----|-----|-----| ¦ |
|
|
|
|
* |[...]| | | | ¦ |
|
|
|
|
* |-----|-----|-----|-----| ¦ |
|
|
|
|
* | | | | | | ¦ | |
|
2014-08-17 01:58:01 +00:00
|
|
|
* | AT6 | | | | v ¦ v |
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
* | | | | | ¦ |
|
|
|
|
* |-----|-----|-----|-----| ¦ |
|
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
|
|
|
* | Empty space | | |
|
|
|
|
* |-----------------------| | |
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
* | ¦ ¦ ¦ ¦ |
|
|
|
|
* | Tile- ¦ | ¦ | ¦ ¦ |
|
|
|
|
* | set ¦ v ¦ v ¦ ¦ |
|
|
|
|
* | ¦ ¦ ¦ | ¦ | |
|
|
|
|
* | | ¦ ¦ ¦ v ¦ v |
|
|
|
|
* | v ¦ | ¦ | ¦ ¦ |
|
|
|
|
* | ¦ v ¦ v ¦ ¦ |
|
|
|
|
* | ¦ ¦ ¦ ¦ |
|
|
|
|
* *---------------------------------------*
|
2013-09-01 14:27:21 +00:00
|
|
|
*
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
* When allocating the atlas size, we first expand vertically
|
|
|
|
* until all the space immediately below the autotile area
|
|
|
|
* is used up, and then, when the max texture size
|
|
|
|
* is reached, horizontally.
|
2013-09-01 14:27:21 +00:00
|
|
|
*
|
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
|
|
|
* To animate the autotiles, we catch any autotile vertices in
|
|
|
|
* the tilemap shader based on their texcoord, and offset them
|
|
|
|
* horizontally by (animation index) * (autotile frame width = 96).
|
2013-09-01 14:27:21 +00:00
|
|
|
*
|
|
|
|
* Elements:
|
|
|
|
* Even though the Tilemap carries similarities with other
|
|
|
|
* SceneElements, it is not one itself but composed of multiple
|
2014-08-17 01:58:01 +00:00
|
|
|
* such elements (GroundLayer and ZLayers).
|
2013-09-01 14:27:21 +00:00
|
|
|
*
|
|
|
|
* GroundLayer:
|
|
|
|
* Every tile with priority=0 is drawn at z=0, so we
|
|
|
|
* collect all such tiles in one big quad array and
|
|
|
|
* draw them at once.
|
|
|
|
*
|
2014-08-17 01:58:01 +00:00
|
|
|
* ZLayer:
|
2013-09-01 14:27:21 +00:00
|
|
|
* Each tile in row n with priority=m is drawn at the same
|
|
|
|
* z as every tile in row n-1 with priority=m-1. This means
|
|
|
|
* we can collect all tiles sharing the same z in one quad
|
|
|
|
* array and draw them at once. I call these collections
|
2014-08-17 01:58:01 +00:00
|
|
|
* 'zlayers'. They're drawn from the top part of the map
|
2013-09-01 14:27:21 +00:00
|
|
|
* (lowest z) to the bottom part (highest z).
|
2014-08-17 01:58:01 +00:00
|
|
|
* Objects that would end up on the same zlayer are eg. trees.
|
2013-09-01 14:27:21 +00:00
|
|
|
*
|
2014-07-10 23:07:18 +00:00
|
|
|
* Map viewport:
|
|
|
|
* This rectangle describes the subregion of the map that is
|
|
|
|
* actually translated to vertices and stored on the GPU ready
|
|
|
|
* for rendering. Whenever, ox/oy are modified, its position is
|
|
|
|
* adjusted if necessary and the data is regenerated. Its size
|
|
|
|
* is fixed. This is NOT related to the RGSS Viewport class!
|
2013-09-01 14:27:21 +00:00
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
2013-10-09 09:52:39 +00:00
|
|
|
/* Autotile animation */
|
|
|
|
static const uint8_t atAnimation[16*4] =
|
|
|
|
{
|
|
|
|
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
|
|
|
|
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
|
|
|
|
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
|
|
|
|
3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3
|
|
|
|
};
|
|
|
|
|
|
|
|
static elementsN(atAnimation);
|
|
|
|
|
|
|
|
/* Flash tiles pulsing opacity */
|
2013-09-23 06:27:28 +00:00
|
|
|
static const uint8_t flashAlpha[] =
|
|
|
|
{
|
|
|
|
/* Fade in */
|
|
|
|
0x3C, 0x3C, 0x3C, 0x3C, 0x4B, 0x4B, 0x4B, 0x4B,
|
|
|
|
0x5A, 0x5A, 0x5A, 0x5A, 0x69, 0x69, 0x69, 0x69,
|
|
|
|
/* Fade out */
|
|
|
|
0x78, 0x78, 0x78, 0x78, 0x69, 0x69, 0x69, 0x69,
|
|
|
|
0x5A, 0x5A, 0x5A, 0x5A, 0x4B, 0x4B, 0x4B, 0x4B
|
|
|
|
};
|
|
|
|
|
|
|
|
static elementsN(flashAlpha);
|
|
|
|
|
2013-09-01 14:27:21 +00:00
|
|
|
struct GroundLayer : public ViewportElement
|
|
|
|
{
|
|
|
|
GLsizei vboCount;
|
|
|
|
TilemapPrivate *p;
|
|
|
|
|
|
|
|
GroundLayer(TilemapPrivate *p, Viewport *viewport);
|
|
|
|
|
2014-07-10 23:07:18 +00:00
|
|
|
void updateVboCount();
|
|
|
|
|
2013-09-01 14:27:21 +00:00
|
|
|
void draw();
|
|
|
|
void drawInt();
|
|
|
|
|
|
|
|
void onGeometryChange(const Scene::Geometry &geo);
|
2014-09-23 19:12:58 +00:00
|
|
|
|
|
|
|
ABOUT_TO_ACCESS_NOOP
|
2013-09-01 14:27:21 +00:00
|
|
|
};
|
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
struct ZLayer : public ViewportElement
|
2013-09-01 14:27:21 +00:00
|
|
|
{
|
2014-07-10 23:07:18 +00:00
|
|
|
size_t index;
|
2013-09-01 14:27:21 +00:00
|
|
|
GLintptr vboOffset;
|
|
|
|
GLsizei vboCount;
|
|
|
|
TilemapPrivate *p;
|
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
/* If this layer is part of a batch and not
|
2013-10-13 20:00:38 +00:00
|
|
|
* the head, it is 'muted' via this flag */
|
|
|
|
bool batchedFlag;
|
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
/* If this layer is a batch head, this variable
|
2013-10-13 20:00:38 +00:00
|
|
|
* holds the element count of the entire batch */
|
|
|
|
GLsizei vboBatchCount;
|
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
ZLayer(TilemapPrivate *p, Viewport *viewport);
|
2014-07-10 23:07:18 +00:00
|
|
|
|
|
|
|
void setIndex(int value);
|
2013-09-01 14:27:21 +00:00
|
|
|
|
|
|
|
void draw();
|
|
|
|
void drawInt();
|
|
|
|
|
2014-07-10 23:07:18 +00:00
|
|
|
static int calculateZ(TilemapPrivate *p, int index);
|
|
|
|
|
2013-09-27 02:42:22 +00:00
|
|
|
void initUpdateZ();
|
2014-08-17 01:58:01 +00:00
|
|
|
void finiUpdateZ(ZLayer *prev);
|
2014-09-23 19:12:58 +00:00
|
|
|
|
|
|
|
ABOUT_TO_ACCESS_NOOP
|
2013-09-01 14:27:21 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct TilemapPrivate
|
|
|
|
{
|
|
|
|
Viewport *viewport;
|
|
|
|
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
Bitmap *autotiles[autotileCount];
|
2013-09-01 14:27:21 +00:00
|
|
|
|
|
|
|
Bitmap *tileset;
|
2014-08-09 16:35:01 +00:00
|
|
|
|
2013-09-01 14:27:21 +00:00
|
|
|
Table *mapData;
|
|
|
|
Table *priorities;
|
|
|
|
bool visible;
|
|
|
|
Vec2i offset;
|
|
|
|
|
|
|
|
Vec2i dispPos;
|
|
|
|
|
|
|
|
/* Tile atlas */
|
|
|
|
struct {
|
2013-09-06 10:26:41 +00:00
|
|
|
TEXFBO gl;
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
|
|
|
|
Vec2i size;
|
|
|
|
|
2013-09-29 23:38:46 +00:00
|
|
|
/* Effective tileset height,
|
|
|
|
* clamped to a multiple of 32 */
|
|
|
|
int efTilesetH;
|
|
|
|
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
/* Indices of usable
|
|
|
|
* (not null, not disposed) autotiles */
|
2013-12-26 19:18:33 +00:00
|
|
|
std::vector<uint8_t> usableATs;
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
|
2013-09-01 14:27:21 +00:00
|
|
|
/* Indices of animated autotiles */
|
2013-12-26 19:18:33 +00:00
|
|
|
std::vector<uint8_t> animatedATs;
|
2013-09-01 14:27:21 +00:00
|
|
|
} atlas;
|
|
|
|
|
2014-07-10 23:07:18 +00:00
|
|
|
/* Map viewport position */
|
|
|
|
Vec2i viewpPos;
|
2013-09-01 14:27:21 +00:00
|
|
|
|
|
|
|
/* Ground layer vertices */
|
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
|
|
|
SVVector groundVert;
|
2013-09-01 14:27:21 +00:00
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
/* ZLayer vertices */
|
|
|
|
SVVector zlayerVert[zlayersMax];
|
2013-09-01 14:27:21 +00:00
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
/* Base quad indices of each zlayer
|
2013-09-01 14:27:21 +00:00
|
|
|
* in the shared buffer */
|
2014-08-17 01:58:01 +00:00
|
|
|
size_t zlayerBases[zlayersMax+1];
|
2013-09-01 14:27:21 +00:00
|
|
|
|
|
|
|
/* Shared buffers for all tiles */
|
|
|
|
struct
|
|
|
|
{
|
2014-07-13 12:03:18 +00:00
|
|
|
GLMeta::VAO vao;
|
2013-09-01 14:27:21 +00:00
|
|
|
VBO::ID vbo;
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
bool animated;
|
|
|
|
|
|
|
|
/* Animation state */
|
|
|
|
uint8_t frameIdx;
|
|
|
|
uint8_t aniIdx;
|
2013-09-01 14:27:21 +00:00
|
|
|
} tiles;
|
|
|
|
|
2014-10-26 19:00:56 +00:00
|
|
|
FlashMap flashMap;
|
|
|
|
uint8_t flashAlphaIdx;
|
2013-09-01 14:27:21 +00:00
|
|
|
|
|
|
|
/* Scene elements */
|
|
|
|
struct
|
|
|
|
{
|
|
|
|
GroundLayer *ground;
|
2014-08-17 01:58:01 +00:00
|
|
|
ZLayer* zlayers[zlayersMax];
|
|
|
|
/* Used layers out of 'zlayers' (rest is hidden) */
|
|
|
|
size_t activeLayers;
|
2013-09-01 14:27:21 +00:00
|
|
|
Scene::Geometry sceneGeo;
|
|
|
|
Vec2i sceneOffset;
|
|
|
|
} elem;
|
|
|
|
|
|
|
|
/* Affected by: autotiles, tileset */
|
|
|
|
bool atlasSizeDirty;
|
|
|
|
/* Affected by: autotiles(.changed), tileset(.changed), allocateAtlas */
|
|
|
|
bool atlasDirty;
|
|
|
|
/* Affected by: mapData(.changed), priorities(.changed) */
|
|
|
|
bool buffersDirty;
|
2014-07-10 23:07:18 +00:00
|
|
|
/* Affected by: ox, oy */
|
|
|
|
bool mapViewportDirty;
|
2013-09-01 14:27:21 +00:00
|
|
|
/* Affected by: oy */
|
|
|
|
bool zOrderDirty;
|
|
|
|
|
|
|
|
/* Resources are sufficient and tilemap is ready to be drawn */
|
|
|
|
bool tilemapReady;
|
|
|
|
|
|
|
|
/* Change watches */
|
|
|
|
sigc::connection tilesetCon;
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
sigc::connection autotilesCon[autotileCount];
|
2013-09-01 14:27:21 +00:00
|
|
|
sigc::connection mapDataCon;
|
|
|
|
sigc::connection prioritiesCon;
|
|
|
|
|
|
|
|
/* Dispose watches */
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
sigc::connection autotilesDispCon[autotileCount];
|
2013-09-01 14:27:21 +00:00
|
|
|
|
|
|
|
/* Draw prepare call */
|
|
|
|
sigc::connection prepareCon;
|
|
|
|
|
|
|
|
TilemapPrivate(Viewport *viewport)
|
|
|
|
: viewport(viewport),
|
|
|
|
tileset(0),
|
|
|
|
mapData(0),
|
|
|
|
priorities(0),
|
|
|
|
visible(true),
|
2014-10-26 19:00:56 +00:00
|
|
|
flashAlphaIdx(0),
|
2013-09-01 14:27:21 +00:00
|
|
|
atlasSizeDirty(false),
|
|
|
|
atlasDirty(false),
|
|
|
|
buffersDirty(false),
|
2014-07-10 23:07:18 +00:00
|
|
|
mapViewportDirty(false),
|
2013-09-01 14:27:21 +00:00
|
|
|
zOrderDirty(false),
|
|
|
|
tilemapReady(false)
|
|
|
|
{
|
|
|
|
memset(autotiles, 0, sizeof(autotiles));
|
|
|
|
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
atlas.animatedATs.reserve(autotileCount);
|
2013-09-29 23:38:46 +00:00
|
|
|
atlas.efTilesetH = 0;
|
|
|
|
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
tiles.animated = false;
|
|
|
|
tiles.frameIdx = 0;
|
|
|
|
tiles.aniIdx = 0;
|
2013-09-01 14:27:21 +00:00
|
|
|
|
|
|
|
/* Init tile buffers */
|
|
|
|
tiles.vbo = VBO::gen();
|
|
|
|
|
2014-07-13 12:03:18 +00:00
|
|
|
GLMeta::vaoFillInVertexData<SVertex>(tiles.vao);
|
|
|
|
tiles.vao.vbo = tiles.vbo;
|
|
|
|
tiles.vao.ibo = shState->globalIBO().ibo;
|
2013-09-23 05:15:01 +00:00
|
|
|
|
2014-07-13 12:03:18 +00:00
|
|
|
GLMeta::vaoInit(tiles.vao);
|
2013-09-01 14:27:21 +00:00
|
|
|
|
2014-07-10 23:07:18 +00:00
|
|
|
elem.ground = new GroundLayer(this, viewport);
|
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
for (size_t i = 0; i < zlayersMax; ++i)
|
|
|
|
elem.zlayers[i] = new ZLayer(this, viewport);
|
2014-07-10 23:07:18 +00:00
|
|
|
|
2013-10-09 10:30:33 +00:00
|
|
|
prepareCon = shState->prepareDraw.connect
|
2013-09-01 14:27:21 +00:00
|
|
|
(sigc::mem_fun(this, &TilemapPrivate::prepare));
|
2014-10-26 19:00:56 +00:00
|
|
|
|
|
|
|
updateFlashMapViewport();
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
~TilemapPrivate()
|
|
|
|
{
|
2014-07-10 23:07:18 +00:00
|
|
|
/* Destroy elements */
|
|
|
|
delete elem.ground;
|
2014-08-17 01:58:01 +00:00
|
|
|
for (size_t i = 0; i < zlayersMax; ++i)
|
|
|
|
delete elem.zlayers[i];
|
2013-09-01 14:27:21 +00:00
|
|
|
|
2013-10-22 04:36:13 +00:00
|
|
|
shState->releaseAtlasTex(atlas.gl);
|
2014-07-10 23:07:18 +00:00
|
|
|
|
|
|
|
/* Destroy tile buffers */
|
2014-07-13 12:03:18 +00:00
|
|
|
GLMeta::vaoFini(tiles.vao);
|
2013-09-01 14:27:21 +00:00
|
|
|
VBO::del(tiles.vbo);
|
|
|
|
|
2014-07-10 23:07:18 +00:00
|
|
|
/* Disconnect signal handlers */
|
2013-09-01 14:27:21 +00:00
|
|
|
tilesetCon.disconnect();
|
2014-07-19 00:58:57 +00:00
|
|
|
for (int i = 0; i < autotileCount; ++i)
|
2013-09-01 14:27:21 +00:00
|
|
|
{
|
|
|
|
autotilesCon[i].disconnect();
|
|
|
|
autotilesDispCon[i].disconnect();
|
|
|
|
}
|
|
|
|
mapDataCon.disconnect();
|
|
|
|
prioritiesCon.disconnect();
|
|
|
|
|
|
|
|
prepareCon.disconnect();
|
|
|
|
}
|
|
|
|
|
2014-10-26 19:00:56 +00:00
|
|
|
void updateFlashMapViewport()
|
|
|
|
{
|
|
|
|
flashMap.setViewport(IntRect(viewpPos.x, viewpPos.y, viewpW, viewpH));
|
|
|
|
}
|
|
|
|
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
void updateAtlasInfo()
|
|
|
|
{
|
2014-09-23 19:12:58 +00:00
|
|
|
if (nullOrDisposed(tileset))
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
{
|
|
|
|
atlas.size = Vec2i();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-09-29 23:38:46 +00:00
|
|
|
int tsH = tileset->height();
|
|
|
|
atlas.efTilesetH = tsH - (tsH % 32);
|
|
|
|
|
|
|
|
atlas.size = TileAtlas::minSize(atlas.efTilesetH, glState.caps.maxTexSize);
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
|
|
|
|
if (atlas.size.x < 0)
|
|
|
|
throw Exception(Exception::MKXPError,
|
|
|
|
"Cannot allocate big enough texture for tileset atlas");
|
|
|
|
}
|
|
|
|
|
|
|
|
void updateAutotileInfo()
|
|
|
|
{
|
|
|
|
/* Check if and which autotiles are animated */
|
2013-12-26 19:18:33 +00:00
|
|
|
std::vector<uint8_t> &usableATs = atlas.usableATs;
|
|
|
|
std::vector<uint8_t> &animatedATs = atlas.animatedATs;
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
|
|
|
|
usableATs.clear();
|
|
|
|
|
2014-07-19 00:58:57 +00:00
|
|
|
for (int i = 0; i < autotileCount; ++i)
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
{
|
2014-09-23 19:12:58 +00:00
|
|
|
if (nullOrDisposed(autotiles[i]))
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
continue;
|
|
|
|
|
2013-10-09 16:07:19 +00:00
|
|
|
if (autotiles[i]->megaSurface())
|
|
|
|
continue;
|
|
|
|
|
2013-12-26 19:18:33 +00:00
|
|
|
usableATs.push_back(i);
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
|
|
|
|
if (autotiles[i]->width() > autotileW)
|
2013-12-26 19:18:33 +00:00
|
|
|
animatedATs.push_back(i);
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
tiles.animated = !animatedATs.empty();
|
|
|
|
}
|
|
|
|
|
2013-09-01 14:27:21 +00:00
|
|
|
void updateSceneGeometry(const Scene::Geometry &geo)
|
|
|
|
{
|
|
|
|
elem.sceneOffset.x = geo.rect.x - geo.xOrigin;
|
|
|
|
elem.sceneOffset.y = geo.rect.y - geo.yOrigin;
|
|
|
|
elem.sceneGeo = geo;
|
|
|
|
}
|
|
|
|
|
|
|
|
void updatePosition()
|
|
|
|
{
|
2014-07-10 23:07:18 +00:00
|
|
|
dispPos.x = -(offset.x - viewpPos.x * 32) + elem.sceneOffset.x;
|
2014-08-15 12:00:55 +00:00
|
|
|
dispPos.y = -(offset.y - viewpPos.y * 32) + elem.sceneOffset.y;
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void invalidateAtlasSize()
|
|
|
|
{
|
|
|
|
atlasSizeDirty = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
void invalidateAtlasContents()
|
|
|
|
{
|
|
|
|
atlasDirty = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
void invalidateBuffers()
|
|
|
|
{
|
|
|
|
buffersDirty = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Checks for the minimum amount of data needed to display */
|
|
|
|
bool verifyResources()
|
|
|
|
{
|
2014-09-23 19:12:58 +00:00
|
|
|
if (nullOrDisposed(tileset))
|
2013-09-01 14:27:21 +00:00
|
|
|
return false;
|
|
|
|
|
|
|
|
if (!mapData)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Allocates correctly sized TexFBO for atlas */
|
|
|
|
void allocateAtlas()
|
|
|
|
{
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
updateAtlasInfo();
|
2013-09-01 14:27:21 +00:00
|
|
|
|
|
|
|
/* Aquire atlas tex */
|
2013-10-22 04:36:13 +00:00
|
|
|
shState->releaseAtlasTex(atlas.gl);
|
|
|
|
shState->requestAtlasTex(atlas.size.x, atlas.size.y, atlas.gl);
|
2013-09-01 14:27:21 +00:00
|
|
|
|
|
|
|
atlasDirty = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Assembles atlas from tileset and autotile bitmaps */
|
|
|
|
void buildAtlas()
|
|
|
|
{
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
updateAutotileInfo();
|
|
|
|
|
2014-01-16 18:16:09 +00:00
|
|
|
TileAtlas::BlitVec blits = TileAtlas::calcBlits(atlas.efTilesetH, atlas.size);
|
2013-09-01 14:27:21 +00:00
|
|
|
|
|
|
|
/* Clear atlas */
|
2014-07-16 03:22:43 +00:00
|
|
|
FBO::bind(atlas.gl.fbo);
|
2013-09-01 14:27:21 +00:00
|
|
|
glState.clearColor.pushSet(Vec4());
|
|
|
|
glState.scissorTest.pushSet(false);
|
|
|
|
|
2013-10-01 11:10:14 +00:00
|
|
|
FBO::clear();
|
2013-09-01 14:27:21 +00:00
|
|
|
|
|
|
|
glState.scissorTest.pop();
|
|
|
|
glState.clearColor.pop();
|
|
|
|
|
2014-07-16 02:48:40 +00:00
|
|
|
GLMeta::blitBegin(atlas.gl);
|
|
|
|
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
/* Blit autotiles */
|
2013-12-27 05:19:30 +00:00
|
|
|
for (size_t i = 0; i < atlas.usableATs.size(); ++i)
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
{
|
2013-12-27 05:19:30 +00:00
|
|
|
const uint8_t atInd = atlas.usableATs[i];
|
|
|
|
Bitmap *autotile = autotiles[atInd];
|
|
|
|
|
|
|
|
int blitW = std::min(autotile->width(), atAreaW);
|
|
|
|
int blitH = std::min(autotile->height(), atAreaH);
|
2013-09-01 14:27:21 +00:00
|
|
|
|
2014-07-16 02:48:40 +00:00
|
|
|
GLMeta::blitSource(autotile->getGLTypes());
|
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
|
|
|
|
2014-07-13 12:05:56 +00:00
|
|
|
if (blitW <= autotileW && tiles.animated)
|
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
|
|
|
{
|
|
|
|
/* Static autotile */
|
|
|
|
for (int j = 0; j < 4; ++j)
|
2014-07-16 02:48:40 +00:00
|
|
|
GLMeta::blitRectangle(IntRect(0, 0, blitW, blitH),
|
|
|
|
Vec2i(autotileW*j, atInd*autotileH));
|
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
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Animated autotile */
|
2014-07-16 02:48:40 +00:00
|
|
|
GLMeta::blitRectangle(IntRect(0, 0, blitW, blitH),
|
|
|
|
Vec2i(0, atInd*autotileH));
|
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
|
|
|
}
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
}
|
2013-09-01 14:27:21 +00:00
|
|
|
|
2014-07-16 02:53:08 +00:00
|
|
|
GLMeta::blitEnd();
|
2014-07-16 02:48:40 +00:00
|
|
|
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
/* Blit tileset */
|
|
|
|
if (tileset->megaSurface())
|
2013-09-01 14:27:21 +00:00
|
|
|
{
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
/* Mega surface tileset */
|
|
|
|
TEX::bind(atlas.gl.tex);
|
2013-09-01 14:27:21 +00:00
|
|
|
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
SDL_Surface *tsSurf = tileset->megaSurface();
|
2013-09-01 14:27:21 +00:00
|
|
|
|
2013-12-26 19:18:33 +00:00
|
|
|
for (size_t i = 0; i < blits.size(); ++i)
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
{
|
2013-12-27 05:11:18 +00:00
|
|
|
const TileAtlas::Blit &blitOp = blits[i];
|
2013-09-01 14:27:21 +00:00
|
|
|
|
2014-07-11 06:31:12 +00:00
|
|
|
GLMeta::subRectImageUpload(tsSurf->w, blitOp.src.x, blitOp.src.y,
|
|
|
|
blitOp.dst.x, blitOp.dst.y, tsLaneW, blitOp.h, tsSurf, GL_RGBA);
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
}
|
2013-10-16 17:20:36 +00:00
|
|
|
|
2014-07-16 02:53:08 +00:00
|
|
|
GLMeta::subRectImageEnd();
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Regular tileset */
|
2014-07-16 02:48:40 +00:00
|
|
|
GLMeta::blitBegin(atlas.gl);
|
|
|
|
GLMeta::blitSource(tileset->getGLTypes());
|
2013-09-01 14:27:21 +00:00
|
|
|
|
2013-12-26 19:18:33 +00:00
|
|
|
for (size_t i = 0; i < blits.size(); ++i)
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
{
|
2013-12-27 05:11:18 +00:00
|
|
|
const TileAtlas::Blit &blitOp = blits[i];
|
2013-09-01 14:27:21 +00:00
|
|
|
|
2014-07-16 02:48:40 +00:00
|
|
|
GLMeta::blitRectangle(IntRect(blitOp.src.x, blitOp.src.y, tsLaneW, blitOp.h),
|
|
|
|
blitOp.dst);
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
}
|
2014-07-16 02:48:40 +00:00
|
|
|
|
2014-07-16 02:53:08 +00:00
|
|
|
GLMeta::blitEnd();
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
int samplePriority(int tileInd)
|
|
|
|
{
|
|
|
|
if (!priorities)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (tileInd > priorities->xSize()-1)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
int value = priorities->at(tileInd);
|
|
|
|
|
|
|
|
if (value > 5)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
|
|
|
FloatRect getAutotilePieceRect(int x, int y, /* in pixel coords */
|
|
|
|
int corner)
|
|
|
|
{
|
|
|
|
switch (corner)
|
|
|
|
{
|
|
|
|
case 0 : break;
|
|
|
|
case 1 : x += 16; break;
|
|
|
|
case 2 : x += 16; y += 16; break;
|
|
|
|
case 3 : y += 16; break;
|
|
|
|
default: abort();
|
|
|
|
}
|
|
|
|
|
|
|
|
return FloatRect(x, y, 16, 16);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
void handleAutotile(int x, int y, int tileInd, SVVector *array)
|
2013-09-01 14:27:21 +00:00
|
|
|
{
|
|
|
|
/* Which autotile [0-7] */
|
|
|
|
int atInd = tileInd / 48 - 1;
|
|
|
|
/* Which tile pattern of the autotile [0-47] */
|
|
|
|
int subInd = tileInd % 48;
|
|
|
|
|
|
|
|
const StaticRect *pieceRect = &autotileRects[subInd*4];
|
|
|
|
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
/* Iterate over the 4 tile pieces */
|
2013-09-01 14:27:21 +00:00
|
|
|
for (int i = 0; i < 4; ++i)
|
|
|
|
{
|
|
|
|
FloatRect posRect = getAutotilePieceRect(x*32, y*32, i);
|
|
|
|
FloatRect texRect = pieceRect[i];
|
|
|
|
|
|
|
|
/* Adjust to atlas coordinates */
|
|
|
|
texRect.y += atInd * autotileH;
|
|
|
|
|
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
|
|
|
SVertex v[4];
|
|
|
|
Quad::setTexPosRect(v, texRect, posRect);
|
2013-09-01 14:27:21 +00:00
|
|
|
|
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
|
|
|
/* Iterate over 4 vertices */
|
|
|
|
for (size_t i = 0; i < 4; ++i)
|
|
|
|
array->push_back(v[i]);
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void handleTile(int x, int y, int z)
|
|
|
|
{
|
2014-07-10 23:07:18 +00:00
|
|
|
int tileInd =
|
|
|
|
tableGetWrapped(mapData, x + viewpPos.x, y + viewpPos.y, z);
|
2013-09-01 14:27:21 +00:00
|
|
|
|
|
|
|
/* Check for empty space */
|
|
|
|
if (tileInd < 48)
|
|
|
|
return;
|
|
|
|
|
|
|
|
int prio = samplePriority(tileInd);
|
|
|
|
|
|
|
|
/* Check for faulty data */
|
|
|
|
if (prio == -1)
|
|
|
|
return;
|
|
|
|
|
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
|
|
|
SVVector *targetArray;
|
2013-09-01 14:27:21 +00:00
|
|
|
|
|
|
|
/* Prio 0 tiles are all part of the same ground layer */
|
|
|
|
if (prio == 0)
|
|
|
|
{
|
|
|
|
targetArray = &groundVert;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2014-08-17 01:58:01 +00:00
|
|
|
int layerInd = y + prio;
|
|
|
|
targetArray = &zlayerVert[layerInd];
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Check for autotile */
|
|
|
|
if (tileInd < 48*8)
|
|
|
|
{
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
handleAutotile(x, y, tileInd, targetArray);
|
2013-09-01 14:27:21 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
int tsInd = tileInd - 48*8;
|
|
|
|
int tileX = tsInd % 8;
|
|
|
|
int tileY = tsInd / 8;
|
|
|
|
|
2013-09-29 23:38:46 +00:00
|
|
|
Vec2i texPos = TileAtlas::tileToAtlasCoor(tileX, tileY, atlas.efTilesetH, atlas.size.y);
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
FloatRect texRect((float) texPos.x+.5, (float) texPos.y+.5, 31, 31);
|
2013-09-01 14:27:21 +00:00
|
|
|
FloatRect posRect(x*32, y*32, 32, 32);
|
|
|
|
|
|
|
|
SVertex v[4];
|
|
|
|
Quad::setTexPosRect(v, texRect, posRect);
|
|
|
|
|
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
|
|
|
for (size_t i = 0; i < 4; ++i)
|
|
|
|
targetArray->push_back(v[i]);
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void clearQuadArrays()
|
|
|
|
{
|
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
|
|
|
groundVert.clear();
|
2013-12-26 19:18:33 +00:00
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
for (size_t i = 0; i < zlayersMax; ++i)
|
|
|
|
zlayerVert[i].clear();
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void buildQuadArray()
|
|
|
|
{
|
|
|
|
clearQuadArrays();
|
|
|
|
|
2014-07-10 23:07:18 +00:00
|
|
|
for (int x = 0; x < viewpW; ++x)
|
|
|
|
for (int y = 0; y < viewpH; ++y)
|
|
|
|
for (int z = 0; z < mapData->zSize(); ++z)
|
2013-09-01 14:27:21 +00:00
|
|
|
handleTile(x, y, z);
|
|
|
|
}
|
|
|
|
|
2013-12-26 19:18:33 +00:00
|
|
|
static size_t quadDataSize(size_t quadCount)
|
2013-09-01 14:27:21 +00:00
|
|
|
{
|
|
|
|
return quadCount * sizeof(SVertex) * 4;
|
|
|
|
}
|
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
size_t zlayerSize(size_t index)
|
2013-09-01 14:27:21 +00:00
|
|
|
{
|
2014-08-17 01:58:01 +00:00
|
|
|
return zlayerBases[index+1] - zlayerBases[index];
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void uploadBuffers()
|
|
|
|
{
|
|
|
|
/* Calculate total quad count */
|
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
|
|
|
size_t groundQuadCount = groundVert.size() / 4;
|
2013-12-26 19:18:33 +00:00
|
|
|
size_t quadCount = groundQuadCount;
|
2013-09-01 14:27:21 +00:00
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
for (size_t i = 0; i < zlayersMax; ++i)
|
2013-09-01 14:27:21 +00:00
|
|
|
{
|
2014-08-17 01:58:01 +00:00
|
|
|
zlayerBases[i] = quadCount;
|
|
|
|
quadCount += zlayerVert[i].size() / 4;
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
zlayerBases[zlayersMax] = quadCount;
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
|
2013-09-01 14:27:21 +00:00
|
|
|
VBO::bind(tiles.vbo);
|
|
|
|
VBO::allocEmpty(quadDataSize(quadCount));
|
|
|
|
|
2014-10-09 17:02:29 +00:00
|
|
|
VBO::uploadSubData(0, quadDataSize(groundQuadCount), dataPtr(groundVert));
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
for (size_t i = 0; i < zlayersMax; ++i)
|
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
|
|
|
{
|
2014-08-17 01:58:01 +00:00
|
|
|
if (zlayerVert[i].empty())
|
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
|
|
|
continue;
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
VBO::uploadSubData(quadDataSize(zlayerBases[i]),
|
2014-10-09 17:02:29 +00:00
|
|
|
quadDataSize(zlayerSize(i)), dataPtr(zlayerVert[i]));
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
VBO::unbind();
|
|
|
|
|
|
|
|
/* Ensure global IBO size */
|
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
|
|
|
shState->ensureQuadIBO(quadCount);
|
|
|
|
}
|
|
|
|
|
|
|
|
void bindShader(ShaderBase *&shaderVar)
|
|
|
|
{
|
|
|
|
if (tiles.animated)
|
|
|
|
{
|
|
|
|
TilemapShader &tilemapShader = shState->shaders().tilemap;
|
|
|
|
tilemapShader.bind();
|
|
|
|
tilemapShader.setAniIndex(tiles.frameIdx);
|
|
|
|
shaderVar = &tilemapShader;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
shaderVar = &shState->shaders().simple;
|
|
|
|
shaderVar->bind();
|
|
|
|
}
|
|
|
|
|
|
|
|
shaderVar->applyViewportProj();
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
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
|
|
|
void bindAtlas(ShaderBase &shader)
|
2013-09-01 14:27:21 +00:00
|
|
|
{
|
2013-09-06 10:26:41 +00:00
|
|
|
TEX::bind(atlas.gl.tex);
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
shader.setTexSize(atlas.size);
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
void updateActiveElements(std::vector<int> &zlayerInd)
|
2013-09-01 14:27:21 +00:00
|
|
|
{
|
2014-07-10 23:07:18 +00:00
|
|
|
elem.ground->updateVboCount();
|
2013-09-01 14:27:21 +00:00
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
for (size_t i = 0; i < zlayersMax; ++i)
|
2013-09-01 14:27:21 +00:00
|
|
|
{
|
2014-08-17 01:58:01 +00:00
|
|
|
if (i < zlayerInd.size())
|
2014-07-10 23:07:18 +00:00
|
|
|
{
|
2014-08-17 01:58:01 +00:00
|
|
|
int index = zlayerInd[i];
|
|
|
|
elem.zlayers[i]->setVisible(visible);
|
|
|
|
elem.zlayers[i]->setIndex(index);
|
2014-07-10 23:07:18 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2014-08-17 01:58:01 +00:00
|
|
|
/* Hide unused layers */
|
|
|
|
elem.zlayers[i]->setVisible(false);
|
2014-07-10 23:07:18 +00:00
|
|
|
}
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-07-10 23:07:18 +00:00
|
|
|
void updateSceneElements()
|
2013-09-01 14:27:21 +00:00
|
|
|
{
|
2014-08-17 01:58:01 +00:00
|
|
|
/* Only allocate elements for non-emtpy zlayers */
|
|
|
|
std::vector<int> zlayerInd;
|
2013-12-26 19:18:33 +00:00
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
for (size_t i = 0; i < zlayersMax; ++i)
|
|
|
|
if (zlayerVert[i].size() > 0)
|
|
|
|
zlayerInd.push_back(i);
|
2013-09-01 14:27:21 +00:00
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
updateActiveElements(zlayerInd);
|
|
|
|
elem.activeLayers = zlayerInd.size();
|
2014-07-10 23:07:18 +00:00
|
|
|
zOrderDirty = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
void hideElements()
|
|
|
|
{
|
|
|
|
elem.ground->setVisible(false);
|
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
for (size_t i = 0; i < zlayersMax; ++i)
|
|
|
|
elem.zlayers[i]->setVisible(false);
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void updateZOrder()
|
|
|
|
{
|
2014-08-17 01:58:01 +00:00
|
|
|
if (elem.activeLayers == 0)
|
2013-10-13 10:58:56 +00:00
|
|
|
return;
|
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
for (size_t i = 0; i < elem.activeLayers; ++i)
|
|
|
|
elem.zlayers[i]->initUpdateZ();
|
2013-09-27 02:42:22 +00:00
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
ZLayer *prev = elem.zlayers[0];
|
2013-10-13 10:58:56 +00:00
|
|
|
prev->finiUpdateZ(0);
|
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
for (size_t i = 1; i < elem.activeLayers; ++i)
|
2013-10-13 10:58:56 +00:00
|
|
|
{
|
2014-08-17 01:58:01 +00:00
|
|
|
ZLayer *layer = elem.zlayers[i];
|
|
|
|
layer->finiUpdateZ(prev);
|
|
|
|
prev = layer;
|
2013-10-13 10:58:56 +00:00
|
|
|
}
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
/* When there are two or more zlayers with no other
|
2013-10-13 20:00:38 +00:00
|
|
|
* elements between them in the scene list, we can
|
2014-08-17 01:58:01 +00:00
|
|
|
* render them in a batch (as the zlayer data itself
|
2013-10-13 20:00:38 +00:00
|
|
|
* is ordered sequentially in VRAM). Every frame, we
|
2014-08-17 01:58:01 +00:00
|
|
|
* scan the scene list for such sequential layers and
|
|
|
|
* batch them up for drawing. The first layer of the batch
|
2013-10-13 20:00:38 +00:00
|
|
|
* (the "batch head") executes the draw call, all others
|
|
|
|
* are muted via the 'batchedFlag'. For simplicity,
|
|
|
|
* single sized batches are possible. */
|
2014-08-17 01:58:01 +00:00
|
|
|
void prepareZLayerBatches()
|
2013-10-13 20:00:38 +00:00
|
|
|
{
|
2014-08-17 01:58:01 +00:00
|
|
|
ZLayer *const *zlayers = elem.zlayers;
|
2013-10-13 20:00:38 +00:00
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
for (size_t i = 0; i < elem.activeLayers; ++i)
|
2013-10-13 20:00:38 +00:00
|
|
|
{
|
2014-08-17 01:58:01 +00:00
|
|
|
ZLayer *batchHead = zlayers[i];
|
2013-10-13 20:00:38 +00:00
|
|
|
batchHead->batchedFlag = false;
|
|
|
|
|
|
|
|
GLsizei vboBatchCount = batchHead->vboCount;
|
|
|
|
IntruListLink<SceneElement> *iter = &batchHead->link;
|
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
for (i = i+1; i < elem.activeLayers; ++i)
|
2013-10-13 20:00:38 +00:00
|
|
|
{
|
|
|
|
iter = iter->next;
|
2014-08-17 01:58:01 +00:00
|
|
|
ZLayer *layer = zlayers[i];
|
2013-10-13 20:00:38 +00:00
|
|
|
|
|
|
|
/* Check if the next SceneElement is also
|
2014-08-17 01:58:01 +00:00
|
|
|
* the next zlayer in our list. If not,
|
2013-10-13 20:00:38 +00:00
|
|
|
* the current batch is complete */
|
2014-08-17 01:58:01 +00:00
|
|
|
if (iter != &layer->link)
|
2013-10-13 20:00:38 +00:00
|
|
|
break;
|
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
vboBatchCount += layer->vboCount;
|
|
|
|
layer->batchedFlag = true;
|
2013-10-13 20:00:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
batchHead->vboBatchCount = vboBatchCount;
|
|
|
|
--i;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-07-10 23:07:18 +00:00
|
|
|
void updateMapViewport()
|
|
|
|
{
|
|
|
|
int tileOX, tileOY;
|
|
|
|
|
|
|
|
if (offset.x >= 0)
|
|
|
|
tileOX = offset.x / 32;
|
|
|
|
else
|
|
|
|
tileOX = -(-(offset.x-31) / 32);
|
|
|
|
|
|
|
|
if (offset.y >= 0)
|
|
|
|
tileOY = offset.y / 32;
|
|
|
|
else
|
|
|
|
tileOY = -(-(offset.y-31) / 32);
|
|
|
|
|
|
|
|
bool dirty = false;
|
|
|
|
|
|
|
|
if (tileOX < viewpPos.x || tileOX + 21 > viewpPos.x + viewpW)
|
|
|
|
{
|
|
|
|
viewpPos.x = tileOX;
|
|
|
|
dirty = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (tileOY < viewpPos.y || tileOY + 16 > viewpPos.y + viewpH)
|
|
|
|
{
|
|
|
|
viewpPos.y = tileOY;
|
|
|
|
dirty = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (dirty)
|
|
|
|
{
|
|
|
|
buffersDirty = true;
|
2014-10-26 19:00:56 +00:00
|
|
|
updateFlashMapViewport();
|
2014-07-10 23:07:18 +00:00
|
|
|
updatePosition();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-09-01 14:27:21 +00:00
|
|
|
void prepare()
|
|
|
|
{
|
|
|
|
if (!verifyResources())
|
|
|
|
{
|
2014-07-10 23:07:18 +00:00
|
|
|
if (tilemapReady)
|
|
|
|
hideElements();
|
2013-09-01 14:27:21 +00:00
|
|
|
tilemapReady = false;
|
2014-07-10 23:07:18 +00:00
|
|
|
|
2013-09-01 14:27:21 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (atlasSizeDirty)
|
|
|
|
{
|
|
|
|
allocateAtlas();
|
|
|
|
atlasSizeDirty = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (atlasDirty)
|
|
|
|
{
|
|
|
|
buildAtlas();
|
|
|
|
atlasDirty = false;
|
|
|
|
}
|
|
|
|
|
2014-07-10 23:07:18 +00:00
|
|
|
if (mapViewportDirty)
|
|
|
|
{
|
|
|
|
updateMapViewport();
|
|
|
|
mapViewportDirty = false;
|
|
|
|
}
|
|
|
|
|
2013-09-01 14:27:21 +00:00
|
|
|
if (buffersDirty)
|
|
|
|
{
|
|
|
|
buildQuadArray();
|
|
|
|
uploadBuffers();
|
2014-07-10 23:07:18 +00:00
|
|
|
updateSceneElements();
|
2013-09-01 14:27:21 +00:00
|
|
|
buffersDirty = false;
|
|
|
|
}
|
|
|
|
|
2014-10-26 19:00:56 +00:00
|
|
|
flashMap.prepare();
|
2013-09-01 14:27:21 +00:00
|
|
|
|
|
|
|
if (zOrderDirty)
|
|
|
|
{
|
|
|
|
updateZOrder();
|
|
|
|
zOrderDirty = false;
|
|
|
|
}
|
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
prepareZLayerBatches();
|
2013-10-13 20:00:38 +00:00
|
|
|
|
2013-09-01 14:27:21 +00:00
|
|
|
tilemapReady = true;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
GroundLayer::GroundLayer(TilemapPrivate *p, Viewport *viewport)
|
2014-08-30 22:51:23 +00:00
|
|
|
: ViewportElement(viewport, 0),
|
2014-07-10 23:07:18 +00:00
|
|
|
vboCount(0),
|
2013-09-01 14:27:21 +00:00
|
|
|
p(p)
|
|
|
|
{
|
|
|
|
onGeometryChange(scene->getGeometry());
|
|
|
|
}
|
|
|
|
|
2014-07-10 23:07:18 +00:00
|
|
|
void GroundLayer::updateVboCount()
|
|
|
|
{
|
2014-08-17 01:58:01 +00:00
|
|
|
vboCount = p->zlayerBases[0] * 6;
|
2014-07-10 23:07:18 +00:00
|
|
|
}
|
|
|
|
|
2013-09-01 14:27:21 +00:00
|
|
|
void GroundLayer::draw()
|
|
|
|
{
|
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
|
|
|
ShaderBase *shader;
|
2013-09-23 05:15:01 +00:00
|
|
|
|
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
|
|
|
p->bindShader(shader);
|
|
|
|
p->bindAtlas(*shader);
|
2013-09-01 14:27:21 +00:00
|
|
|
|
2014-07-13 12:03:18 +00:00
|
|
|
GLMeta::vaoBind(p->tiles.vao);
|
2013-09-01 14:27:21 +00:00
|
|
|
|
2014-07-10 23:07:18 +00:00
|
|
|
shader->setTranslation(p->dispPos);
|
|
|
|
drawInt();
|
2013-09-01 14:27:21 +00:00
|
|
|
|
2014-07-13 12:03:18 +00:00
|
|
|
GLMeta::vaoUnbind(p->tiles.vao);
|
|
|
|
|
2014-10-26 19:00:56 +00:00
|
|
|
p->flashMap.draw(flashAlpha[p->flashAlphaIdx] / 255.f, p->dispPos);
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void GroundLayer::drawInt()
|
|
|
|
{
|
2014-07-11 00:09:53 +00:00
|
|
|
gl.DrawElements(GL_TRIANGLES, vboCount, _GL_INDEX_TYPE, (GLvoid*) 0);
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void GroundLayer::onGeometryChange(const Scene::Geometry &geo)
|
|
|
|
{
|
|
|
|
p->updateSceneGeometry(geo);
|
|
|
|
p->updatePosition();
|
|
|
|
}
|
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
ZLayer::ZLayer(TilemapPrivate *p, Viewport *viewport)
|
2014-08-30 22:51:23 +00:00
|
|
|
: ViewportElement(viewport, 0),
|
2014-07-10 23:07:18 +00:00
|
|
|
index(0),
|
|
|
|
vboOffset(0),
|
|
|
|
vboCount(0),
|
2013-10-13 20:00:38 +00:00
|
|
|
p(p),
|
|
|
|
vboBatchCount(0)
|
2014-07-10 23:07:18 +00:00
|
|
|
{}
|
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
void ZLayer::setIndex(int value)
|
2013-09-01 14:27:21 +00:00
|
|
|
{
|
2014-07-10 23:07:18 +00:00
|
|
|
index = value;
|
|
|
|
|
|
|
|
z = calculateZ(p, index);
|
|
|
|
scene->reinsert(*this);
|
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
vboOffset = p->zlayerBases[index] * sizeof(index_t) * 6;
|
|
|
|
vboCount = p->zlayerSize(index) * 6;
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
void ZLayer::draw()
|
2013-09-01 14:27:21 +00:00
|
|
|
{
|
2013-10-13 20:00:38 +00:00
|
|
|
if (batchedFlag)
|
|
|
|
return;
|
|
|
|
|
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
|
|
|
ShaderBase *shader;
|
2013-09-23 05:15:01 +00:00
|
|
|
|
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
|
|
|
p->bindShader(shader);
|
|
|
|
p->bindAtlas(*shader);
|
2013-09-01 14:27:21 +00:00
|
|
|
|
2014-07-13 12:03:18 +00:00
|
|
|
GLMeta::vaoBind(p->tiles.vao);
|
2013-09-01 14:27:21 +00:00
|
|
|
|
2014-07-10 23:07:18 +00:00
|
|
|
shader->setTranslation(p->dispPos);
|
|
|
|
drawInt();
|
2013-09-01 14:27:21 +00:00
|
|
|
|
2014-07-13 12:03:18 +00:00
|
|
|
GLMeta::vaoUnbind(p->tiles.vao);
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
void ZLayer::drawInt()
|
2013-09-01 14:27:21 +00:00
|
|
|
{
|
2014-07-11 00:09:53 +00:00
|
|
|
gl.DrawElements(GL_TRIANGLES, vboBatchCount, _GL_INDEX_TYPE, (GLvoid*) vboOffset);
|
2014-07-10 23:07:18 +00:00
|
|
|
}
|
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
int ZLayer::calculateZ(TilemapPrivate *p, int index)
|
2014-07-10 23:07:18 +00:00
|
|
|
{
|
|
|
|
return 32 * (index + p->viewpPos.y + 1) - p->offset.y;
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
void ZLayer::initUpdateZ()
|
2013-09-01 14:27:21 +00:00
|
|
|
{
|
2013-09-27 02:42:22 +00:00
|
|
|
unlink();
|
|
|
|
}
|
|
|
|
|
2014-08-17 01:58:01 +00:00
|
|
|
void ZLayer::finiUpdateZ(ZLayer *prev)
|
2013-09-27 02:42:22 +00:00
|
|
|
{
|
2014-07-10 23:07:18 +00:00
|
|
|
z = calculateZ(p, index);
|
2013-09-27 02:42:22 +00:00
|
|
|
|
2013-10-13 10:58:56 +00:00
|
|
|
if (prev)
|
|
|
|
scene->insertAfter(*this, *prev);
|
|
|
|
else
|
|
|
|
scene->insert(*this);
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void Tilemap::Autotiles::set(int i, Bitmap *bitmap)
|
|
|
|
{
|
2014-09-26 16:21:50 +00:00
|
|
|
if (!p)
|
|
|
|
return;
|
|
|
|
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
if (i < 0 || i > autotileCount-1)
|
2013-09-01 14:27:21 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
if (p->autotiles[i] == bitmap)
|
|
|
|
return;
|
|
|
|
|
|
|
|
p->autotiles[i] = bitmap;
|
|
|
|
|
|
|
|
p->invalidateAtlasContents();
|
|
|
|
|
|
|
|
p->autotilesCon[i].disconnect();
|
|
|
|
p->autotilesCon[i] = bitmap->modified.connect
|
|
|
|
(sigc::mem_fun(p, &TilemapPrivate::invalidateAtlasContents));
|
|
|
|
|
|
|
|
p->autotilesDispCon[i].disconnect();
|
|
|
|
p->autotilesDispCon[i] = bitmap->wasDisposed.connect
|
2014-09-23 19:12:58 +00:00
|
|
|
(sigc::mem_fun(p, &TilemapPrivate::invalidateAtlasContents));
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
|
|
|
|
p->updateAutotileInfo();
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
Bitmap *Tilemap::Autotiles::get(int i) const
|
|
|
|
{
|
2014-09-26 16:21:50 +00:00
|
|
|
if (!p)
|
|
|
|
return 0;
|
|
|
|
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
if (i < 0 || i > autotileCount-1)
|
2013-09-01 14:27:21 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
return p->autotiles[i];
|
|
|
|
}
|
|
|
|
|
|
|
|
Tilemap::Tilemap(Viewport *viewport)
|
|
|
|
{
|
|
|
|
p = new TilemapPrivate(viewport);
|
2014-09-26 16:21:50 +00:00
|
|
|
atProxy.p = p;
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
Tilemap::~Tilemap()
|
|
|
|
{
|
2014-09-23 19:12:58 +00:00
|
|
|
dispose();
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void Tilemap::update()
|
|
|
|
{
|
2014-09-23 19:12:58 +00:00
|
|
|
guardDisposed();
|
|
|
|
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
if (!p->tilemapReady)
|
|
|
|
return;
|
|
|
|
|
2013-09-23 06:27:28 +00:00
|
|
|
/* Animate flash */
|
2014-10-26 19:00:56 +00:00
|
|
|
if (++p->flashAlphaIdx >= flashAlphaN)
|
|
|
|
p->flashAlphaIdx = 0;
|
2013-09-23 06:27:28 +00:00
|
|
|
|
|
|
|
/* Animate autotiles */
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
if (!p->tiles.animated)
|
2013-09-01 14:27:21 +00:00
|
|
|
return;
|
|
|
|
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
p->tiles.frameIdx = atAnimation[p->tiles.aniIdx];
|
2013-09-01 14:27:21 +00:00
|
|
|
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
if (++p->tiles.aniIdx >= atAnimationN)
|
|
|
|
p->tiles.aniIdx = 0;
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
2014-09-26 16:21:50 +00:00
|
|
|
Tilemap::Autotiles &Tilemap::getAutotiles()
|
2013-09-01 14:27:21 +00:00
|
|
|
{
|
2014-09-23 19:12:58 +00:00
|
|
|
guardDisposed();
|
|
|
|
|
2014-09-26 16:21:50 +00:00
|
|
|
return atProxy;
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
DEF_ATTR_RD_SIMPLE(Tilemap, Viewport, Viewport*, p->viewport)
|
|
|
|
DEF_ATTR_RD_SIMPLE(Tilemap, Tileset, Bitmap*, p->tileset)
|
|
|
|
DEF_ATTR_RD_SIMPLE(Tilemap, MapData, Table*, p->mapData)
|
2014-10-26 19:00:56 +00:00
|
|
|
DEF_ATTR_RD_SIMPLE(Tilemap, FlashData, Table*, p->flashMap.getData())
|
2013-09-01 14:27:21 +00:00
|
|
|
DEF_ATTR_RD_SIMPLE(Tilemap, Priorities, Table*, p->priorities)
|
|
|
|
DEF_ATTR_RD_SIMPLE(Tilemap, Visible, bool, p->visible)
|
|
|
|
DEF_ATTR_RD_SIMPLE(Tilemap, OX, int, p->offset.x)
|
|
|
|
DEF_ATTR_RD_SIMPLE(Tilemap, OY, int, p->offset.y)
|
|
|
|
|
|
|
|
void Tilemap::setTileset(Bitmap *value)
|
|
|
|
{
|
2014-09-23 19:12:58 +00:00
|
|
|
guardDisposed();
|
|
|
|
|
2013-09-01 14:27:21 +00:00
|
|
|
if (p->tileset == value)
|
|
|
|
return;
|
|
|
|
|
|
|
|
p->tileset = value;
|
2014-08-09 16:35:01 +00:00
|
|
|
|
|
|
|
if (!value)
|
|
|
|
return;
|
2013-09-01 14:27:21 +00:00
|
|
|
|
|
|
|
p->invalidateAtlasSize();
|
|
|
|
p->tilesetCon.disconnect();
|
|
|
|
p->tilesetCon = value->modified.connect
|
|
|
|
(sigc::mem_fun(p, &TilemapPrivate::invalidateAtlasSize));
|
Implement a new tileset atlas layout to allow for bigger tilesets
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
2013-09-23 20:21:58 +00:00
|
|
|
|
|
|
|
p->updateAtlasInfo();
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void Tilemap::setMapData(Table *value)
|
|
|
|
{
|
2014-09-23 19:12:58 +00:00
|
|
|
guardDisposed();
|
|
|
|
|
2013-09-01 14:27:21 +00:00
|
|
|
if (p->mapData == value)
|
|
|
|
return;
|
|
|
|
|
|
|
|
p->mapData = value;
|
|
|
|
|
2014-08-09 16:35:01 +00:00
|
|
|
if (!value)
|
|
|
|
return;
|
|
|
|
|
2013-09-01 14:27:21 +00:00
|
|
|
p->invalidateBuffers();
|
|
|
|
p->mapDataCon.disconnect();
|
|
|
|
p->mapDataCon = value->modified.connect
|
|
|
|
(sigc::mem_fun(p, &TilemapPrivate::invalidateBuffers));
|
|
|
|
}
|
|
|
|
|
|
|
|
void Tilemap::setFlashData(Table *value)
|
|
|
|
{
|
2014-09-23 19:12:58 +00:00
|
|
|
guardDisposed();
|
|
|
|
|
2014-10-26 19:00:56 +00:00
|
|
|
p->flashMap.setData(value);
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void Tilemap::setPriorities(Table *value)
|
|
|
|
{
|
2014-09-23 19:12:58 +00:00
|
|
|
guardDisposed();
|
|
|
|
|
2013-09-01 14:27:21 +00:00
|
|
|
if (p->priorities == value)
|
|
|
|
return;
|
|
|
|
|
|
|
|
p->priorities = value;
|
|
|
|
|
2014-08-09 16:35:01 +00:00
|
|
|
if (!value)
|
|
|
|
return;
|
|
|
|
|
2013-09-01 14:27:21 +00:00
|
|
|
p->invalidateBuffers();
|
|
|
|
p->prioritiesCon.disconnect();
|
|
|
|
p->prioritiesCon = value->modified.connect
|
|
|
|
(sigc::mem_fun(p, &TilemapPrivate::invalidateBuffers));
|
|
|
|
}
|
|
|
|
|
|
|
|
void Tilemap::setVisible(bool value)
|
|
|
|
{
|
2014-09-23 19:12:58 +00:00
|
|
|
guardDisposed();
|
|
|
|
|
2013-09-01 14:27:21 +00:00
|
|
|
if (p->visible == value)
|
|
|
|
return;
|
|
|
|
|
|
|
|
p->visible = value;
|
|
|
|
|
|
|
|
if (!p->tilemapReady)
|
|
|
|
return;
|
|
|
|
|
|
|
|
p->elem.ground->setVisible(value);
|
2014-08-17 01:58:01 +00:00
|
|
|
for (size_t i = 0; i < p->elem.activeLayers; ++i)
|
|
|
|
p->elem.zlayers[i]->setVisible(value);
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void Tilemap::setOX(int value)
|
|
|
|
{
|
2014-09-23 19:12:58 +00:00
|
|
|
guardDisposed();
|
|
|
|
|
2013-09-01 14:27:21 +00:00
|
|
|
if (p->offset.x == value)
|
|
|
|
return;
|
|
|
|
|
|
|
|
p->offset.x = value;
|
|
|
|
p->updatePosition();
|
2014-07-10 23:07:18 +00:00
|
|
|
p->mapViewportDirty = true;
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void Tilemap::setOY(int value)
|
|
|
|
{
|
2014-09-23 19:12:58 +00:00
|
|
|
guardDisposed();
|
|
|
|
|
2013-09-01 14:27:21 +00:00
|
|
|
if (p->offset.y == value)
|
|
|
|
return;
|
|
|
|
|
|
|
|
p->offset.y = value;
|
|
|
|
p->updatePosition();
|
2013-09-27 02:42:22 +00:00
|
|
|
p->zOrderDirty = true;
|
2014-07-10 23:07:18 +00:00
|
|
|
p->mapViewportDirty = true;
|
2013-09-01 14:27:21 +00:00
|
|
|
}
|
2014-09-23 19:12:58 +00:00
|
|
|
|
|
|
|
void Tilemap::releaseResources()
|
|
|
|
{
|
|
|
|
delete p;
|
2014-09-26 16:21:50 +00:00
|
|
|
atProxy.p = 0;
|
2014-09-23 19:12:58 +00:00
|
|
|
}
|