32bit Graphics Extra Zoom Patch

[Ben_Robbins_]

...reminds me of this stunning mock-up, from some time ago.

[GeekToo]

So here it is: a new revision of the patch

What's improved
-------------------
-automatic resize of z0 sprites to more zoomed out levels, so you don't have to pngcodec every zoom level, and 32bpp sprites are also shown in zoomed out levels.
-city names etc are now shown correctly in more zoomed out levels
-vehicles are shown correctly on more zoomed out levels on the right and bottom parts of the screen ( this wasn't on the bug list, 'cause you guys did not find it, but I knew it was there. Try to run a bus line, zoom out from the normal level, and scroll the screen so the bus is in the right half of the screen, and you'll know what I mean.
-I implemented the improved algorithm for company colours ( it does have some nasty side-effects, like drawing all 8 bpp recoloured sprites in a funny colour, but they need to be replaced anyway )


Still not right:
============
-plane shadows
-company colours only work for a limited number of colours, I do have ideas how to solve this, but I wanted to give you the chance to play with the blending already. So the hue of the recoloured sprites is not correct, but some colour variations are already possible. I'm still working on this, so this certainly isn't the last revision of the patch.

How to apply company colour
===========================
Create an 8bpp indexed colour mask file: nnnn_zxm.png nnnn=sprite number, x=zoomlevel. No need to pngcodec it.
Draw pixels in the colour index range 196-203 where the CC must be applied.
Put the mask file in the same directory as the sprite to replace( like bin/data/sprites/trg1r)
I've added some example files of my foster bus(one view only) to show the mechanism. The masking of it is still sloppy, because I just made a quick mask to try the code.

As usual, any comment is welcome.

PS: in contrast to what I said before, don't grayscale the sprite on the places where CC must be applied, I use the colour information to determine the saturation level. ( Sorry for the artists that already did that, that's the risk of jumping on a running train, or ongoing development)

[DeletedUser5]

Well, good CC is implemented. I don't like that sprites are resized also to z1 and z2. I'd like to see that sprites are resized only to z3 and above. Not to z1 and z2.

[Wacki]

Windows binary, please.

[Ben_Robbins_]

Great work as per usual. I think having sprites resize to z1 and z2 if there is no available sprite is great, since otherwise we may just be making sprites ourselves which are just resized in the same way as done in game, which seems a waste of time, and size of the graphics .tars.

[DeletedUser5]

But for example your roads don't compare fine with grass. That's why I don't like it. Maybe something like patch option would be possible.

[Ben_Robbins_]

For examples, like the road or grass, then I intend to make different zoom level sprites. Because details need to be emphasised in the lower zooms. i.e. the road markings, or the contrast in greens. It's not going to stop people from adding sprites for z1 and z2, but if they are unavailable it will resize. (assuming I have understood it correctly)

[Nickman]

I have made new windows binaries .
Looking good!

I did find some resizing issues on the max zoomed out level. My road depot became bigger instead of smaller .

----------

EDIT:
It seems I had uploaded the diff file .
Now the correct rar is attached .

[MvGulik]

Hi

Great patch.
Love the additional zoom levels.
New transparency look great to.

Something that could be considered a personal preference. (for fine tuning later)
The income/cost message scroll-up speed in maximum (z0) zoom level seems a little to high for comfortably reading.

M.v.Gulik.

[bazil14]

I have made new windows binaries .
Looking good!

I did find some resizing issues on the max zoomed out level. My road depot became bigger instead of smaller .

----------

EDIT:
It seems I had uploaded the diff file .
Now the correct rar is attached .

ive used ur rar fie but weirdly it looks like it is the same version as the fisrt binery you made eg sprites arnt being rezised in z2 level, Wrond diff patched? or is it ment to be like that

[Nickman]

ive used ur rar fie but weirdly it looks like it is the same version as the fisrt binery you made eg sprites arnt being rezised in z2 level, Wrond diff patched? or is it ment to be like that

Hmm, I'll take a look at it... Let me get back at you

------

I just tried it out and it seems to be working just fine over here... The date stamp of the .exe file is also the current day so... :s
could someone else confirm if this is the correct version or not? If not I will re compile and republish .

[GeekToo]

For examples, like the road or grass, then I intend to make different zoom level sprites. Because details need to be emphasised in the lower zooms. i.e. the road markings, or the contrast in greens. It's not going to stop people from adding sprites for z1 and z2, but if they are unavailable it will resize. (assuming I have understood it correctly)

Completely right.

If graphics don't match nice, that must be solved in the graphics.

A little more explanation: the patch now resizes 32bpp also to the more zoomed out levels, previously it only rescaled 8bpp sprites.
This does mean: for all viewport sprites, provide a z0 sprite, and the game will take care of resizing to more zoomed out levels. Only when you want more detail in the z1, z2 etc you need to provide these too. For GUI sprites, in general, provide a z2, ( or z0, or z1 which will then be resized), because GUI sprites don't get zoomed.

The way that sprites are searched: try the current zoom level, if no sprite is present, try the next more zoomed in level and resize that etc.
If no more zoomed in level is found, it falls back to searching 8bpp and resized that. For 32bpp sprites it never resizes a sprite to a more zoomed in level, because that's always ugly. It only does it with 8bpp sprites, so you can at least see what is supposed to be shown on a tile, else it would be black. When all 32bpp sprites are present, rescaling to double size will never be needed.

I did find some resizing issues on the max zoomed out level. My road depot became bigger instead of smaller

Can you provide a sprite for this? For vehicles and landscape sprites I did not see this issue

Something that could be considered a personal preference. (for fine tuning later)
The income/cost message scroll-up speed in maximum (z0) zoom level seems a little to high for comfortably reading.

I'll add it to to todo list

I just tried it out and it seems to be working just fine over here... The date stamp of the .exe file is also the current day so... :s
could someone else confirm if this is the correct version or not? If not I will re compile and republish

I did not check yet, as I'm on Linux now, and would need to reboot, but you can check it easy: if 32bpp sprites get resized to the z3 level
that is one level more zoomed out than the default level, it's ok.
Another check: Put the example png's I posted above, in the data/sprites/trg1r directory ( they're coded ), and look at the company colours on the bus. If it shows a flat colour, it's the old patch, if the lighting is ok, it's the new one.

[Nickman]

Wehn I zoom out to the max level there are things that don't get scaled:
- Roed depot
- some trees?
- The sign posts

The roads seem to scale perfectly, but it's the 8bpp graphics that I mentioned that don't scale, they keep there original size I think. It does give a cartoonisch view of the map .

If you want to I'll grab a screenshot?

[bazil14]

@Nickman

hey, just so you know what is happening on my version i have attached this screenshot

dunno if it still does this on the patch geektoo realised but it does on your windows version (probely not your fault)
also it happens with rails too

It probely isnt your fault and maybe its my pc messing up (but it is pretty new)

-Bazil14

[GeekToo]

I saw this once on the windows version, and tried to reproduce it, but couldn't yet.
Try the following: rename all tars in the data dir to .tr
rename the sprites directory to spritesbak
remove all newgrf in the newgrf setting window or cfg file.

start ottd again ( as always with the 32bpp-optimized blitter )
It should display correct.
Now add one tar and restart ottd etc.

when all tars are added again, rename the spritesbak dir to sprites again.

Maybe that gives an indication when the problem occurs.

@Nickman, I saw the problem with the depots etc, that clearly must be added to the buglist. Thanks for finding it.

[DeletedUser5]

So ok. Actually I like resizing. But in old revisions it worked better. Roads don't look for me that good for example. Or rails too. Resizing with gimp makes it better.

[Ben_Robbins_]

Could you post some examples for comparison?

bazil14/geektoo: I'm using the windows version and haven't had this issue.

[DeletedUser5]

See screenshots. For example offset generated are worse. Test it by yourself.

[bazil14]

found the culprits the "temperate set without grass" and "temperate+roads" were messing it up with out those tars it worked perfectly. obvisily your sizing system doesnt like multiple tars with the same sprites in them:P

also a bug for you,

. 8bpp industrys and 8bpp construion stages dont get resized when you zoom out
also you might want to get the game to aa the 32bpp strites when they are resized from z0 zoom into z1 zoom and z2 zoom
.also with the 32bpp bus the game crashes if your zoomed in and you have one (only if you have the mask you made
-Bazil14

[GeekToo]

found the culprits the "temperate set without grass" and "temperate+roads" were messing it up with out those tars it worked perfectly. obvisily your sizing system doesnt like multiple tars with the same sprites in them:P

. 8bpp industrys and 8bpp construion stages dont get resized when you zoom out
also you might want to get the game to aa the 32bpp strites when they are resized from z0 zoom into z1 zoom and z2 zoom

-Bazil14

Thanks for the research, I guess the second issue is the same as with depots that Nickman reported.
Doing some antialiasing when zooming out is one of the things on my personal to do list, although the current algorithm is already better than the one in trunk.

Soeb, the zooming out can not be worse than in previous revision, because that revision did not zoom out 32 bpp. But things can always be improved