Tracking implementation of SHDR chunk

[colinator27]

This chunk is pretty complex compared to the last one I documented, and many others... I'm not sure how much of this will make sense, but I guess this issue can track the implementation of the SHDR chunk to this library/tool.

Here's what I got, from the latest GMS2 compiler. I haven't tested too much because it gets complicated very fast.

SHDR: ListChunk
This chunk seems pretty strange and complex in some places, and I tried my best to document it (somewhat) clearly.
---
<normal FourCC and chunk length>

List<T> format beginning:
 Int32 - count
 <list of 32-bit pointers to each item>
 
 For each item:
  32-bit string pointer to shader name
  
  Int32 - shader type with a bitwise OR against -0x80000000 (in big endian here, also it's signed and negative), as a number it is -2147483648
   Basically, in this case, this just changes the last byte of the little-endian Int32 to 0x80. For what reason is unknown?
   Little-endian-formatted types that are known, total of seven:
    0x01000080 (1) -> GLSL ES
    0x01000080 (2) -> GLSL
    0x03000080 (3) -> Unknown
    0x04000080 (4) -> HLSL
    0x05000080 to 0x07000080 (5 to 7) -> Unknown
   Missing from this list (the "unknown" types) are PSSL (PlayStation Shader Language), Cg, and Cg_PS3 (for PS3 seemingly)
    Also potentially a difference between HLSL9 and HLSL11
    I was unable to test these
  
  <note: many of the strings and pointers in this chunk will be null>
  32-bit string pointer to GLSL ES vertex shader code
  32-bit string pointer to GLSL ES fragment shader code
  32-bit string pointer to GLSL vertex shader code
  32-bit string pointer to GLSL fragment shader code
  32-bit string pointer to HLSL9 vertex shader code
  32-bit string pointer to HLSL9 fragment shader code
  
  <note: I'm going to give some pointers ID numbers so it's easy to tell where they go in the chunk>
  32-bit pointer to HLSL11 vertex shader string/bytes (ID #1)
  32-bit pointer to HLSL11 pixel shader string/bytes (ID #2)
  
  Int32 - count of vertex shader attributes
  Array (NOT a List<T>) of 32-bit string pointers, using the count specified on the last line, each representing a vertex shader attribute
  
  Int32 - literally just the number 2
  
  32-bit pointer to PSSL vertex shader string/bytes (ID #3)
  Int32 - length of PSSL vertex shader string/bytes
  32-bit pointer to PSSL pixel shader string/bytes (ID #4)
  Int32 - length of PSSL pixel shader string/bytes
  
  32-bit pointer to Cg vertex shader string/bytes (ID #5)
  Int32 - length of Cg vertex shader string/bytes
  32-bit pointer to Cg pixel shader string/bytes (ID #6)
  Int32 - length of Cg pixel shader string/bytes
  
  32-bit pointer to Cg_PS3 vertex shader string/bytes (ID #7)
  Int32 - length of Cg_PS3 vertex shader string/bytes
  32-bit pointer to Cg_PS3 pixel shader string/bytes (ID #8)
  Int32 - length of Cg_PS3 pixel shader string/bytes
  
  <note: Here's where everything starts to get complicated. I will do my best to represent if statements and loops used>
  <note2: This part contains a lot of actual shader data, but not all of it>
  <note3: There is a lot of strange padding involved, but it's probably unnecessary when re-compiling because of pointers?>
  
  If there is HLSL11 vertex shader data:
   While (Int64 stream position/position in file) bitwise AND (Int32 number 7) is not 0:
    Byte - number 0
   <pointer ID #1 leads here>
   The buffer/bytes/string for the shader data - the length is found nowhere else, maybe?
    Or it's a possibility that you read until you hit the necessary zero padding before the location the next pointer points to (for the next shader data)?
    Or you just continually read through the zeros until you hit the next shader data (using the pointers)?
  
  If there is HLSL11 pixel shader data:
   While (Int64 stream position/position in file) bitwise AND (Int32 number 7) is not 0:
    Byte - number 0
   <pointer ID #2 leads here>
   The buffer/bytes/string for the shader data - the length is found nowhere else, maybe?
    (same thoughts as above)
    
  If there is PSSL vertex shader data:
   While (Int64 stream position/position in file) bitwise AND (Int32 number 7) is not 0:
    Byte - number 0
   <pointer ID #3 leads here>
   The buffer/bytes/string for the shader data - the length is found nowhere else, maybe?
    (same thoughts as above)
    
  If there is PSSL pixel shader data:
   While (Int64 stream position/position in file) bitwise AND (Int32 number 7) is not 0:
    Byte - number 0
   <pointer ID #4 leads here>
   The buffer/bytes/string for the shader data - the length is found nowhere else, maybe?
    (same thoughts as above)
    
  If there is Cg vertex shader data:
   While (Int64 stream position/position in file) bitwise AND (Int32 number 7) is not 0:
    Byte - number 0
   <pointer ID #5 leads here>
   The buffer/bytes/string for the shader data - the length is found nowhere else, maybe?
    (same thoughts as above)
    
  If there is Cg pixel shader data:
   While (Int64 stream position/position in file) bitwise AND (Int32 number 7) is not 0:
    Byte - number 0
   <pointer ID #6 leads here>
   The buffer/bytes/string for the shader data - the length is found nowhere else, maybe?
    (same thoughts as above)
    
  <note: Take care of the next two: it uses the number 15 for its bitwise AND operation instead of 7)
  
  If there is Cg_PS3 vertex shader data:
   While (Int64 stream position/position in file) bitwise AND (Int32 number 15) is not 0:
    Byte - number 0
   <pointer ID #7 leads here>
   The buffer/bytes/string for the shader data - the length is found nowhere else, maybe?
    (same thoughts as above)
    
  If there is Cg_PS3 pixel shader data:
   While (Int64 stream position/position in file) bitwise AND (Int32 number 15) is not 0:
    Byte - number 0
   <pointer ID #8 leads here>
   The buffer/bytes/string for the shader data - the length is found nowhere else, maybe?
    (same thoughts as above)

[colinator27]

So does this need a GUI implementation sometime?

[colinator27]

Actually, I'm working on a bunch of additions/changes to a whole lot of things right now, including editors for shaders and maybe extensions if I get to it.

[krzys-h]

This can be closed now, right?