Support really large textures in tilesets

[Shadowblitz16]

Describe the project you are working on

A mario game which I will provide a editor where users can draw there own graphics.

Describe the problem or limitation you are having in your project

I am using a tileset texture with a size of 256x16384
Thats 32 tiles wide and 2048 tiles high, which is 65536 tiles in total supported.

While tilesets can load an image this big it lags really bad.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Add support for texture pages in which textures loaded into a tileset are split into smaller parts but treated as the same texture functionality wise.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Basicly if you have 8x8 tiles and you say have gpu limitation of a 16x16 texture (yes I know that would never happen this is only for demonstration) and you load a texture of a size 32x32, Your 32x32 texture would be split up into a 4x4 pages.

When you fetch a tile by it's index the tileset treats the tileset as if you have 4 columns and 4 rows of 8x8 tiles.

If this enhancement will not be used often, can it be worked around with a few lines of script?

Idk if it would be used often but it would optimize tileset, and it can't be worked around easly, especially if you want to support treating it as one big texture.

Is there a reason why this should be core and not an add-on in the asset library?

Tileset is ready in core.

[Calinou]

I think the performance issue you're encountering is likely caused by the number of tiles in the TileSet, not the texture size. If you try a tile size of 256x256 in that tileset, it should perform much better.

I don't know in practice how common it is for a TileSet to have 65536 different tiles. I'd expect a number like 4096 to be pretty large already - it's already a lot of work for artists to cover.

[AThousandShips]

What game level context would utilize the majority of those 65536 tiles? Sounds like that would be a lot of wasted resources unless each level using the TileSet uses a majority of the tiles, and otherwise I'd say the it should be broken down into more usable portions, for example by terrain theme, especially since you can use multiple TileSets in one TileMapLayer so you can still make levels with different themes

[Shadowblitz16]

I think the performance issue you're encountering is likely caused by the number of tiles in the TileSet, not the texture size. If you try a tile size of 256x256 in that tileset, it should perform much better.

I don't know in practice how common it is for a TileSet to have 65536 different tiles. I'd expect a number like 4096 to be pretty large already - it's already a lot of work for artists to cover.

I always thought it was due to texture size limitations.
Also I give that many tiles so users can expand, according to the devs of zquest they had to expand their tile limit to be a uint instead of a ushort for zelda lttp assets and they had 16x16 tiles not 8x8

What game level context would utilize the majority of those 65536 tiles? Sounds like that would be a lot of wasted resources unless each level using the TileSet uses a majority of the tiles, and otherwise I'd say the it should be broken down into more usable portions, for example by terrain theme, especially since you can use multiple TileSets in one TileMapLayer so you can still make levels with different themes

There might be optimizations made on the side of the application who's graphics system I am trying to reproduce.
I think they don't initialize all there tiles at once but instead only load them when needed.
But again they recently expanded their tile count to a max uint instead of a max ushort because they said they didn't have enough room.

Note these tiles will be stored in a binary format, but will be stored as 4bpp pixel data without the palette so that's 8x the compression. basically 2 pixels per byte.