I've been doing a bit more idle fiddling with this stuff. What follows is rather long, but sums up what I've been learning about making skins, and how the game handles them.
I happen to be using the free nVidia Photoshop plugin for DDS, just because I have an old version of Photoshop which I've had for years, and which still does everything I want it to do. I haven't yet tried messing with DDS files in GIMP, so can't give an opinion on that. However, I have just noticed (after actually looking through the options
) the nVidia plugin does give you the choice of forcing binary alpha. This makes perfect sense, since DDS is only used for game files AFAIK, and a lot of older games relied on binary alpha. After a quick test, setting the binary threshold to 0 seems to work well.
The problem is that it is limited in which files it will accept for processing. Trying to go straight from PSD to DDS, which would be ideal, doesn't work because the PSD has too many channels for the plugin to handle. That means an intermediate step (to another image format) is still necessary. The basic idea of using a temporary image format that will allow forcing binary alpha (transparency) is still a winner, IMO. You can use either png-8 or gif for forcing the transparency, since in terms of results they are indistinguishable.
However, PNG-8 and gif both use restricted palettes, which can cause banding or other problems with some images. I've found that the plugin will handle PNG-24 images without dramas, which allows an unrestricted palette, but the catch here is that the final DDS will have a restricted palette anyway, so I'm not sure there will ever be any advantage in using PNG-24 as the temporary step.
The one real catch with this method is that it forces binary alpha everywhere, meaning the bits of the train that you might want to glow in the dark (lights, windows, etc) wont do it. They'll just come out as solid colour. This isn't a huge deal, but it's a niggle and I've found a way around it. Turns out that once the plugin has saved a file as DDS, Photoshop will then quite happily edit it, even though it wont edit DDS files exported straight from the game's default folders. Go figure.
This means you can save a DDS skin and then open it in PS to play with the alpha channel, putting it to non-binary in the small areas where you want night glow. This is a bit of a fiddle, but
far less work than trying to get rid of unwanted night glow everywhere else. Since the alpha channel in any image can be edited just like any grayscale image, you can just cut and paste any bits you want to change. So, to get a headlight glowing again all you need to do is copy the relevant part of the alpha channel from another file (like a default skin) or simply use a selection to put bounds around the area, then some shade of grey and a brush to add your own in the right spots.
-------------------------------------------------------
Next thing I've been grumbling to myself about
is the game's rendering abilities. They suck. They totally suck things which nobody should have to suck, and which your mother may have warned you about if she could bring herself to mention them. However, we is stuck with what the game can do.
The quality of work in many (not all) of the default skins is actually pretty high, but when rendered in the game they look a lot worse than an inspection of the DDS would lead you to expect. Basically, colours get muddy and lines get blurred. I'm not sure there is anything that can be done about the colours getting muddy. I know DDS does use a restricted palette that loses some information compared to a normal RGBA image (
good basic description of the problem here) and my guess is that the image you see when looking at a saved DDS does not have the same palette that the game uses on the fly to render the image. IOW, I think most of the information loss happens on rendering, not on saving. This means getting a skin to look good in the game is trickier than just getting it to look good in your image editor. Good ol' RT3. You can always trust it to make simple jobs more difficult for you.
TGA dosn't have the same palette restrictions as DDS, but that doesn't necessarily mean the game will be capable of rendering it properly. I did notice that
Itsa Timmy posted a screenshot of a double diesel which has one loco done as DDS and another as TGA. The TGA does seem brighter and sharper. When I get the time and inclination I'll do a side by side comparison using both DDS and TGA skins, and see if the TGA gives any noticeable improvement in quality. If it does, it may be worth using. If not, sticking with DDS would be better for performance.
The blurring of lines can only be dealt with in one way, and that's by increasing the resolution (scale) of parts that need to look better. Even small changes should have a noticeable effect. Resolution is dependent on pixel density, which varies as the square of the linear dimension. IOW, making a part 10% bigger on the skin will give a roughly 20% increase in detail. The current skin for the Berkshire project has sufficient clear space to give roughly 15% scale increase for a lot of major components, which in theory would mean getting one third better detail than default. Means a lot of gfx remapping, which is a PITA, but should make a better looking unit if anyone can bring themselves to do it.
-------------------------------------------------------
There's another thing or two I've found, but this is getting into .3dp and hex nastiness, so skip the following if you're only into skins.
I've thought of a way of cleaning up some of the coding to make it more readable (relatively speaking). It'll never be truly human-friendly but it can be improved a bit. The thing is that the IEEE 754 single precision floating point format used for coordinates is as nasty and tricky as the name makes it sound. The default game files often contain a jumble of letters and numbers that appear to make no sense. Part of this is down to the nature of the format. Very small rounding errors in the gfx app used to create the default files can lead to wildy different looking hex code for two points that actually share the same coordinate. This makes the file far more confusing than it needs to be, since it's easier to figure out which face is where if some coordinates are the same (like for the edge of the smokebox, all y axis coordinates should match).
If you are editing a default file, it helps if you rationalise the hex for the coordinates a bit. Here are two shots, showing the default hex and how you can change it to be slightly less headbutt-inducing.
- Default_code.png (45.2 KiB) Viewed 6671 times
- Evened_up.png (43.39 KiB) Viewed 6671 times
Also, if something should be 0 but is coded as something-not-quite-zero, change it. A good example is from the TrackPoint.3dp for the default Duke locomotive. The intended value for it is 0 for all three axes (ie: in the middle of the track, halfway along the loco) but the default hex says 17 B7 51 37 00 00 00 00 17 B7 51 37.
If you run 17 B7 51 37 through a base converter you'll see that it is 0.00001250 in normal decimal. That equates to a difference of roughly 0.0001250" for a full scale locomotive and track, which you'll never notice in the game but which makes the code more confusing. If it just says 00 00 00 00 00 00 00 00 00 00 00 00 it makes more sense when pigging around in the files.
Note that 00 00 00 00 is not the only way that 0 can be coded. 00 00 00 05 is still 0. So is 00 00 00 0F. In terms of hex these are all the same, but they're a PITA for humans. Take the easier option and make it just say 00 00 00 00.
This the leads into the next box of tricks. Because some of the bytes in this format are less important than others, you can use this to make any custom code more digestible. Starting with the "evened up" code from the previous screenshot, here you can see the effect of going further and changing the first byte to 00. The base converter shows that the difference in positioning is only about 0.0001 of a unit, which scales to about 0.001" on a full sized loco. Being able to effectively skip one byte makes things less mind-boggling when you're looking at walls of bytes.
- Cleaner_code_1.png (17.22 KiB) Viewed 6671 times
Ok, so how far can you take this? It depends on the values you need, but often it can be taken quite a bit further than you might think. Two more examples below. In these cases the difference from the original is 0.22" and 0.09" respectively at full scale. Even the worst one is only about 1/4" out, and the second one only about 1/10" out. Anyone who doesn't think this is close enough for many points in RT3 models is even more OCD than I am.
- Cleaner_code_2.png (17.04 KiB) Viewed 6671 times
- Cleaner_code_3.png (16.93 KiB) Viewed 6671 times
My 2c is that these last two examples are far easier to deal with, in terms of boggling of our brains when editing files, than the default code. I can remember 4 random bits of gobbledegook much easier than I can remember 8.
Слава Україні! 
