32bit Extra Zoom Graphics Works In Progress

[Wacki]

Yes, it is really great now!!!

[Belgabor]

Couldn't agree more, perfect

[maquinista]

This file has all the trucks modeled by CryingCorvus and coded by habell. I have fixed the CC masks.

I must update a tropical house, because the sprite has been moved to OPENTTDW.GRF file.

[Dabas]

Trucks by CryingCorvus are great, but the CC unification is needed. I think that red at the Teemes bus is the best.

[maquinista]

Trucks by CryingCorvus are great, but the CC unification is needed. I think that red at the Teemes bus is the best.

Yes, but I think that It is a problem of the algorithm that converts the original colours in CC colors. It shoud be like the GIMP's layer mode "hue". I don't know if this can be changed.

I have coded the lumbermill modeled by Wacki.

[CryingCorvus]

Awesome lumbermill.

Yes, but I think that It is a problem of the algorithm that converts the original colours in CC colors. It shoud be like the GIMP's layer mode "hue". I don't know if this can be changed

Please solve the problem becouse trucks I make now (including already done mail trucks) are in blue colour, same as varivars trucks. Its bunch of sprites to rerender

[GeekToo]

Yes, but I think that It is a problem of the algorithm that converts the original colours in CC colors. It shoud be like the GIMP's layer mode "hue". I don't know if this can be changed.

That's exactly what the algorithm does now: change the hue, and leave the brightness and saturation as in the original sprite. The problem here is that the tanker's brightness is less than the brightness of the mailtruck in the original sprites. And also the saturations differ, the tanker is less saturated. So imo the algorithm is doing what it is supposed to do. You can try it yourself: take the original sprites, and make the colours as equal as possible by changing with a hue layer, without changing the brightness or saturation.

If you (or Crying Corvus, or anyone else) can find a better way to make the colours equal, please describe the steps you took and post some png's, the algorithm can of course be changed.

The attached picture shows the comparison of the sprites with the same hues for top of the two trucks.

[CryingCorvus]

I can see that all original trucks are orange like my mailtruck when company colour is set to red....
same for Varivar's trucks

[maquinista]

The problem in CC is that there are a few hues used (blue, red, yellow and green) in 8 bpp games is not a problem because these hues are used with different saturations and brightness. This could be solved using more hues in 32 bpp extra zoom.

This is the station graphics. These files doesn't look good at z2 level. They should be downscaled for this zoom level. Z1 and Z0 levels looks good. There are more details to fix. Also, I'm coding the semaphores.

[Slye_Fox]

nice, but i still got the old "glass" ontop of the new station

[maquinista]

Have You downloaded train.tar file? I have updated it. I have deleted some platforms from Ben_Robbins_, and I have added four 1×1 sprites to replace the "old" glass.

I have seen this model:


Do You have updates of this model?

I think that It is interesting.

[Slye_Fox]

http://www.tt-forums.net/viewtopic.php? ... 5&start=20

[CryingCorvus]

The problem in CC is that there are a few hues used (blue, red, yellow and green) in 8 bpp games is not a problem because these hues are used with different saturations and brightness. This could be solved using more hues in 32 bpp extra zoom.

Yes but Im still worried about things that are already coded. Trains are correctly red but Varivar propobly never rerender his trucks and I can only stick to this colour. Rerendering with saturated green can help but this needs coding again by Habell and this can be too much. Weird thing is that other colours work correctly
Anyway I see that little squer in CC selector showing red colour is also orange, wicked

[Teemes]

Trucks by CryingCorvus are great, but the CC unification is needed

Yeah, I second that.
It's all an issue of the HSV values of the rendered sprites, as GeekToo pointed out in his post, (not the overlays that are applied in the game or stuff like that).
Anyway, If we'd all use similar values, the problem of differing company colours would cease to exist. A quick look into the vehicles by different posters shows the following:

• (Hue[1]; Saturation; Value[2])
  Varivar: 216, 100, 65
  CryingCorvus("blue" lorries): 214,99,45 (nice replication of varivar's colours)
  CryingCorvus("green" lorries): 120, 46, 27 (quite different, doesn't fit in as nicely [3])
  Teemes(bus): 0,100,35 (very bright and cartoonish)
  Teemes(trains): 230,74,35 (replicates SlyeFox's and ben_robbins' wagons [4])

[1]: please note: for each 120° of hue the resulting company colour looks the same, as GeekToo pointed out. CryingCorvus' Hue of 120 for the green lorries is equivalent to a hue of 240. Same for Teemes' hue of 0=120=140.
So the list above could also read Varivar:216, CC("blue"): 214, CC("green"): 240 T(bus): 240, T(trains): 230.

[2]median value (sort of). The V values varies greatly depending on the orientation towards the light source, so it's impossible to determine the "real" V values without looking into the .blend files (which I can't ATM, my home computer's still not working)

[3]mainly because of the very low S value, but H is also a bit off (although see [1])

[4]slightly lower S value, makes the train vehicles look "grittier", quite suitable IMHO.

I guess the H+S values for trains are pretty much set in stone, as we don't have the .blend files from Slye_Fox and ben_robbins, and I guess nobody wants to repeat their amazing effort of creating all the train wagons.
For varivar's trucks we also don't have the .blend files, so we'd either have to redo all his trucks (which would be a waste of time and effort, as his models were excellent) or we have to set his colour values as the new norm for road vehicles (and have the red company colour look slightly orange because of the H value (240 would show up as red, his value is 216).

Hum, pretty long post, anyone still with me? I guess the "best" way to settle this issue would be a poll, but I think the options should be discussed first. Any opinions?

By the way: moral of this - post your .blend files and allow others to modify them (Creative Commons or related stuff)

[GeekToo]

Very nice post Teemes, good description of the problem area.

When I implemented the CC for the extra zoom level, I experimented a lot with different blend methods, and that resulted in the algorithm as it is now.

We could of course change the algorithm, so that every pixel with CC mask gets the same hue (that was my first implementation), but you lose a lot of detail on the hue-gradients. It turned out that the 3d-renderers use a certain hue-range, depending on light and reflection etc, instead of one fixed hue for a certain material colour. Changing all the pixels to one hue does give noticable loss of detail.

Unfortunately, the colour remapping is done in the blitter, ie it is done on a per pixel basis, which means the algorithm must be fast, and there's no time to scan a certain mask to determine the 'median hue' in a masked area.

So that leaves a couple of options:
-standardize the render colour (which is basically your proposal).
-specify the median hue, I'm thinking of adding a field when Pngcodecing a sprite.
-determine the median hue when loading the sprite, which would give some performance loss when lots of sprites need to be loaded (typically zoom-in/out or startup).

Solutions 2 and 3 would mean changes to the algorithm, solution 1 and 2 to the already rendered sprites (or pngcodecing of the sprite).

I'm not sure which is the best solution, any opinions would be appreciated.

None of the descibed solutions will solve the problem of the grayscale mapping: if you use a lightgrey CC or a darkgrey CC, currently that will result in the same colour, which also is a little yellow. Maybe I should change some things, so every CC has a different hue, iso also using brightness to distinguish different CC's

[CryingCorvus]

For most of us there's no problem, but where's varivar? For now I have changed and rendered all green lorries to blue one. I think the idea of varivars colour as norm take less effort for some of us Also this orange colour p*** me off when everything is red, I hope it is some possibility to change code for road vehicles to something that will modify colours of the trucks to exacly specified hue range when you chose "red" option. I know this will need some good programmer(ist?) but this is only an idea.

eeeee nevermind. I see u tried everything (propably)
I bet on specifying the median hue, "I'm thinking of adding a field when Pngcodecing a sprite."

[flowover]

I must be doing something wrong. A couple problems here.

First, whenever I have a road set in my data folder, the closer zooms show glitched out seperate screen regions where ever a city road intersection should be. I see all these other screen shots that it doesn't occur in, so I'm led to believe it must be my configuration.

Second, I can't get these graphics working in tandem with openGFX. I replaced all the trg folder names inside the .tar files with opengfx. I think I was properly following Zephyris' advice. Still no loading though.

IIRC the way 32bpp graphics are "coded" is by putting them in a folder (in a .tar) which has the same name as the grf which includes the sprites the 32bpp graphics are supposed to replace. To get the 32bpp graphics to work for OpenGFX the folder needs to be renamed appropriately, eg. trg1r.grf --> opengfx1r.grf

Is this even the right thread to ask these questions in? I didn't want to use the problems forum as this is a fringe topic.

[LordAzamath]

So what's the file path to the sprites?

[Teemes]

So that leaves a couple of options:
-standardize the render colour (which is basically your proposal).
-specify the median hue, I'm thinking of adding a field when Pngcodecing a sprite.
-determine the median hue when loading the sprite, which would give some performance loss when lots of sprites need to be loaded (typically zoom-in/out or startup).

Thanks for the insight into your patch, GeekToo! I didn't know about the inner workings and could only propose a solution that doesn't require a modification of the patch. But considering the options you proposed, I'm strongly in favour of solution #2, the extra field in the .png. All incompatible render coulours could easily be modified that way, with (next to) no performance loss.
I'd be glad if you'd implement that solution into the patch, please let us know the results when you attempt it.
Irregardless, it would still be nice to have a "standard" render colour, so only the irregular sprites would need that extra field, which would make coding a bit easier...

[maquinista]

This is the TAR file with the depots coded: