Questions about "advanced sprite layout"

[michael blunck]

I´m experimenting with the "advanced sprite layout" feature, but I get an error message from OTTD:

invalid or unknown format for spritelayout (sprite 3149)

This is sprite 3149:

Code: Select all

3149 * 0 02 0f 04 42 <9a 0f 00 00> <04 00 00 80> <00 00 00> <10 10 08>
	<00 00 00 80> <02 00> <00 00 08> <08 08 10> <10>   

As can be seen, this spritelayout consists of a ground sprite and a 1st building sprite w/o any usage of the advanced sprite layout features, and a second building sprite, making use of it by adding an offset to this very sprite.

Notation of the "advanced sprite layout" in the Wiki is as follows:

Code: Select all

<Sprite-number> * <Length> 02 07/09/0F/11 <set-id>
                  <0x40 + num-sprites>
                  <groundsprite> <flags> [<register/value>]...
                  [<buildingsprite> <flags>
                    (<xoffset> <yoffset> <zoffset> <xextent> <yextent> <zextent> | <xpixeloffset> <ypixeloffset> 80)
                    [<register/value>]...
                  ]...

Question is whether indeed all the sprites in an advanced sprite layout have to specify a <flag> value as specified above? Even "static" sprites (e.g., not using a sprite offset at all)? Especially a ground sprite? Or is it allowed to supply a flag value of zero to circumvent the need to include a <flags> value? And not using any <register/value> in this case too?


Second question is w/r to bit0 of <flags>. This is barely documented:

"Skip bounding box including child sprites" resp "Skip sprite".

What does this mean? Skipping in relation to a certain register value?

regards
Michael

[frosch]

I cannot make any sense of your example sprite, so I cannot correct it. However, wrt. your other questions:
All entries in the spritelayout - including the primary ground sprite - need a <flags> value. If <flags> is zero, you do not need to specify any registers.
Your other questions are likely answered in the "Register or value in advanced sprite layouts" section in the specs. Some flags take registers, some take none. The meaning of the "skip" flag is also described there.

[michael blunck]

I cannot make any sense of your example sprite

That should be obvious, but let me try again:

Code: Select all

3149 * 0 02 0f 04 42 // number of sprites (ex ground sprite) = 2
	9a 0f 00 00 // ground sprite
	04 00 00 80 // 1st building sprite
	00 00 00 // building sprite bb coordinates
	10 10 08 // building sprite bb sizes
	00 00 00 80 // 2nd building sprites
	02 00 // flags = set sprite offset
	00 00 08 // 2nd building sprite bb coordinates
	08 08 10 // 2nd building sprite bb sizes
	10 // regsiter to be used for 2nd building sprite  

so I cannot correct it. However, wrt. your other questions:
All entries in the spritelayout - including the primary ground sprite - need a <flags> value. If <flags> is zero, you do not need to specify any registers.

Question was if a flag value of zero would be allowed at all, i.e. if a sprite in an advanced sprite layout may be handled as a "normal" sprite (i.e. without using the special adv sprite layout features). This is not documented, but indeed the BNF notation suggest that there must always a <flag> value be set (probably zero). I wanted to know if this interpretation is correct.

In lights of this, is the above code (omitting <flags> for "static" sprites) correct?

For testing puroposes, I´ve added empty <flag>s like this:

Code: Select all

3149 * 0 02 0f 04 42 // number of sprites (ex ground sprite) = 2
	9a 0f 00 00 // ground sprite
	00 00 // no flags
	04 00 00 80 // 1st building sprite
	00 00 // no flags
	00 00 00 // building sprite bb coordinates
	10 10 08 // building sprite bb sizes
	00 00 00 80 // 2nd building sprites
	02 00 // flags = set sprite offset
	00 00 08 // 2nd building sprite bb coordinates
	08 08 10 // 2nd building sprite bb sizes
	10 // regsiter to be used for 2nd building sprite  

This doesn´t generate an error but "it does not work", i.e. the value set in register 0x10 isn´t added to <00 00 00 80>.

Is this code correct?

Your other questions are likely answered in the "Register or value in advanced sprite layouts" section in the specs. Some flags take registers, some take none.

That wasn´t the question.

The meaning of the "skip" flag is also described there.

Ah yes, found it. Thanks.

regards
Michael

[frosch]

Your second code example looks correct to me. You always have to define flags, even if they are 00 00, else there is no definite way to decode a sprite.

[michael blunck]

Your second code example looks correct to me. You always have to define flags, even if they are 00 00, else there is no definite way to decode a sprite.

After a short break, I´ve undertaken some more investigation.

Depending on the layout of the action1 sprite block, "sprite offsets" are handled differently.

E.g., for the code below, this works:

Code: Select all

     4 * 4	 01 0F 01 04
    5 sprites\lights.pcx 10 50 09 48 13 -5 -39
    6 sprites\lights.pcx 27 50 09 48 13 -5 -39
    7 sprites\lights.pcx 44 50 09 48 13 -5 -39
    8 sprites\lights.pcx 61 50 09 48 13 -5 -39

but this does not:

Code: Select all

    4 * 4	 01 0F 04 01
    5 sprites\lights.pcx 10 50 09 48 13 -5 -39
    6 sprites\lights.pcx 27 50 09 48 13 -5 -39
    7 sprites\lights.pcx 44 50 09 48 13 -5 -39
    8 sprites\lights.pcx 61 50 09 48 13 -5 -39

It seems that advanced spritelayout´s "sprite offset" only handles sprites in the same sprite set, but it doesn´t handle sprites in consecutive sprite sets containing e.g. only one sprite.

This is problematic, because some TTD features might have only one sprite ("view") defined per sprite set, which can´t be accessed by using the "sprite offset" ...

I mean, even the sprite aligner tool regards such sprites as consecutive.

Any solution?

regards
Michael

Code: Select all

// Automatically generated by GRFCODEC. Do not modify!
// (Info version 7)
// Format: spritenum pcxfile xpos ypos compression ysize xsize xrel yrel
    0 * 4	 0B 00 00 00
    1 * 32     08 07 "MB" 00 00
                "adv sprite layout test" 00
                "mb" 00

    2 * 22     04 0F FF 01 1C D0 "lighthouse test" 00

    3 * 48	 00 0F 0E 01 00
                        08 "MCXX"
                        09 1C D0
                        0A 1C D0
                        0B 07
                        0C 11
                        0D 14
                        0E 52 B3 0A 00
                        0F ED 08 0B 00
                        10 40 00
                        17 04

    4 * 4	 01 0F 04 01
    5 sprites\lights.pcx 10 50 09 48 13 -5 -39
    6 sprites\lights.pcx 27 50 09 48 13 -5 -39
    7 sprites\lights.pcx 44 50 09 48 13 -5 -39
    8 sprites\lights.pcx 61 50 09 48 13 -5 -39

    9 * 23	 02 0F 00 41
                        00 00 00 00  00 00                          // groundsprite
                        00 00 00 80  02 00  00 00 00  10 10 30  11  // building sprites, offset by reg 0x11

   10 * 18       02 0F 00 81 48 20 FF 0E 1A 00 11 01
                        00 00  00 00
                        00 00

   11 * 7	 03 0F 01 00  00 00 00