32bit Graphics Extra Zoom Patch

[maquinista]

How does 2CC work with the extra zoom level method of CC recolouring? If a 2CC palette index is in the mask image does it get recoloured correctly?

Yes, if it is in the mask image, and the palette is correctly filled in, it will lookup the 8bpp colour index and translate it to 32bpp. Haven't tried though if this works in practice.

Cmoiramain: added to my personal list of items to solve.

I have added the CC mask for some livestock wagons and It works:

[neob]

The feature that allows station tiles with two or more ground sprites is awesome.

a lot of potential

[peter2]

thanks for the binnaries great patch gives me a new interest in the game

[Zephyris]

So, what have I done wrong?

Screenshot1.png (298.38 KiB) Viewed 4358 times

(I am referring to the lack of shading on the CC and 2CC, not the messed up offsets)

Using the x64 version posted here.
An example sprite and mask are attached.

[maquinista]

The CC mask are good, They are in indexed mode and They have the correct values.
Try to take another screenshot with less saturation. Open the view port, and hold the 3 key two or three seconds, and press CTRL + R.

The problem could be caused by the CC algorithm. It's experimental and It could have some improvements.
IMHO the algorithm shouldn't increase the original saturation of the pixels. It should be allowed only to decrease it.

I could try to modify the CC algorithm, but I don't know where the saturation is modified.

[Zephyris]

Open the view port, and hold the 3 key two or three seconds, and press CTRL + R.

Ummm, This doesn't seem to do anything... I tried it in the main viewport and an extra viewport.

IMHO the algorithm shouldn't increase the original saturation of the pixels. It should be allowed only to decrease it.

Having helped write the algorithm I think I can help here! The algorithm can't calculate the saturation of a pixel in the sprite (easily) without knowing the hue of that pixel, and there is no standard hue used across original sprites for CC regions. Therefore the algorithm simply ignores the hue and saturation data of the original sprite and only uses the pixel brightness for the CC calculation. It should never give the result I am seeing as there is definately an underlying variation in brightness.

I could try to modify the CC algorithm, but I don't know where the saturation is modified.

As I understand it the saturation is stored in the presets for company colours, so this would be the place to change it.

[Zephyris]

Does this give some hint to the problem? It looks to me that the CC algorithm isn't running at all for some reason; I would expect the company colour schemes to look different (ie. no difference between red/pink etc). If the new CC algorithm isn't running that would explain why the lorry sprite CC is being recoloured to flat CC (the colour on the mask sprite) instead of being calculated properly...

[maquinista]

Open the view port, and hold the 3 key two or three seconds, and press CTRL + R.

Having helped write the algorithm I think I can help here! The algorithm can't calculate the saturation of a pixel in the sprite (easily) without knowing the hue of that pixel, and there is no standard hue used across original sprites for CC regions. Therefore the algorithm simply ignores the hue and saturation data of the original sprite and only uses the pixel brightness for the CC calculation. It should never give the result I am seeing as there is definately an underlying variation in brightness.

The saturation (or chroma) is the difference between the highest RGB value and the lower value. It can be calculated easily from original colours.

http://en.wikipedia.org/wiki/HSL_and_HSV#Hue_and_chroma

[Zephyris]

The saturation (or chroma) is the difference between the highest RGB value and the lower value. It can be calculated easily from original colours.

Apologies, you are totally right. I had another look over the code and the info taken from the sprite is the saturation and the brightness, only hue is ignored. The company colour is produced by adjusting the saturation and hue, and if I understand the CC presets right then the saturation modifications are either nil or less saturated.

[GeekToo]

Looking at the purple letters, I'd say you started the 32bpp-simple, iso of 32bpp-optimized blitter. And then you have the original sprite masking. Zooming out probably looks funny too.

[Zephyris]

Looking at the purple letters, I'd say you started the 32bpp-simple, iso of 32bpp-optimized blitter. And then you have the original sprite masking.

Aaaah, thankyou

[GeekToo]

Update:
-sync to trunk
+
-force to always use the 32bpp-optimized blitter
-better catenary drawing order
-solved some problems with track fence drawing
-minor fixes

[neob]

binaries

[petert]

binaries

Try to upload the correct diff file, for 19167, as I see you've upload GeekToo's diff.

[neob]

i applied his 19167 diff on the trunk which was 19180, no conflicts, no errors.
is that a problem?

[NekoMaster]

i applied his 19167 diff on the trunk which was 19180, no conflicts, no errors.
is that a problem?

Probably not, but try testing everything just to make sure

[petert]

i applied his 19167 diff on the trunk which was 19180, no conflicts, no errors.
is that a problem?

No, just provide the new diff. Even when there aren't conflicts, there are usually some offsets.

Probably not, but try testing everything just to make sure

What else should neob have tested, exactly?

[Antonio1984]

Update:
-sync to trunk
+
-force to always use the 32bpp-optimized blitter
-better catenary drawing order
-solved some problems with track fence drawing
-minor fixes

thanks GeekToo for the patch, and thanks neob for the various binaries!

[neob]

a quick question regarding the scale algorithm, if there a z2(32bpp in normal zoom) sprite presented but no z0 (fullzoom)
which sprite will the algorithm scale the z2 or the 8bpp ?

---
p.s. Antonio1984, thanks but its 'GeekToo' who does all the heavy lifting

[GeekToo]

the 8bpp for zoom in, the 32bpp for zoomout