Shader "sprite constants" limit

I asked op of this topic, he said it was done with the constant buffers, which is not a solution for me.
But a DEF-2055 feature request about passing arrays to shaders was created in that topic. This would be a nice solution for me aswell, are there any plans for this in the not-so-far future?

@Mathias_Westerdahl
Thanks for the explanation! What i want to do is fairly well described here. I have a game character (zombie) with spritesheet animations and everything. There are lots of them and i want to randomize their colors in some way, altering, for example, their shirt and pants but without affecting skin and bandages color. Game has pixel-art style, so the character has small neat color palette (~8 colors) and there seems to be no need in any more sophisticated approach.
In the article it is suggested to procedurally create a unique 1x256 texture and then just do “color = new_palette[color.x * 255]” in the fragment shader (of course considering the fact that no colors should have the same red value). This would be the best solution for me, but there seems to be no way to create a procedural texture, except to render part of the scene, no “set_pixel” functions for us :frowning:
So i’m trying another one - i don’t even need 256 colors, i’m fine with 10, so i’m just creating 10 vec4 variables, collect them into vec4 array in vertex shader and use that array like a 1x10 texture in fragment shader. It could work for me (after fixing some colors in the base zombie spritesheet), but i can’t use more than 4 constants (which also leaves me with no tint and saturation constants aswell i suppose).
Here is the zombies (Smash Bash, ho!) with altered shirt color (not randomized but its easy to add): http://joxi.ru/krDDz85SE0NYxr.png . The problem is this is done with “if (int(floor(color.x * 255.0)) == 115) color = vec4(1,0,0,1);”, and even though i can live with that, it will require a much more complex fragment shader with lots of if statements, which is most probably a really bad idea considering perfomance. And i would have to create a unique shader for every type of monster with this approach.

@Mathias_Westerdahl @Ragnar_Svensson
So basically any of this would help me:

  1. Creating and passing procedurally created 1x256 texture as shader constant
  2. Passing array (vec4’s, but simple floats will work too) as shader constant. (DEF-2055)
  3. Increasing the amount of variables to at least 10 (16 would be better). Not so good approach, as it requires me to do some work in vertex shader, but still possible. Is it possible to check if you can increase constants amount?
  4. If there are any other way to make this “procedural diversification” (i like the sound of that lol), i’m all ears. Without increasing the amount of work for the artists too much if possible :slight_smile:
  5. Not really good solution, but better than nothing: if i could manually create, like, 10 different “palettes” and save them somehow in the material/shader, and then just pass one number constant - which of this 10 palettes to use, there will be at least 10 different zombie types in the game. Problem is i have no idea how to save this data in the material and how then to use it from fragment shader.

There probably is also a more complex way - to use a mask spritesheet that is somehow passed to the shader with the same current frame as original sprite. Then i can use any of x,y,z,w values of the pixel to represent the color, aka "final_color = procedural_color1 * pixel.x + … + procedural_color_4 * pixel.w (this is used in some terrain frameworks, i fogot how this approach is called). But still, every mask texture allows to use only 4 channels and is overkill, because i dont need to combine colors. And still 4 shader constants wouldnt be enough for me.

4 Likes