32bit Graphics Extra Zoom Patch

Discuss, get help with, or post new graphics for TTDPatch and OpenTTD, using the NewGRF system, here. Graphics for plain TTD also acceptable here.

Moderator: Graphics Moderators

Flamefire
Engineer
Engineer
Posts: 19
Joined: 07 Aug 2010 15:03

Re: [32bpp] Extra zoom levels, experimental new CC algorithm

Post by Flamefire »

I'm currently trying to get 32bpp extra zoom to work with latest trunk.
I managed to work in all changes by manually copying and changing the code, where there were conflicts (there are many...)
Now it is running. But there is one last thing. I'm sure i just forgot something or did something wrong. But I dont know where to look further.

The Problem is, that on some occasions the screen is drawing in the screen (screenshots)
Unbenannt, 11. Jan 1970.png
Single
(211.75 KiB) Downloaded 2 times
I noticed, that the position of thes screens-in-screen are affected by other windows.
E.g. the single one disappears as the screenshot saved window appeared and reapeared after it was closed
The multiple ones are a bit away from the open window and stay in the same distance.
Unbenannt, 6. Feb 1970.png
More
(641.99 KiB) Downloaded 2 times
Does anyone know what causes this?

I attached the diff-file. You can easily apply it to latest trunk and compile without changes.
Attachments
myPatch.patch
Diff fixed
(76.23 KiB) Downloaded 138 times
Last edited by Flamefire on 10 Aug 2010 19:48, edited 1 time in total.
User avatar
GeekToo
Tycoon
Tycoon
Posts: 961
Joined: 03 Jun 2007 22:22

Re: [32bpp] Extra zoom levels, experimental new CC algorithm

Post by GeekToo »

without having applied the patch, but by checking the diff, I am very suspicous of this statement in line 2230 of the patch:

Code: Select all

+	if (false && ScaleByZoom(bottom - top, vp->zoom) * ScaleByZoom(right - left, vp->zoom) > 180000) {
I dont think the false statement is correct
Flamefire
Engineer
Engineer
Posts: 19
Joined: 07 Aug 2010 15:03

Re: [32bpp] Extra zoom levels, experimental new CC algorithm

Post by Flamefire »

sry. this was because i tried to check that ;-)
but it doesnt affect that bug

I fixed it in the diff above
Flamefire
Engineer
Engineer
Posts: 19
Joined: 07 Aug 2010 15:03

Re: [32bpp] Extra zoom levels, experimental new CC algorithm

Post by Flamefire »

I got it to work. not fully sure, what caused it. I did it the other way round. Applying the 32bpp patch, then updating to latest trunk resolving some conflicts.
After a few other fixes (double includes, style mistakes) i made a new diff out of it.
Maybe it can be included to the other ones, in case someone else wants it? Maybe the coders can use it to continue with a more recent version.
I attach the diff and Win 32/64 Bit executables compiled from it.
Dont forget to set the 32bpp blitter in the config file or it will crash (this should be fixed without forcing the blitter. I removed that forcing)
Also set the cache size to 64 in config (default is 64 but if it is set to something else it may get overwritten)

Have fun!

Edit: Because new language files are needed I attached the whole game with current language files.
Attachments
32bpp for 20445.patch
(78.87 KiB) Downloaded 253 times
openttd32.rar
Win 32 Bit game
(3.31 MiB) Downloaded 271 times
openttd64.rar
Win 64 Bit game
(3.76 MiB) Downloaded 213 times
Flamefire
Engineer
Engineer
Posts: 19
Joined: 07 Aug 2010 15:03

Re: [32bpp] Extra zoom levels, experimental new CC algorithm

Post by Flamefire »

hm...I cant attach more than 3 files...
So a new post:

I found that blending causes Problems. E.g. the text in the settings window is almost unreadable. Other textes are bad too
And positioning stations with effectarea shown is impossible because the highlighters are just white. I got the same problems with the 32bpp on the "old" revision. So it isnt me...

I'll fix it if i can

Edit: Status: Fixed
Games attached.

@Devs: I introduced a new Blitter-Mode: BM_COLOUR_REMAP_BLEND
per Default evrything uses the old mode (but with alpha channel), but if there is actually recouloring, then blending is used. works well.

@Lord Aro: Well...I'd need some help if I want to get further. I dont understand important parts of the sprite handling and representation. Maybe there is someone who can help me along

EDIT2: I made a new Patch: I wanted to have fading fields, because i think it looks bad, if they just change in one step. Now the Blitter is able to have full alpha transparent drawing. I made some new Palette constants to have it from 0%-100% transparency.
This works now.
The attached game contains 32 and 64Bit binaries. The Patch (again from trunk) is also attached.

Evrything from me can be found in this new thread: http://www.tt-forums.net/viewtopic.php?f=36&t=49661
Attachments
32bpp for 20445 fix 1.patch
(79.91 KiB) Downloaded 161 times
32bpp for 20445 with field fade.patch
(86.7 KiB) Downloaded 162 times
Last edited by Flamefire on 12 Aug 2010 17:20, edited 3 times in total.
User avatar
Lord Aro
Tycoon
Tycoon
Posts: 2369
Joined: 25 Jun 2009 16:42
Location: Location, Location
Contact:

Re: [32bpp] Extra zoom levels, experimental new CC algorithm

Post by Lord Aro »

If you have actually fixed problems, and not introduced new ones, well done! They have been problems for a long time.
For your next trick, you can sort out all the CC problems :lol:
AroAI - A really feeble attempt at an AI

It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. --Edsger Dijkstra
User avatar
GeekToo
Tycoon
Tycoon
Posts: 961
Joined: 03 Jun 2007 22:22

Re: [32bpp] Extra zoom levels, experimental new CC algorithm

Post by GeekToo »

Flamefire wrote: I found that blending causes Problems. E.g. the text in the settings window is almost unreadable. Other textes are bad too
...
I introduced a new Blitter-Mode: BM_COLOUR_REMAP_BLEND
per Default evrything uses the old mode (but with alpha channel), but if there is actually recouloring, then blending is used. works well.
Hi Flamefire,
Very nice someone else is active in coding for 32bpp graphics.

The problem with the text was introduced with one of the merges with trunk. Your solution for that does work, but is a bit overcomplicated: the extra zoom patch already contains a non-blending recolour, it is called OPAQUE, so there is no need to add yet another mode, which does the same.
Flamefire wrote: And positioning stations with effectarea shown is impossible because the highlighters are just white. I got the same problems with the 32bpp on the "old" revision. So it isnt me...
This is a different problem, that is caused by the fact that the blend is done based on hue, but the selectors are white or grey tones, so no hue, and thus no recoloration.
I see three possible solutions:
-change the graphics, so they contain a hue (ie not a white or grey tone)
-your solution, which works, but disadvantage is that the sprites will be drawn with limited colours, effectively reducing it to 8bpp drawn in 32bpp.
-use a new blending mode that does a colorisation blend: white of the base sprite and a blue mask will result in blue. That mode cannot be used for normal CC recoloring, because then white highlights would also be colored, which is ugly, but for selectors it is ok, I guess

For now, I'll use your solution, because it is better than having nothing, but when people start complaining about ugly looking selectors, we will have to go for solution 3.
http://dev.openttdcoop.org/projects/32b ... repository

Beside that, I like you idea of the blending fields. I will not copy it yet, because it is not completely matured, and I dont know the performance effects without profiling, and it cannot be switched off yet. Nontheless, the idea is very nice, keep going!
Flamefire
Engineer
Engineer
Posts: 19
Joined: 07 Aug 2010 15:03

Re: [32bpp] Extra zoom levels, experimental new CC algorithm

Post by Flamefire »

nice to read an official developer ;-)
and also nice that you like my idea.

Hm, where was that introduced? There had to be a check for the recouloring like in the new patch or evrything else set to use OPAQUE
EDIT: Here you missed something: you should have changed the text drawing methods to use opaque. just do a search in gfx.cpp for the remap mode. Look at my topic (link above) there I provide newer patches against latest trunks

Can you explain the blend mode used in simple words? A very simple method would be to replace all non transparent pixels in the mask with the new color. But that would be to easy ;-)
So how are the masks done, stored and handled?

1) I would avoid changing the graphics. The best on 32bpp EZ is that it is compatible to old stuff.
2) Why are the colors limited? There are sprites with 32bpp (RGB+A each 1 Byte) and they are drawn to screen with that 4 Bytes.
3) For this i have to know how recouloring really works. If you have this: The sprite, a sprite mask, and a color mask and it works like this:
Make light fall through the color mask so we can have different colors. Than this colored light goes through the sprite mask, that can contain holes (transparent areas) where light goes through, solid parts (black?) where light cant pass and something between, where it is just weakened. After this the so calculated light falls at the sprite. So fully transparent masked parts are fully drawn in the new color, black masked parts stay and the parts between are faded.
With this the mask can contain black parts, where the white highlights should stay.

Do you have ICQ? So we can talk better about that without spamming the whole forum ;-)
User avatar
GeekToo
Tycoon
Tycoon
Posts: 961
Joined: 03 Jun 2007 22:22

Re: [32bpp] Extra zoom levels, experimental new CC algorithm

Post by GeekToo »

Flamefire wrote:nice to read an official developer ;-)
I'm not an official dev, I'm 'just' the author of the extra zoom level patch
Flamefire wrote: Hm, where was that introduced? There had to be a check for the recouloring like in the new patch or evrything else set to use OPAQUE
EDIT: Here you missed something: you should have changed the text drawing methods to use opaque. just do a search in gfx.cpp for the remap mode. Look at my topic (link above) there I provide newer patches against latest trunks
The text drawing in opaque was introduced in revision 4 or 5 of the patch, a couple of years ago.
http://dev.openttdcoop.org/projects/32b ... es/ez.diff

The only recent revision where it was incorrect, because of merge failure was revision 45, I repaired it again in rev 46 and 47 (which also updates to recent trunk). Check line 937 of revision 47.
Flamefire wrote: Can you explain the blend mode used in simple words? A very simple method would be to replace all non transparent pixels in the mask with the new color. But that would be to easy ;-)
So how are the masks done, stored and handled?
Both trunk and the ez-patch use the same file formats: a full 32bpp source sprite, and an 8bpp mask file.
The mask file determines where recoloration needs to be applied: if there is a pixel on a position in the mask file, recolour will be applied to the corresponding pixel of the source sprite. The value of the pixel in the 8bpp mask file is an index in the ottd-palette, that indicates with which color recolour must be applied.

The main difference in blending between trunk and ez is in how the recolour of those pixels is done:
-trunk completely replaces the 32bpp sprite pixels with the 8bpp mask colour (recalculated to 32bits, but still only 256 colours are possible). For company colours it's even worse: there are only 8 shades of every CC available in the palette, so for every cc the colour space is only 3 bits! Like you said, that is too simple, and imho it just looks ugly, completely destroying any gradients in hue, saturation or brightness, that is why I changed it in EZ:
-In EZ the calculation is done different (I assume you know some basic colour theory);
Say we have a 32bpp source sprite pixel with HSL (hue, saturation, lightness) values of Ho,So,Lo and a mask pixel of Hm,Sm,Lm, then the blended pixel will have Hm,So,Lo. Because So and Lo come from the 32bpp sprite, saturation and lightness gradients are stll possible, only the hue is limited, which is not a big problem for recognizable company colours.
Example: if we have a full blue original pixel rgb =0,0,ff, and the mask colour is red ff, 0, 0 the result would be ff,0,0. If the original were 0,0,80, the result would be 80,0,0 where trunk would give ff,0,0. So this method gives a lot more room for saturation and lighness variation (mind that graytones cannot be recolored, they dont have a hue).
Flamefire wrote: 1) I would avoid changing the graphics. The best on 32bpp EZ is that it is compatible to old stuff.
Agreed completely
Flamefire wrote: 2) Why are the colors limited? There are sprites with 32bpp (RGB+A each 1 Byte) and they are drawn to screen with that 4 Bytes.
The sprites are 32bpp, but get replaced with the mask colours, which are, as explained above, only 8bpp
Flamefire wrote: 3) For this i have to know how recouloring really works. If you have this: The sprite, a sprite mask, and a color mask and it works like this:
Make light fall through the color mask so we can have different colors. Than this colored light goes through the sprite mask, that can contain holes (transparent areas) where light goes through, solid parts (black?) where light cant pass and something between, where it is just weakened. After this the so calculated light falls at the sprite. So fully transparent masked parts are fully drawn in the new color, black masked parts stay and the parts between are faded.
With this the mask can contain black parts, where the white highlights should stay.
Your theory is correct, but would break compatibility with trunk for the mask files, which I want to avoid.
A new blending algorithm, like an averaging blend or whatever could be limited to patch code, while keeping compatibility with trunk files.
Flamefire wrote: Do you have ICQ? So we can talk better about that without spamming the whole forum ;-)
Well, the discussion is relevant for the patch this thread is about, and may also provide some info for others, so I don't mind to have the discussion here in the open.
Jupix
Chief Executive
Chief Executive
Posts: 683
Joined: 19 Feb 2005 09:08
Location: Finland
Contact:

Re: [32bpp] Extra zoom levels, experimental new CC algorithm

Post by Jupix »

GeekToo wrote:
Flamefire wrote: Do you have ICQ? So we can talk better about that without spamming the whole forum ;-)
Well, the discussion is relevant for the patch this thread is about, and may also provide some info for others, so I don't mind to have the discussion here in the open.
Indeed, your posts are mighty insightful so please feel free to converse here, for everyone elses benefit.
#################
Flamefire
Engineer
Engineer
Posts: 19
Joined: 07 Aug 2010 15:03

Re: [32bpp] Extra zoom levels, experimental new CC algorithm

Post by Flamefire »

ok.
so i think the palette non sprites are the masks.
but there are some other masks for each sprite (with "m" at the end of the filename)
what do they mean?

I'd also need something to extract the png files (sprites and masks) from the grfs (OpenGFX) to take a look at them. But I didnt found anything that works.

Last but not least: The coord calculation in 32bpp patch is made on a different place than in trunk. This was the greatest difference while merging. (evrything else was in 1 file, but that was spread around evrything)
What exactly was changed and why?

And a request: Maybe we can improove it in a way, that it gets (at least partially) included in trunk. There are so much differences that dont need to exist. So that the only differences are really the full zoom. or whatever the trunk devs dont want to have or what isnt stable yet (e.g. the CC)


I played a bit around with colors. Well... I dont see any solution.
One the one hand, we want to keep the white highlights and just change the color (hue), on the other hand, we want the white sprites to be also affected.
So the solution with the opaque is really the end of the line.
Why change anything beyond? CC is done nicely with changing hue and other sprite colors are just translated. Well ok, they use 8bpp, but why do we need to use 32bpp if we want to draw a full blue selector, or a green text?
User avatar
GeekToo
Tycoon
Tycoon
Posts: 961
Joined: 03 Jun 2007 22:22

Re: [32bpp] Extra zoom levels, experimental new CC algorithm

Post by GeekToo »

Flamefire wrote: so i think the palette non sprites are the masks.
but there are some other masks for each sprite (with "m" at the end of the filename)
what do they mean?
The palette non sprites are the colortables: sequences of max 256 colours, defining the palette to work with. Let's call them color[0]...color[255]. Which colortable to use is defined by the pal parameter of the blitter.

The mask files are the ones with the "m" at the end. Every pixel consists of a byte, that is an index in the colortable if it is not transparent. So if a pixel in the mask files has value 53, color[53] in the colortable will be used to recolour the source sprite (see LookupColourInPalette)
Flamefire wrote: I'd also need something to extract the png files (sprites and masks) from the grfs (OpenGFX) to take a look at them. But I didnt found anything that works.
I always use grfcodec for that, there is a link to it on this page:
http://wiki.openttd.org/How_to_Create_3 ... Extra_Zoom
Flamefire
Engineer
Engineer
Posts: 19
Joined: 07 Aug 2010 15:03

Re: [32bpp] Extra zoom levels, experimental new CC algorithm

Post by Flamefire »

I checked the performance of my fading field patch and also applied an option to deactivate it. (deactivated by default)
Patch can be found on my thread.

But: on zoomed in stages the performance is quite good. But on max outzoom or 1 below it lags and eats cpu as hell...
of course it has to draw the tiles twice and calculate alpha values, but that worse?

On further research I found that oTTD uses GDI under Windows. GDI is know as quite slow. Also the blitter blits pixels on cpu.
I wondered why it doesnt use SDL by default (which is known under at least Win and Linux) and make use of the hardware acceleration (e.g. use surfaces for the sprites and let the graphics card blit it)
By now the SDL video driver class does not use the opportunities SDL provides.

Ok to be honest, this wont solve all problems, but e.g. Alpha blending would be quite easy and fast.
Maybe the CC and other recoulorings will be a problem, but maybe it can be used there, where it is not needed.
But since some work has to be done also on loading sprites, it has to be done in trunk. Otherwhise there will be 2 versions of oTTD that are too different.
User avatar
GeekToo
Tycoon
Tycoon
Posts: 961
Joined: 03 Jun 2007 22:22

Re: [32bpp] Extra zoom levels, experimental new CC algorithm

Post by GeekToo »

Binaries for several architectures, created on the openttd compile farm!

With the kind help of the openttdcoop guys (esp. Ammler and Planetmaker), and of Rubidium (one of the OpenTTD devs), we now have the possibility to create binaries for several architectures (linux and windows), compiled on the openttd compile farm.

I think that is an important step forward!

Maybe I will elaborate on the technical details later, but the first run was done last night. There may still be some child diseases, but I've tested the Windows 32bit version and that seems to be OK.

Now you can pickup your binaries here:
http://bundles.openttdcoop.org/32bpp-ez/LATEST/

Issues can be reported in this thread or on:
http://dev.openttdcoop.org/projects/32bpp-ez-patches
Jupix
Chief Executive
Chief Executive
Posts: 683
Joined: 19 Feb 2005 09:08
Location: Finland
Contact:

Re: [32bpp] Extra zoom levels, experimental new CC algorithm

Post by Jupix »

Fantastic! Congrats, and thanks to the guys for helping make it happen.
#################
maquinista
Tycoon
Tycoon
Posts: 1828
Joined: 10 Jul 2006 00:43
Location: Spain

Re: [32bpp] Extra zoom levels, experimental new CC algorithm

Post by maquinista »

Maybe this could fix the saturation in areas with low saturation:


I have seen this code that calculates saturation of CC color:

Code: Select all

+ /* Saturation cc */
+ float saturation;
+ if (max_colour == min_colour) {
+ saturation = 0;
+ } else if (lightness_colour <= 0.5) {
+ saturation = (max_colour / 255.0 - min_colour / 255.0) / (2.0 * lightness_colour);
+ } else {
+ saturation = (max_colour / 255.0 - min_colour / 255.0) / (2 - 2.0 * lightness_colour);
+ }
Also, this code calculates the lightness of original pixels:

Code: Select all

+ /* Original colour */
+ int r_current = GB(current, 16, 8);
+ int g_current = GB(current, 8, 8);
+ int b_current = GB(current, 0, 8);
+ /* Find max and min original colour */
+ int min_current = min(min(r_current, g_current),b_current);
+ int max_current = max(max(r_current, g_current),b_current);


+ /* Lightness original colour */
+ float lightness_current = (max_current + min_current) / (2 * 255.0);
My idea is to use the saturation of original color if its saturation is lower than the CC saturation.

Maybe this code could be added, but... I'm not a good C++ programmer.

Code: Select all

+ /* Saturation cc */
+ float saturation_current;
+ if (max_current == min_current) {
+ saturation_current = 0;
+ } else if (lightness_current <= 0.5) {
+ saturation_current = (max_current / 255.0 - min_current / 255.0) / (2.0 * lightness_current);
+ } else {
+ saturation_current = (max_current / 255.0 - min_current / 255.0) / (2 - 2.0 * lightness_current);
+ }
And add this code:

Code: Select all

if (saturation_current < saturation) {
 saturation = saturation_current;
} 
This should keep the saturation of pixels with low saturation.
Sorry if my english is too poor, I want learn it, but it isn't too easy.[/list][/size]
User avatar
GeekToo
Tycoon
Tycoon
Posts: 961
Joined: 03 Jun 2007 22:22

Re: [32bpp] Extra zoom levels, experimental new CC algorithm

Post by GeekToo »

Thanks Maquinista for the suggestion. Can you show a screenshot where you think it is currently not OK?

I'm currently in the process to convert that code to use all ints again (Szvengar updated the algorithm to use a lot of floats). After that, I will take a look at it.

Maybe we should even use the saturation of the original always, but I dont know whether that has some unwanted side-effects, we'll have to test that.
User avatar
Zephyris
Tycoon
Tycoon
Posts: 2890
Joined: 16 May 2007 16:59

Re: [32bpp] Extra zoom levels, experimental new CC algorithm

Post by Zephyris »

GeekToo wrote:Maybe we should even use the saturation of the original always, but I dont know whether that has some unwanted side-effects, we'll have to test that.
You'll find that some colour pairs, green and pale green in particular, will look similar if you ignore the saturation of the company colour... It will also make the company colour within a company much less uniform - when I designed the current algorithm (IIRC) I decided to completely ignore the sprites hue and saturation for this purpose.
maquinista
Tycoon
Tycoon
Posts: 1828
Joined: 10 Jul 2006 00:43
Location: Spain

Re: [32bpp] Extra zoom levels, experimental new CC algorithm

Post by maquinista »

GeekToo wrote:Thanks Maquinista for the suggestion. Can you show a screenshot where you think it is currently not OK?

I'm currently in the process to convert that code to use all ints again (Szvengar updated the algorithm to use a lot of floats). After that, I will take a look at it.

Maybe we should even use the saturation of the original always, but I dont know whether that has some unwanted side-effects, we'll have to test that.
The current algorithm creates sharp edges and sometimes oversaturates some areas.
Zephyris wrote:
GeekToo wrote:Maybe we should even use the saturation of the original always, but I dont know whether that has some unwanted side-effects, we'll have to test that.
You'll find that some colour pairs, green and pale green in particular, will look similar if you ignore the saturation of the company colour... It will also make the company colour within a company much less uniform - when I designed the current algorithm (IIRC) I decided to completely ignore the sprites hue and saturation for this purpose.
It will be ignored only in areas with low saturation. If a pixel of the original sprite is saturated, It will have the company color saturation. This is useful to keep the edges of the CC mask.

The only detail is that We should avoid to make sprites without saturated areas in the CC colour, like the building near the windsock.

The problem of the original algorithm is that It does not allow to add a CC mask in the window reflections or transparency, because It will look bad.
Attachments
The left screenshot has some original sprites over it with GIMP.
The left screenshot has some original sprites over it with GIMP.
saturation_problem.JPEG (356.28 KiB) Viewed 555 times
The bands looks bad in their edges.
The bands looks bad in their edges.
depot_water_problem.jpeg (51.93 KiB) Viewed 5615 times
Sorry if my english is too poor, I want learn it, but it isn't too easy.[/list][/size]
maquinista
Tycoon
Tycoon
Posts: 1828
Joined: 10 Jul 2006 00:43
Location: Spain

Re: [32bpp] Extra zoom levels, experimental new CC algorithm

Post by maquinista »

I have a question: Wath is the palette index that I should use in buildings with translations for "brownish red" colour (795-801)?

I'm coding this temperate building wich doesn't have ground sprite:
Image
It has these different color translations.


Also, I have made a preview with the water tower. I think that It will look better. I have made it with GIMP. The only pixels that are changed are the pixels in the borders of the CC area (pixels that contains CC color and colors that shouldn't be changed). The other pixels have a good saturation. We need to make the sprites with a good saturation, like most of the current sprites.
Attachments
Animated PNG file.
Animated PNG file.
animation_water_tower_cc_problem.png (117.15 KiB) Viewed 5513 times
Second preview.
Second preview.
cc_problem.jpg (92.03 KiB) Viewed 5513 times
Sorry if my english is too poor, I want learn it, but it isn't too easy.[/list][/size]
Post Reply

Return to “Graphics Development”

Who is online

Users browsing this forum: Amazon [Bot] and 21 guests