Width detection fails for certain (GFX) cl2 files about d1-graphics-tool

[AJenbo]

PlrGFX\Warrior\wlb\wlbat.CL2

Odd. If I inspect the header of this file it clearly indicates that it should be a 96x128 sprite and not the actual 128x96.
This might well result in graphical glitches in vanilla in multiplayer if a warrior with light armor is firing the bow while partially below the lower part of the screen.

(2 blocks of 32px height, we would have expected 3 blocks for 128 rows)

compared to a sprite with the same dimensions:

[AJenbo]

Also if i hard code the width and only decode the second block we can see that the header wasn't pointing to the start of a row:

(a bit less then 43 rows instead of 32)

The proposed solution isn't easy to implement as the program hold sprites is in a list of pixel rows, and the input box isn't available until after the image has been decoded.

[pionere]

Also if i hard code the width and only decode the second block we can see that the header wasn't pointing to the start of a row:

The game does not really care about the header (or the blocks), just reads the byte-array as is using the specified width.

The proposed solution isn't easy to implement as the program hold sprites is in a list of pixel rows, and the input box isn't available until after the image has been decoded.

Right, it is a bit unfortunate that reloading the image is a bit complicated... :(

[AJenbo]

The game does not really care about the header (or the blocks)

For the most part, but it (vanilla) uses the blocks are used to skip part of the sprite during rendering if they are not fully onscreen.

Right, it is a bit unfortunate that reloading the image is a bit complicated... :(

It looks like this could be the same issue as with monsters/fireman/firema.cl2.

I'm thinking that a more viable solution is to have patches for correcting the broken headers. But that would be out of scope of D1GT imo.

Another option would be to have a list of known widths for problematic sprites and hard code an overwrite list in the application. Thought I'm not sure how we should best identify the sprite.

firema.cl2 can be detected as a bad header since it does not have the correct amount of pixels for an 128x* image, but wlbat.CL2 unfortunately does

[pionere]

For the most part, but it (vanilla) uses the blocks are used to skip part of the sprite during rendering if they are not fully onscreen.

Uhm... No. Where do you see that?

It looks like this could be the same issue as with monsters/fireman/firema.cl2.

Might be, but it is unused in the game.

I'm thinking that a more viable solution is to have patches for correcting the broken headers. But that would be out of scope of D1GT imo.

Changing the headers is not enough, the byte-array should be modified as well. So it is even worse...

Another option would be to have a list of known widths for problematic sprites and hard code an overwrite list in the application. Thought I'm not sure how we should best identify the sprite.

I don't think it is worth to hardcode these problematic sprites. If it is too complicated to solve in a generic way then just leave it...

[AJenbo]

For the most part, but it (vanilla) uses the blocks are used to skip part of the sprite during rendering if they are not fully onscreen.

Uhm... No. Where do you see that?

I'm happy to point you to it, but I don't appreciate the sassiness:
https://github.com/diasurgical/devilution/blob/f1b85a5cd3751363d248f7a2a460d527f69c2a32/Source/engine.cpp#L1099
https://github.com/diasurgical/devilution/blob/master/Source/scrollrt.cpp#L1711
https://github.com/diasurgical/devilution/blob/master/Source/scrollrt.cpp#L236

Might be, but it is unused in the game.

I don't see how that makes it more or less relevant for D1GT?

[AJenbo]

Changing the headers is not enough, the byte-array should be modified as well. So it is even worse...

Arh, I was hoping that the data encoding did not cross the 32 row line :(

Patching the header to 10,580,1153 make the first chunk come out to the correct width (because of integer rounding), but the second one is seen as 97 which causes D1GT to discard the result and give up. We could remove the sanity check, but you are probably right that this isn't worth it.

[pionere]

I'm happy to point you to it, but I don't appreciate the sassiness: https://github.com/diasurgical/devilution/blob/f1b85a5cd3751363d248f7a2a460d527f69c2a32/Source/engine.cpp#L1099 https://github.com/diasurgical/devilution/blob/master/Source/scrollrt.cpp#L1711 https://github.com/diasurgical/devilution/blob/master/Source/scrollrt.cpp#L236

Ok. Now that is really ugly. Good job cleaning that up!

Might be, but it is unused in the game.
I don't see how that makes it more or less relevant for D1GT?

Just wanted to point out that it is less important and last time I checked it might be FUBAR anyway....

[AJenbo]

@mewmew I think you figured out what was wrong with firema.cl2. Is it mostly just bad headers or does it require a re encoding to be fully correct?

[mewmew]

@mewmew I think you figured out what was wrong with firema.cl2. Is it mostly just bad headers or does it require a re encoding to be fully correct?

Yeah, firema.cl2 is broken in retail. If memory serves me right, the alpha release has a working copy of firema.cl2/cel in monsters/fireman/firema.cel

[AJenbo]

I think the conclusion here is that these 4 files are invalid and should be fixed externally before they can be used in a normal build.

One way to do so is using https://github.com/diasurgical/devilutionx-mpq-tools which will convert them to .clx (CLX is also supported by D1GT) which doesn't have this issue.

Once we have support for writing .cl2 they can then be exported to a valid .cl2 if so desired.