32bit Graphics Extra Zoom Patch

[Nickman]

Here are the Win32 binaries .
Have fun with them.

[Bilbo]

---- NEW POST ---
So I decided to make a list of graphics posted in this theard.
First page
grass.tar [1.37 MB] - Graphics by Ben_Robbins_, coded by GeekToo. - witout grid lines
selectors_z0.tar [120 KB] - Graphics by Ben_Robbins_, coded by Soeb.
3trees_z0.tar [810 KB] - Graphics by Ben_Robbins_, coded by Soeb.

...

Umm ... the link for selectors_z0.tar and 3trees_z0.tar in your post is the same, so one of the links should be corrected :)

[Dragonling]

Here are the Win32 binaries .
Have fun with them.

No fun but a crash.
Every time I try to zoom-in I get an "out of sprite memory" and an "Assertion failed!" in File "C:/BuildOTTD/msys/home/ottdsrc/trunk/src/openttd.cpp" in "Line: 108"

I used no additional GRFs and only "grass.tar" and blitter=32bpp-optimized.

[Nickman]

Read the first post

modify openttd.cfg:
-set sprite_cache_size to at least 32, preferably 48 to prevent out of sprite memory errors

It's in "my document/OpenTTD" or something like that if you can't find it in the directory of OTTD
I had the same problem

[DeletedUser5]

Umm ... the link for selectors_z0.tar and 3trees_z0.tar in your post is the same, so one of the links should be corrected

Thanks for note. It's fixed now.

[Wacki]

Read the first post

modify openttd.cfg:
-set sprite_cache_size to at least 32, preferably 48 to prevent out of sprite memory errors

It's in "my document/OpenTTD" or something like that if you can't find it in the directory of OTTD
I had the same problem

I must set: set sprite_cache_size to 64

[bazil14]

Here are the Win32 binaries .
Have fun with them.

thank you so much, works well, p.s. complimants to the original patch maker

[petosko]

hi...there is not sound when you build a train track in superzoom... i want only say this and sorry for bad english, maybe you can understand

[GeekToo]

Thanks a lot Nickman, for posting the windows binaries, they seem to be popular, and it did save me some time.

Everybody else, thanks for the useful input. I updated the first post according to your comments.

Some things I would like to know:
- what items on the bug list or todo list need to be worked on first ? I want to create some kind of priority list, so I can spend my time optimal. I do have an idea about this myself, but it's better to listen to the community on this, as I'm not really objective
- how do you like the new transparency? Should it stay this way, should I remove it completely, or should it be a greyscale or whatever ideas you come up with

[Roujin]

I'd probably follow something like this order..

- bugs that obstruct gameplay
- technical improvements (optimisation etc.)
- minor bugs (graphical only)

[DeletedUser5]

- what items on the bug list or todo list need to be worked on first ? I want to create some kind of priority list, so I can spend my time optimal. I do have an idea about this myself, but it's better to listen to the community on this, as I'm not really objective
- how do you like the new transparency? Should it stay this way, should I remove it completely, or should it be a greyscale or whatever ideas you come up with

I'll say implement other blitters.
I like the transparency a lot. It should stay in my opinion.

[Wacki]

I would like to have your new idea with company colour!

[DeletedUser5]

I've noticed another thing. When you'll code a new graphics a plane for example, it will look like every frame that was showed once is still showed. And when you'll make a plane and when it flies shadow don't look good.

@EDIT: First bug disappears when you'll code z1 and z2.

[GeekToo]

I've noticed another thing. When you'll code a new graphics a plane for example, it will look like every frame that was showed once is still showed.
@EDIT: First bug disappears when you'll code z1 and z2.

Can you explain this a little further? Like in what zoom, and with which sprite. I tried but can not reproduce this.

And when you'll make a plane and when it flies shadow don't look good.

I did notice this already. The openttd trunk code does not use 'real' transparency, but did only darken the colors of the background a bit, without drawing the foreground sprite. The shadows of the planes were (ab)using this effect for creating shadow effect.
Now in 32bpp the transparency is real transparency, and this becomes visible. This can be solved by distinguishing between transparency, and darkening, and draw the sprites in one of these modes. But you're right, this needs some attention.

[DeletedUser5]

Can you explain this a little further? Like in what zoom, and with which sprite. I tried but can not reproduce this.

z0
Only noticed with planes. Take one planes from Air Vehicles (New Graphics) for example. Actually I know it happens wit all sprites for Sampson U52, because I didn't tested it on other planes. I wanted to write vehicles, but I've wrote new graphics. As I said it looks like every one frame is leaved. You need to move screen, or selector, and it disappears. But when you'll add z1 and z2 problem doesn't exist.

[GeekToo]

Thanks Soeb, I will try this soon.

A little update: I have been working on the patch and fixed the following:
-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 white text in purple, because the text sprite are originally drawn in that colour, I will find a way to get around that)

So that are some things that were on your wish list, except for implementing the other blitters, because I want to wait with that until the optimized blitter has proved itself.

About the company colours: the current trunk implementation only allows 8 colours for a sprite to be drawn in CC, which looks ugly next to 32bpp colours. I implemented an algorithm where the vehicle sprite defines a greyscale, that is multiplied with the company colour, which makes at least 256 colours possible, and even more when small colour variations are applied in the sprite. That's already a big improvement. But I would like to have some feedback on the following(I also mentioned this already in another topic) :

What should be the exact algorithm for blending: if I do a multiply, the sprites tend to get darker. When I do a blend, the contrast of the material reduces.
A little explanation: a multiply does multiply the rgb values of the sprites with the rgb values of the mask. So when a white sprite is multiplied with a pure red mask, the resulting colour is pure red. But when a red value of 128 ( of 256 ) is multiplied with itself, the resulting colour is 64, so much darker.
When a do a blend, which avarages the color values of the mask and sprite, with for instance 50% alpha, a pure red value of the mask which is blended with a white sprite value becomes light red: the green and blue values are at 50%

You can try this in Photoshop or Gimp by using different blend modes, like multiply, screen, lighten etc.
When the right method has been determined, I'll post an update of the patch.

[Zephyris]

Surely it would be easiest to convert the greyscale company colour image to HSL colour space, increase the saturation, then pick the hue, before converting back to RGB. I don't know if this has a GIMP layer blending equivalent, but it would be the most accurate (and quite a simple way) of doing it.

*edit* I have no programing ability, but guess the following may be useful:
http://www.easyrgb.com/math.php?MATH=M18#text18
http://www.easyrgb.com/math.php?MATH=M19#text19

[Nickman]

Surely it would be easiest to convert the greyscale company colour image to HSL colour space, increase the saturation, then pick the hue, before converting back to RGB. I don't know if this has a GIMP layer blending equivalent, but it would be the most accurate (and quite a simple way) of doing it.

*edit* I have no programing ability, but guess the following may be useful:
http://www.easyrgb.com/math.php?MATH=M18#text18
http://www.easyrgb.com/math.php?MATH=M19#text19

I used the exact same site for those algorithms about two years back .
To make a colour get brighter in a 3D engine (pertty basic) we had to do when it approches the light source, worked pretty nice .

Don't really know for shure wich blending option would be the best thouh...

[DeletedUser5]

So OK. You've did a little update. But there isn't any new diff.

tested on Gentoo Linux and Windows XP pro, and probably by some other windows variants too by the alfa testers.

I tested it on Ubuntu Linux. So not only Gentoo Linux

[GeekToo]

@ Zephyris: thanks for the links, I did not know the site, some interesting stuff there.
Up til now I tried a blend with 50% ( which makes the hue incorrect ), and a multiply ( which makes the darker colours too dark ). Next try will be to use the hue of the colour mask, and the lightness of the greyscale (as far as possible).

@Soeb, a new update will be available when I sorted out the blend algorithm, which still will take a little time. The blend I use now makes all white text purple/pink, so I did not post it. I don't want to be responsible for damaging your eyes. But I expect it won't take weeks, before it's done.