zBase (32bpp base set by Zephyris)

[Rubidium]

Good luck with your new job. The biggest part (50%) of missing sprites is in the snowy-ish river banks/locks.

[Fanda666]

Hello I noticed a shift of two sprites at the cinema and the theater.


P.S. when the building will be painted? itching to see

[Lord Aro]

Just looking at that screenshot, i think that the depot roof could do with some improvement - it doesn't quite look like a roof...

Everything else i see is as awesome as ever though!

Have fun in the real world! (I hear it sucks)

[Rubidium]

So... this thread and the zbase repository are almost 3 months old. Where are we? Well, almost 98.5% of the "zoomable" sprites are drawn. These sprites are all sprites you can see at different zoom level, so everything except the unzoomable user interface sprites. If the user interface sprites are taken into account, then almost 92% is completed.

Lets hope Zephyris has the time to draw the remaining 1.5% of the zoomable sprites this weekend and then he managed to draw all zoomable sprites in merely three months whereas it took OpenGFX almost two years to get all (zoomable) sprites drawn.

I reckon Zephyris should model the statue after himself for this accomplishment!

[planetmaker]

I reckon Zephyris should model the statue after himself for this accomplishment!

Definitely. I'm very much impressed by what was achieved in this short time.

[Digitalfox]

You know what? I think that would be awesome and truly deserved

[Gremnon]

I've been playing with zBase instead lately, and though it looks a bit odd where 8bpp NewGRF graphics meet 32bpp zBase, it looks awesome. The titlescreen looks almost like a completely different game when you change from OpenGFX to zBase!

[Zephyris]

Technical question re: 32bpp and palette animation.

If I add some animated colours to the 8bpp mask sprites will they appear animated in game? What colour will they be?

I guess this is related to the company colour recolouring question, which has a bug report now http://bugs.openttd.org/task/5316.

[viator]

First my enthusiastic compliments to Zephiris Rubidium and all other team-members for the great (and so fast) development of zBase.
I am sure not to be the only one of all the lurkers on the openTTD site to enjoy this immensely! Every day at least I look for the latest push or nightly.

Having said that at last I may have a small contribution. I put it here since I cannot leave a message in the issue section of openttdcoop. It seems to be a small graphical error which I report because I cannot see (in the software) whether it has further implications for the graphical specs of your great work.

Circumstances : I vastly use the buying of land for future use. For instance to encapsule cities that tend to grow too big or to grow over the farms (nice trick?) or to block too annoying competitors (kind of cheating?).

Reported Issue : About the last four pushes of zBase the little flags appear at a different place (-2,-2) as pointed by the cursor, meaning always -2 squares horizontal and -2 squares vertical. As far as I can see it only happens with these flags and no other sprites.
But there may be more connected to it.

Possible Solutions : Non yet. I did try to use other graphics base sets (opengfx) but there seems to be no connection.

So I mention this to you because there may be an effect within your software graphics or elsewhere bugging you.

Hope it helps.

[Rubidium]

That seems to have been just a wrong offset of the sprite. Should be fixed in the next version.

[frosch]

Technical question re: 32bpp and palette animation.

If I add some animated colours to the 8bpp mask sprites will they appear animated in game? What colour will they be?

It will be animated with the colour from the mask and the brightness from the RGB part, just as for other mask colours.
However, "alpha" does not work for animated colours. They are always 100% opaque.

The same "alpha"-issue applies also on the reverse case. Drawing some half-transparent sprite over an animated colour makes it non-animated.

[viator]

You may want to add to your list for completion of Zbase:
1. The coverage area is highlighted, but in the same colour as the object (both white).
2. Rail construction : The cursor is blank/white meant to be like that or just missing the old cursor sprites?
3. Arm signals stick through bridges that cross over that section, handy yes, realistic no.
4. Tunnel entrance left upper side turns out to be transparent when train passes.
5. These do not really influence the gameplay but may be suitable for a personal choice option f.i. in Advanced Settings.

[Zephyris]

1. The coverage area is highlighted, but in the same colour as the object (both white).

This is an issue with the overbrightness of recolouring, see: http://bugs.openttd.org/task/5316
As there seems to be no interest in correcting this issue I may have to do a lot of rerendering and redesigning of mask sprites (the issue isn't just limited to these UI elements, but all bridge recolours, company colours, etc.).

2. Rail construction : The cursor is blank/white meant to be like that or just missing the old cursor sprites?

I am not sure what you mean, can post a screenshot?

3. Arm signals stick through bridges that cross over that section, handy yes, realistic no.

As above, I am not toally sure what you mean, screenshot?

4. Tunnel entrance left upper side turns out to be transparent when train passes.

Yeah, there are a lot of issues here. Tunnels are one of the first things I designed and they need a big overhaul.

5. These do not really influence the gameplay but may be suitable for a personal choice option f.i. in Advanced Settings.

What do you mean? That 32bpp graphics in general need an advanced settings option?

[viator]

2. Rail construction : The cursor is blank/white meant to be like that or just missing the old cursor sprites?

I am not sure what you mean, can post a screenshot?

The blank space next to the cursor appears and is connected with the choosing out of the rail-type box.
Normally this space shows an example of what you might put there if you push your left mouse button.
I cannot make a screenshot since I need the cursor to make a screenshot and then it is no longer connected to the box for choosing railtypes and the cursor is back to normal again.
Maybe you know of a alphanumeric way to make a screenshot (something like alt-Z or ctlr-S). Then I can make a screenshot for you.

3. Arm signals stick through bridges that cross over that section, handy yes, realistic no.

As above, I am not toally sure what you mean, screenshot?

Appendix Below : Zbase and Stations Transport, 12th Sep 2052.png

5. These do not really influence the gameplay but may be suitable for a personal choice option f.i. in Advanced Settings.

What do you mean? That 32bpp graphics in general need an advanced settings option?

No, I meant the smaller graphics things I mentioned above.
I thought that those alterings were your personal taste.
For instance I do not like the big GUI since it eats too much of my screen. So I wondered if I could put it back to the original size bij some knob somewhere.
Matter of taste, no criticism on your splendid work. Your trains, lorries , houses etc etc I wouldn't like to miss.

EDIT: some typing errors and more exact text about 'blank cursor'

[Kogut]

It is a known and rather unfixable bug, see my ticket - http://bugs.openttd.org/task/3251 (solution: "draw smaller signals")

[Zephyris]

Ok.

So I finally caved in and tried to get company colours to work with the current recolouring scheme.

1. To get the company colours to appear correctly very dark or light mask values can't be used. Ddark makes brown go orange and purple go pink. Light makes yellow go white and red go pink. I therefore chose the dark side of middle company colour; palette entry C9/201; rgb 28,68,140.

2. To stop overbrightening (saturating the brightest values) this means the max pixel value in recoloured parts of the rendered image has to be under 117 (Because of the formula max(r, g, b)*paletteValue/64). This is what that render looks like:

256_0001.png (8.15 KiB) Viewed 3438 times

Yes, it really has to be that dark.

3. Testing the recolouring using the normal blue company colour. Recolouring works; the sprite is the correct colour and the correct brightness

It looks crap though. The CC mask can't be anti-aliased but the 32bpp sprite is anti-aliased (and always should be, otherwise what's the point in having the extra colour depth?). This means the CC mask and the rendered CC regions will never perfectly align. You therefore have a choice; either the mask should overshoot the edges of the CC region. This gives you bright borders to the CC.

Overshoot.png (7.32 KiB) Viewed 3438 times

Or you can undershoot the edges of the CC region. This gives you dark borders to the CC. This is marginally better than the bright borders.

Undershoot.png (8.18 KiB) Viewed 3438 times

In both cases it looks crap; your eyes are very sensitive to different brightnesses and the borders stand out like a sore thumb. It is particularly bad for the small sprites. The ONLY ways to solve this is to alter the recolouring algorithm to make sure that the 32bpp graphics are of a similar brightness before and after company colour recolouring. One easy way to do this is still altering the divisor to 128.

So thats the rant over, now the begging.

Please, please, please change this in trunk. It's probably the smallest commit needed ever; literally all that is needed is changing "64" to "128". That is a diff size of 3 bytes. It will make all recolouring; the tile selectors, the bridges, the town buildings, the company colours, look much better.

[peter1138]

Have you got an example of where the recolouring with /64 looks bad compared to /128? Changing this value has no affect on the recoloured/non-recoloured "join".

[Zephyris]

Changing this value has no affect on the recoloured/non-recoloured "join".

I can give you some examples tomorrow, they are stuck on a different computer at the moment...

Imagine these as the two possibilities for input:

recol_sources.png (1.23 KiB) Viewed 3375 times

Then recolour the left with a /64 and the right with a /128

recol_done.png (1.14 KiB) Viewed 3375 times

Because the /128 recolouring better preserves the brightness of the recoloured region the anti-aliasing works better on the recoloured image. The point is that your eye is very sensitive to fine detail in brightness, but not to differences in colour. Therefore anti-aliasing to dark blue gives a harsher artefact when neighbouring the company colour than the anti-aliasing to a mid blue. This is precisely the effect that jpg compression takes advantage of to achieve such impressive compression.

The advantages are preserved no matter how bright the neighbouring colour to the company colour is. This is the same demo but with the recoloured company colour neighbouring black, mid grey or white. Again the /64 is on the left and the /128 is on the right.

recol_source2.png (2.63 KiB) Viewed 3375 times

I have demo'd these with a 'conservative' mask boundary (i.e. giving a dark boundary artefact). Going the other way with a 'liberal' mask boundary (i.e. giving a bright boundary artefact) the problems are even more obvious with the /64.

[Yexo]

You have me convinced, but since I've never touched that part of the code I'll leave it to petern or michi_cc to decide.

[planetmaker]

That looks convincing enough to me as well to warrant a change of specs.