Number Madness

[JM1261]

Hi all,

First off, apologies if this is in the wrong section. I wasn't sure if it belonged here or in rolling stock design. Anyways, I'm currently working on a repaint for the Dash 8-40CW which comes with the Miami - West Palm Beach DLC. I've been having a peculiar issue with painting the numbers. Whenever I save my changes and reload/save the .dds, something wonky occurs and this is how the texture appears when I import it using RSBinTool:

examplea.jpg

The alpha texture has its share of problems, as well:

exampleb.jpg

Has anyone else ever encountered this issue? If so, do you have any remedies? Thanks in advance to any and all responses, and I'd be glad to provide more information if I need to.

[buzz456]

Is this a number file or what?

[JM1261]

Is this a number file or what?

Yes, it is a number file. This is happening with each one.

[harryadkins]

It might help if you would list your process for reskinning.

[JM1261]

It might help if you would list your process for reskinning.

I export the texture file with RSBinTool into my projects file, etc. I'll then open up the .dds and send the texture to PaintShop for editing. Once that's done, I reload the .dds so it now shows the edited version, and I'll resave it as DDS DXT5 format. As soon as I save the file, however, it becomes the corrupted mess you see above.

Bear in mind that this only happens with the number textures and nothing else. I'm able to import and export other textures without any problems.

[buzz456]

I don't do it that way but it seems that somehow it's not saving it as a bmp before going to the dds. I'm not using Photoshop but in GIMP you need to export it not just save it.

[JM1261]

I don't do it that way but it seems that somehow it's not saving it as a bmp before going to the dds. I'm not using Photoshop but in GIMP you need to export it not just save it.

Now that you mentioned it, I believe I have GIMP installed on here somewhere so I'll try using it instead and see if that makes a difference.

[JM1261]

After tinkering with this for nearly an hour, I can safely say that it has nothing to do with my editing software. Rather, it appears that this is more of a technical issue with the .dds file itself becoming corrupted as soon as it's loaded. Case in point, I went into one of the files and simply reloaded what was there - no texture editing whatsoever. Even with that I still got a corrupted image.

What's more is the fact that even previewing what I have without editing a single thing gives me the same distorted result. Again, it's only with the numbers and nothing else - the textures for the actual engine itself all reload and import fine. Additionally I haven't had this issue with any other DTG locomotive, so I am completely stumped.

Image2.jpg

[buzz456]

I think I ran into this once before now that I looked into it. These files are a real odd number 384x128. You can see from the picture that when I opened it with DXTbmp it opened it ok. After I saved it from the editor and opened again it changed the size to 512x128 without me telling it to do that.

Miami 0.jpg

Since RWTools does automatically what I did manually I am guessing that it's doing some sort of gyration like this causing the problem. I can't remember offhand how I fixed this problem however will mess around with it some more and see if anything triggers the old memory.

[buzz456]

I just took the original .dds opened it in DXTbmp and then just saved it as .dds without sending it to the editor or doing anything to it. Then I went and opened the .dds again and look what showed up. Note what the alpha looks like. I didn't do anything to it either.

Miami goofy.jpg

[JM1261]

I just took the original .dds opened it in DXTbmp and then just saved it as .dds without sending it to the editor or doing anything to it. Then I went and opened the .dds again and look what showed up. Note what the alpha looks like. I didn't do anything to it either.

At least I now know it's not just an issue on my end. Wonder why its only happening with the numbers and nothing else? I wish I had some theories but unfortunately, I'm stumped.

[ChrisOnline]

I have found the best way to overcome this is to start by converting the ORIGINAL .TgPcDx texture to a .dds using RW_Tools (noting the format - DXT5 ARGB in this case), leave that RW_Tools window open, edit the DDS file, and save it using the same format (e.g. DXT5 ARGB). Then use RW_Tools (the same open window) to convert it BACK to .TgPcDx and overwrite the original. RW_Tools automatically generates a .bak file for you, and the overwrite seems to ensure the format is identical.

[JM1261]

I have found the best way to overcome this is to start by converting the ORIGINAL .TgPcDx texture to a .dds using RW_Tools (noting the format - DXT5 ARGB in this case), leave that RW_Tools window open, edit the DDS file, and save it using the same format (e.g. DXT5 ARGB). Then use RW_Tools (the same open window) to convert it BACK to .TgPcDx and overwrite the original. RW_Tools automatically generates a .bak file for you, and the overwrite seems to ensure the format is identical.

This did the trick! Thanks a lot for the suggestion!

Buzz, thanks for your input as well.

[ChrisOnline]

I have found the best way to overcome this is to start by converting the ORIGINAL .TgPcDx texture to a .dds using RW_Tools (noting the format - DXT5 ARGB in this case), leave that RW_Tools window open, edit the DDS file, and save it using the same format (e.g. DXT5 ARGB). Then use RW_Tools (the same open window) to convert it BACK to .TgPcDx and overwrite the original. RW_Tools automatically generates a .bak file for you, and the overwrite seems to ensure the format is identical.

This did the trick! Thanks a lot for the suggestion!

Buzz, thanks for your input as well.

You're welcome, glad to be of help!