replacing terrain graphics, bmp-->pck issue (Hobbes ?)

[robin]

I want to replace the graphics of some terrains (starting from the alien-related ones).

I'd liked to do this in a simple and quick way, so I:
1) convert the .pck into a .bmp (with pckview);
2) draw, then save as .bmp (with appropriate palette);
3) convert back to .pck with pckview (then overwriting the original pck files with my new ones).

But this is what happens, some tiles have "shifted" by 1 pixel horizontally.
This is strange because none of my modifications exceed the original tile width.



Is there a solution to this?
(attached the tileset below)

[Hobbes]

But this is what happens, some tiles have "shifted" by 1 pixel horizontally.

Does this 'shifting' appears when you are visualizing the PCK files on either PCKView or MCDEditor?

[Warboy1982]

try MCDEdit?

[robin]

Does this 'shifting' appears when you are visualizing the PCK files on either PCKView or MCDEditor?

Yes. It happens during the conversion bmp-->pck, the bitmap is fine but the resulting pck is misplaced.

try MCDEdit?

I'll try it. (Link to the latest version?)

https://openxcom.org/forum/index.php?topic=1900.0 ?
https://openxcom.org/forum/index.php?topic=2028.30 ? this one  ?

[Hobbes]

Yes. It happens during the conversion bmp-->pck, the bitmap is fine but the resulting pck is misplaced.
I'll try it.

Then usually the error is in the .bmp file. Usually there's a pixel that PCKView doesn't recognize the color value.

[robin]

Then usually the error is in the .bmp file. Usually there's a pixel that PCKView doesn't recognize the color value.

How can that be though? The image is converted to use the appropriate palette, there's no "extra" or "wrong" color in  it.

[Hobbes]

How can that be though? The image is converted to use the appropriate palette, there's no "extra" or "wrong" color in  it.

I think I got it, check the attached file. On the left side of the image there's an image of one of my tiles and the palette it uses, on the right side there's your tileset and their palette. The first colors are different (they are marked in red).

Try this: open an original tile set, save as bmp one of its tiles. Afterwards open the bmp of your tile, copy the relevant part of the image and paste it over the bmp of the original tile, save it as bmp and load into into the PCK file and see if it gets properly displayed.

[robin]

I think I got it, check the attached file. On the left side of the image there's an image of one of my tiles and the palette it uses, on the right side there's your tileset and their palette. The first colors are different (they are marked in red).

Try this: open an original tile set, save as bmp one of its tiles. Afterwards open the bmp of your tile, copy the relevant part of the image and paste it over the bmp of the original tile, save it as bmp and load into into the PCK file and see if it gets properly displayed.

Yeah the background color changes... it's like they don't use the same color for transparency....

I've downloaded the palettes form this forum (specifically here: https://openxcom.org/forum/index.php?topic=1557.msg16813#msg16813), and I've been using them since the beginning for all my sprites without issues.
Could be that the colors they use for transparency aren't compatible with pckview?

[Hobbes]

Yeah the background color changes... it's like they don't use the same color for transparency....

I've downloaded the palettes form this forum (specifically here: https://openxcom.org/forum/index.php?topic=1557.msg16813#msg16813), and I've been using them since the beginning for all my sprites without issues.
Could be that the colors they use for transparency aren't compatible with pckview?

I've used PCKView for years and it has always been very touchy regarding colors but at the same time, if it loads correctly at PCKView then it will be displayed properly on the original game.

I also got the palettes from that thread but I still simply design over a .bmp of an original image to use the original palette. Otherwise, chances are that one color will be wrongly translated.

[robin]

What software is the one you're using (in that screen)? Photoshop is not being friendly and I need that PCView-compatible palette.

[Hobbes]

What software is the one you're using (in that screen)? Photoshop is not being friendly and I need that PCView-compatible palette.

GIMP but the program is getting that palette from the original image.

[SupSuper]

Yeah the background color changes... it's like they don't use the same color for transparency....

I've downloaded the palettes form this forum (specifically here: https://openxcom.org/forum/index.php?topic=1557.msg16813#msg16813), and I've been using them since the beginning for all my sprites without issues.
Could be that the colors they use for transparency aren't compatible with pckview?

It's likely. For working with images, it's conventional to use "lime" or "pink" as the "transparent color" because it makes it easier to tell the background apart from the sprite.

In OpenXcom the color you use as the "transparent color" in your palette doesn't really matter because it uses "color 0" as the transparent color, not an RGB, so SDL will automatically figure it out when matching extraSprites with the original palettes/graphics.

However there's no guarantee that other programs will behave the same. If they are matching by RGB, you will have to change the first palette color to RGB 0,0,0.

[robin]

It's likely. For working with images, it's conventional to use "lime" or "pink" as the "transparent color" because it makes it easier to tell the background apart from the sprite.

In OpenXcom the color you use as the "transparent color" in your palette doesn't really matter because it uses "color 0" as the transparent color, not an RGB, so SDL will automatically figure it out when matching extraSprites with the original palettes/graphics.

However there's no guarantee that other programs will behave the same. If they are matching by RGB, you will have to change the first palette color to RGB 0,0,0.

I actually already tried that. But it then uses white, instead of that black, for the transparent color.
Also it seems to me that pckview it doesn't use 'pure black' (0, 0, 0) as its transparent color: when you convert .pck files to .bmp using it, the transparent color is 'replaced' instead by a very dark blue-ish-black.
I looked into it too much since I wanted to finish an armor, but I will in the following days.

Also: do you know how to convert .aco swatches into .act color tables? When I try to save directly a color table, it includes only the colors effectively used in the image (photoshop CS4) instead of the whole color table.

[SupSuper]

I actually already tried that. But it then uses white, instead of that black, for the transparent color.
Also it seems to me that pckview it doesn't use 'pure black' (0, 0, 0) as its transparent color: when you convert .pck files to .bmp using it, the transparent color is 'replaced' instead by a very dark blue-ish-black.
I looked into it too much since I wanted to finish an armor, but I will in the following days.

Also: do you know how to convert .aco swatches into .act color tables? When I try to save directly a color table, it includes only the colors effectively used in the image (photoshop CS4) instead of the whole color table.

Dunno, the way I use palettes in Photoshop is to set an image to Image > Mode > Indexed Color, and then I can load and alter the palette in Image > Mode > Color Table. As long as you don't optimize the image, the full 256-color palette should be preserved.

[AndO3131]

This could be another candidate for unhardcoding - 'battlescapeTerrainData' entries

Code: [Select]

      mapDataSets:
        - BLANKS
        - U_EXT02
        - U_WALL02
        - U_BITS
      mapBlocks:
        - name: UFO_110
          width: 10
          length: 10
could be expanded in future 'resource' entry.