zBase (32bpp base set by Zephyris)

[B. Hakluyt]

Hi there

Sorry, I did not read through the whole thread but when trying to download the latest, or any set for that matter from: http://bundles.openttdcoop.org/zbuild/push fails every time. Is there perhaps another place to download the zbase graphics from? Maybe a torrent? I am in Africa and particularly here in the bush where I am now does not seem to have decent enough internet speeds. Any help in this regard would be much appreciated since I would really like to check out this 32bbp graphics.

Regards

[planetmaker]

There was some transient network issue. It works for me (again).

[Zephyris]

This is basically a can of worms that has been discussed to length in this topic: http://www.tt-forums.net/viewtopic.php?f=36&t=59251
I don't remember the outcome, but it may be worth reading before you end up suggestion all kinds of things that were suggested before.

Would it be possible to simply draw a black background then the sprites? It would not fix the problem of sprite edges but it would guarantee no glitches and ensure consistent and glitch free behaviour no matter what sprite edges are being used. I can't imagine there would be much performance hit from pre-filling dirty patches with black.

[LeXa2]

This is basically a can of worms that has been discussed to length in this topic: http://www.tt-forums.net/viewtopic.php?f=36&t=59251
I don't remember the outcome, but it may be worth reading before you end up suggestion all kinds of things that were suggested before.

Would it be possible to simply draw a black background then the sprites? It would not fix the problem of sprite edges but it would guarantee no glitches and ensure consistent and glitch free behaviour no matter what sprite edges are being used. I can't imagine there would be much performance hit from pre-filling dirty patches with black.

It's possible, and my screenshots leveraging the problem are taken with the version of the engine that had been specifically modified to do exactly that, with the only exception that I had been using yellow colour instead of black to fill the parts of the screen that are being redrawn. Trouble is that it is not extremely fast operation really (but it is not _that_slow_ also) as updates usually happen not for the entire screen but only for parts that need to be updated. Thus we can't simply use one call to a C lib telling "fill this entire memory area with zeroes", it would be required to do one call per one updated line (i.e. if the updated region is 15 in height - we would have to call memset 15 times in a row).

If is it OK or not to sacrifice performance a bit to gain deterministic ViewportDoDraw() behavior is a question that only devteam guys could answer. IMO it's a better solution than just leaving it as it is now. On the other hand it's better to have correctly baked land tiles strictly having opaque pixels at places where they're should be and as zBase is currently WIP it is something that could and should be addressed now, before it'd became too late to fix.

[Alberth]

Would it be possible to simply draw a black background then the sprites? It would not fix the problem of sprite edges but it would guarantee no glitches and ensure consistent and glitch free behaviour no matter what sprite edges are being used

Euhm, glitch-free snowy tiles by painting black?

It beats a random colour of course

[FooBar]

Maybe a 50% grey then

[LeXa2]

Maybe a 50% grey then

No matter the colour used it won't be a "glitch-free solution" in general - for example neutral gray colour would look silly when combined with some sprites, like pretty dark road texture as used in zBase. And it won't work properly for sprites like #2170 or #2172 - you'd end up with neutral gray seams crossing the walls of the buildings revealing that in fact it's just several land tiles textured in a clever way. What filling would ensure is that (for the most part) redrawing some part of the viewport at arbitrary screen coordinates would be deterministic, i.e. there won't be randomness in visible glitches - nothing less nothing more. The only real glitch-free solution is to have land tile sprites done in a proper way.

[Zephyris]

Euhm, glitch-free snowy tiles by painting black?

Any bg colour will be 100% predictable = glitch free. It doesn't matter what the colour is, any neutral colour would do, to get rid of weird artefacts.

[Streckenläufer]

Hello,

openttd-1.2.2-RC1 zbase r88 +, compiled source, no further *. grf
I discovered here this graphic errors (street lights) are a little confused.

[Alberth]

Street lights offsets got fixed a few days ago.
(It seems quite impossible to give you a revision, as the zbase repo itself does not contain the offset data)

[Streckenläufer]

Hello,

was discovered in version 1.2.2-RC1 with zbase123 without *. grf this graphic error.

[Rubidium]

That issue is known as http://dev.openttdcoop.org/issues/4154

[MrRB]

Dear everyone, excuse me for barging in on this thread. However I have a few things to ask, related to 32bpp and zBase.

I'm not new to TTD or OpenTTD for that matter, I've got a lot of sets, new AI's etc. etc. However, I want to improve the graphics. I've read about it and ended up with 2 keywords: "32bpp" and "zBase". However the information is so scattered and I'm not a techy or anything.

That's why I'd like to ask what I should do to get better graphics. 32bpp seems to help, but I can't find out where or how to get it. Plus I wonder what zBase adds to that or whether it's mandatory if you'd like to play with the 32bpp version.

And... Does playing with 32bpp and/or zBase change anything about the practicalities of playing OpenTTD?

Oh yes, for an example of the level of detail I'm talking about, something like this:
http://www.tt-forums.net/files/openttd_ ... 75_201.png

Thanks for any clarification!

All the best.

[Zephyris]

I have updated the first post of this thread with some instructions on how to install zBase. Let me know if anything is unclear and I will update it for you.

zBase is "just" a base graphics set so it changes nothing about the gameplay but it does add high resolution high bit depth graphics. Some buildings may look slightly different, some vehicles may look slightly different, but it will all behave exactly the same as normal OpenTTD.

[Fanda666]

this graphics bug known?

[Zephyris]

I have spotted it, but it is not in the bug tracker. I need to do some more work on tunnels soon anyway as there are some additional sprites I have not made yet

[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?

[Zephyris]

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

[Zephyris]

An open question for anyone in the know:

How does 32bpp recolouring (company colour, bridges, etc) actually work; i.e. how are the pixel colours calculated? My company colours are coming out 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]

I remember writing about that, but just where is that fricking post... Ah, found it

For each pixel, trunk will calculate the brightness from the RGB values (which is simply max(R,G,B)) and use it to modulate the colour corresponding to the mask colour index (brightness == 64 means no change, 128 means double brightness and 32 half and so on). There's some trickery involved to avoid numeric overflow, but that's the basics. The result is similar to the ez recolour, but not identical.

http://www.tt-forums.net/viewtopic.php? ... 4#p1028154

E.g: pixel = colour_from_palette * max(R,G,B) / 64, which means that as soon as you have a mask pixel that is not colour index 0, the colour is taken from the palette while the brightness is (partially) taken from the RGB image.

-- Michael Lutz