Atlas texture and batched rendering

[grantramsay]

Spent ages trying to get this working with a GL_TEXTURE_2D_ARRAY but couldn't quite get it to work, parts of the Nuklear GUI would be missing if the array texture was allocated with > 1 depth (layers). Currently it uses an array of textures (up to 8) to store all the images, runs at ~130 FPS on my machine (GL_TEXTURE_2D_ARRAY runs at ~180). Needs a test on a few different PCs

[AJenbo]

The 3 mentioned cel files are corrupt so won't decode under normal conditions

[grantramsay]

Ahh thanks @AJenbo that makes sense

[wheybags]

I get the error

0:14(19): error: sampler arrays indexed with non-constant expressions are forbidden in GLSL 1.30 and later

If you have time, I think the proper answer is either to move to texture arrays, or break the batch when the atlas texture changes. The second option is more scalable IMO, but it would require some intelligent allocation of atlases (at the very least, the ground textures should all be in one atlas).

[wheybags]

I will get around to renderer work eventually myself, if I do before this is merged, I'll just start working on this branch myself. Either way, what's here already is a good chunk of what needs to be done, so thanks a lot!

[grantramsay]

Yeah there's some good stuff in here but it's not stable enough to merge. Storing all the textures is a bit heavy on gpu ram. Splitting textures into drawing layer categories (if possible) and only caching the current level tiles would probably be better. All good, hopefully what's here helps you out

[grantramsay]

I had a thought that clearing the atlas texture when changing levels would be a simple way to reduce the large RAM requirements of storing all the sprites, decided to give it a go.. Uses a 2D array texture 8192*8192 with 2 layers. It's just a thought, let me know what you think. And feel free to discard if you carry this work on in a different direction

[wheybags]

That's a direction we could go, but tbh I think we should be ok to just store the whole game's assets in VRAM. factorio does this (normally it keeps is all on the GPU, it can swap out too if you're low on VRAM, but that's a relatively recent addition for lower end cards) and we should have waaaaaaaay less image data to store.

[wheybags]

Im going to start wokring on a bit of an overhaul to the rendering code, so I think I will just merge this as-is for now, and use it as a base (also avoids my pr getting absolutely massive if I just branch off this and merge it all together :v)