zBase (32bpp base set by Zephyris)

[LeXa2]

...extremely bright and saturated and my bridges are coming out very dark and with incorrect colours (light red instead of yellow, dark red instead of red, dark red instead of grey). I want to know what to do to get them looking a bit nicer!

Michi_cc posted a bit simplified details and that's just as it is in blitters now. Important consequence is that you shouldn't believe the info that's written in wiki here:
http://wiki.openttd.org/How_to_Create_3 ... mask_files

Main thing to know when you're trying to deal with the mask is to keep in mind that the pixel is no longer 32bpp as soon as it has non-zero mask value. Think about them as a grayscale 8bpp image coupled with indexed 8bpp image producing the end-result using something like "multiply" layers combine in Photoshop or GIMP.

Mask pixel is not restricted to be from the "company colours" range, you could use any index you want except for 0. Take as example a GRF that is attached to this message: http://www.tt-forums.net/viewtopic.php? ... 1#p1037511. You could decode it with grfcodec ("grfcodec.exe -d lx2tst01.grf") and inspect the contents. There I had manually performed a sort of "8bpp->32bpp" conversion for oil refinery and radio tower and used mask to retain the palette-animated pixels just like they were in original 8bpp sprites.

Back to company colours vs. mask, I'd recommend to perform it using single mask palette index from company colour range (I'd pick 201, 202 or 203) coupled with neutral gray in base 32bpp image to control "brightness" of the result. #404040 would then result in direct translation into colour for chosen palette entry (#400000, #004000, #000040 and any other #xxyyzz where xx <= 40 && yy <= 30 && zz <= 40 and xx or yy or zz equals to 40 would also result in direct translation), #606060 would make it pretty bright, #202020 would darken it about in half and so on.

[Zephyris]

pixel = colour_from_palette * max(R,G,B) / 64

Why is it colour_from_palette * max(R,G,B) / 64?
colour_from_palette * max(R,G,B) / 128 would make far more sense.

At the moment (old in the eg images) with a "sensible" 32bpp render (one which uses all grey values between 0 and 256 to show the shading) and a company colour recolour using the darkest company colour in the 8bpp mask (rgb values of 0, 24, 108) saturates in the blue channel for 32bpp render values above 152.

If a divisor of 128 were used (new in the eg images) then the blue channel would never saturate giving a full tonal range.

If a divisor of 128 were used then the mid tonal range company colours could also be used giving a result more similar to the 8bpp sprites.

[Zephyris]

I looked into this issue slightly more. It is also the reason that the yellow recolouring for bridges gives an orange result instead of yellow; the darkest shades of the yellow used for these bridges are actually orange in hue. If the recolouring were changed to a divisor of 128 then I could use a lighter shade of the browns used for bridge recolouring in the masks which would fix this issue.

[Michi_cc]

Why is it colour_from_palette * max(R,G,B) / 64?
colour_from_palette * max(R,G,B) / 128 would make far more sense.

You'd have to ask peter1138, but I think he tried somewhat matching it to the recolour algorithm in the 32bpp-ez patch.

Nevertheless, the real algorithm is a bit more complicated exactly due to saturation (colour is taken from the palette entry, not the RGB sprite part!):

Code: Select all

		/* Shortcut for normal brightness */
		if (brightness == DEFAULT_BRIGHTNESS) return colour;

		uint16 ob = 0;
		uint16 r = colour.r * brightness / DEFAULT_BRIGHTNESS;
		uint16 g = colour.g * brightness / DEFAULT_BRIGHTNESS;
		uint16 b = colour.b * brightness / DEFAULT_BRIGHTNESS;

		/* Sum overbright */
		if (r > 255) ob += r - 255;
		if (g > 255) ob += g - 255;
		if (b > 255) ob += b - 255;

		if (ob == 0) return Colour(r, g, b, colour.a);

		/* Reduce overbright strength */
		ob /= 2;
		return Colour(
		          r >= 255 ? 255 : min(r + ob * (255 - r) / 256, 255),
		          g >= 255 ? 255 : min(g + ob * (255 - g) / 256, 255),
		          b >= 255 ? 255 : min(b + ob * (255 - b) / 256, 255),
		          colour.a);

[sweetdude]

Zephyris, do you like us to post the bugs in the tracker already if we find them or do you prefer to wait after all the sprites are converted to 32bpp?

Post them as you find them, though it would be good to focus on on bigger issues (e.g. very misaligned sprites, graphics which glitch through their design and similar) rather than little problems (like ugly textures ).

Graphics bugs should go to the zbase repo, issues with alignment and coding should (I believe) go to zbasebuild: https://dev.openttdcoop.org/projects/zbasebuild

Ok, got a bug here but actually no idea how i can backtrace it to a specific sprite number

allignment bug.png (225.03 KiB) Viewed 1165 times

eventually it turns in this one

allignment bug2.png (223.81 KiB) Viewed 1165 times

[Zephyris]

Could you link to that chunk of code somehow? I think I need a bit more context to work out whats going on... Thanks

[sweetdude]

Could you link to that chunk of code somehow? I think I need a bit more context to work out whats going on... Thanks

Sorry, I have absolutely no clue how to accomplish that
But here is a save game if that will help?

Klein Oosterrecht Transport, 3 Feb 1957.sav

(32.86 KiB) Downloaded 179 times

[Zephyris]

But here is a save game if that will help?

Sorry, I should have been more clear, I was referring to Michi_cc's post regarding the code. Your save game will make it easier for me to identify the misaligned sprite though

[Alberth]

Could you link to that chunk of code somehow? I think I need a bit more context to work out whats going on... Thanks

Note sure what you need, but I searched a bit with 'ack':

Code: Select all

%  ack "Shortcut for normal brightness"
blitter/32bpp_base.hpp
138:            /* Shortcut for normal brightness */

ie http://vcs.openttd.org/svn/browser/trun ... e.hpp#L138

Looking for uses of the function that has that comment (AdjustBrightness) gives

Code: Select all

%  ack AdjustBrightness
blitter/32bpp_simple.cpp
44:                                             if (bp->remap[src->m] != 0) *dst = ComposeColourPA(this->AdjustBrightness(this->LookupColourInPalette(bp->remap[src->m]), src->v), src->a, *dst);
125:                    Colour colour = this->AdjustBrightness(this->LookupColourInPalette(src->m), dst[i].v);

blitter/32bpp_anim.cpp
110:                                                            if (r != 0) *dst = this->AdjustBrightness(this->LookupColourInPalette(r), GB(m, 8, 8));
126:                                                            if (r != 0) *dst = ComposeColourPANoCheck(this->AdjustBrightness(this->LookupColourInPalette(r), GB(m, 8, 8)), src_px->a, *dst);
169:                                                    *dst++ = (m >= PALETTE_ANIM_START) ? this->AdjustBrightness(this->LookupColourInPalette(m), GB(*src_n, 8, 8)) : src_px->data;
178:                                                            *dst = ComposeColourPANoCheck(this->AdjustBrightness(this->LookupColourInPalette(m), GB(*src_n, 8, 8)), src_px->a, *dst);
327:                            *dst_pal = this->AdjustBrightness(LookupColourInPalette(colour), GB(*anim_pal, 8, 8));
433:                            *dst = this->AdjustBrightness(LookupColourInPalette(colour), GB(*anim, 8, 8));

blitter/32bpp_base.hpp
136:    static inline Colour AdjustBrightness(Colour colour, uint8 brightness)

blitter/32bpp_optimized.cpp
122:                                                            if (r != 0) *dst = this->AdjustBrightness(this->LookupColourInPalette(r), GB(m, 8, 8));
135:                                                            if (r != 0) *dst = ComposeColourPANoCheck(this->AdjustBrightness(this->LookupColourInPalette(r), GB(m, 8, 8)), src_px->a, *dst);
289:                                            Colour colour = this->AdjustBrightness(this->LookupColourInPalette(src->m), rgb_max);

It seems to be used in all three 32bpp blitters.
This looks like enough to get you started

[peter1138]

I looked into this issue slightly more. It is also the reason that the yellow recolouring for bridges gives an orange result instead of yellow; the darkest shades of the yellow used for these bridges are actually orange in hue. If the recolouring were changed to a divisor of 128 then I could use a lighter shade of the browns used for bridge recolouring in the masks which would fix this issue.

You nearly got there The darkest of the yellow recolourings are orangey. The solution then is to use a lighter colour from the recolour palette, and to dim your pixel slightly to compensate.

/64 was used to allow a larger range of "overbrightness", /128 just didn't cut it.

[Zephyris]

/64 allows such a huge overbrightening though! Which sprites could possibly need that? As it stands a 32bpp render ranging from 0-255 with the darkest shade of company colour in the 8bpp mask is 2x too bright with the white company colour applied in game. The brightness of the 32bpp render could be reduced but that would start to introduce colour banding. If I wanted to use the mid company colour in the mask (which gives a much better hue) I would have to reduce the 32bpp render brightness by about 8x. At that point the colour banding is so severe that there is no difference from 8bpp.

On the other hand If someone needed overbrightening for a sprite using the brighter shades of the company colour in 8bpp anyway, even without the 4x overbrightening...

[LeXa2]

IMO it could be easily changed now to 128 or any other divisor you and rest devs would find appropriate to use as virtually there are no known 32bpp GRFs that use masking (maybe except for fresh versions of OpenGFX+ Trains but I believe it would be fixed there quickly). It's really a one-liner change to static int DEFAULT_BRIGHTNESS initialization and almost nothing more. And this is a kind of decision/change that should be done ASAP or it would require in future to add some flags into Info 32 format to maintain backwards compatibility with existing 32bpp NewGRFs.

Should it be changed or not is a matter of another discussion though the banding issues you mention looks to me as a pretty valid reason for a change. OTOH mask handling could be changed entirely in a some way. Why to use HSV V as a value base (which max(r, g, b) is)? Why not to use (r + g + b) as a value and set divisor to 192 or 288? That way it would give a lot of "space" for overbright and would allow for bandless darken at the same time.

P.S. It would have bad implications on my 32bpp-anim-aa blitter though as currently I conserve the memory and maximize speed by throwing out two of three values among r, g and b upon encoding as there's no point in storing them. But it's not a change it would be impossible to cope with .

[Fanda666]

Hi, found another shimmering texture

[LeXa2]

Hi, found another shimmering texture *image here*

Looks like the by-product of the masked colour remap (but I might be wrong though) and it's just the thing that is being discussed in last few posts.

[Zephyris]

Hi, found another shimmering texture

This looks like sprites used for the different construction stages are a bit mixed up too...

[Zephyris]

I made a test grf to look at company colour recolouring. This just replaces the bus used for the company colour preview with 32bpp shades of gray (left->right) and a mask with the 8bpp company colour values (top->bottom).

Just something to ponder.

[peter1138]

I'm open to change. The current code is based on results of some of the old format 32 bpp graphics.

However, does 1 bit of extra resolution (which I think is what you're asking for) really make enough difference to warrant making graphics incompatible (or maybe just look a bit odd...?) with already-released versions of OpenTTD?

[Zephyris]

However, does 1 bit of extra resolution (which I think is what you're asking for) really make enough difference to warrant making graphics incompatible (or maybe just look a bit odd...?) with already-released versions of OpenTTD?

I would say it is worth it... It is only a small change but I do think it improves the visual quality of the graphics and makes drawing the graphics more intuitive.

Now is the best possible time to do it, and it is the only chance we would get to perfect the algorithm. Only my zBase and GRVTS graphics and Xotic750's trains are designed for this algorithm and it is a simple and scriptable change to update the masks if that was needed.

The current code is based on results of some of the old format 32 bpp graphics.

TBH from my experience there was still a big change from the ez algorithm to this one which meant big updates to the masks sprites of my GRVTS sprites were needed. In short the existing mask sprites from the old tar/png format will need tweaking anyway...

[peter1138]

Any chance you could make another version with the gradient going from 0-127 across instead of 0-255, to compare?

[Zephyris]

Sure, see attached.