New experimental dual-background mask color

[jezek]

I read the dual-background mask feature in docs, and I wonder... Why make a new color mask (0a100a)? why not reuse the black color for bg mask?

When graphics is set to 2, then for item, character, monster and trap tiles the black bg color will be transparent and showing the underlying floor tile, which has the needed bg color (when bg colors will work in future).

When graphics is set to 1, then the black color will work as for now.

This way, there is no need for the new color (0a100a) for mask. Two mask colors is enough. Or is there something I didn't consider?

[EvgenijK]

Hi, there is a need for black outline or else foreground and background can look indistinguishable(or some parts of them), especially small/thin tiles.

You can see how tiles with outline look better then without:

[jezek]

Hi, @EvgenijK

you are right, with outline it looks better.

But I think, painting 3 masks into one tile puts too much strain onto the painter. Most games use only one mask (bg/transparency mask). When I coded the logic for graphics, first I had only 1 mask (bg), but then I discovered the fg color and I thought, that it would be easier to add one mask (fg) instead of painting every color combination for each tile. But having 3 masks is overkill.

The outline can be painted programmatically (there could be an option). Every pixel in bg mask that neighbors a non-bg mask pixel, is outline pixel. This could be computed at the beginning, when/after creating the bg mask from pixels. The computed outline could even have dynamic width, depending on the tile size. This way we could have outline and keep only 2 masks (bg, fg).

So unless you plan doing some special color effects using bg and fg color (the bg mask would not have the purpose of bg color), or unless you plan to have the bg color outline in different shape as the tile (I don't see a case when this is needed), there is no need for the 3rd mask painted into the tile image. Three masks would just confuse the graphics guys and add them more work.

Is there any example (I forgot to consider) where 3 masks are needed instead of 2 (plus auto-outline)?

[EvgenijK]

Well, i summon @CBlueGH here)

I dont feel drawing outline is cumbersome - can be done easy in gimp.

[CBlueGH]

Re: 2 masks:

The idea with the transparency mask being different was that we indeed have 2 definable colours per tile, foreground (varies) and background (was always black, except in test client, where some characters testwise actually have a background colour different from black). So a background colour can work as "transparency" if it is granted to be always black. But as soon as we actually want to support and use background colours, we need another way to define transparency, as the background colour is now an actual varying colour.

Hm, actually I'd like the colour "black" to just be available for use, for quality-of-life of people who draw tilesets, so their stuff can have pixels that are black instead of having them use "almost black" colour everytime as a workaround, just to make their job easier. Although if black becomes a background colour instead, that is maybe a problem. So actually, black 0x000000 should maybe just be a normal colour and a variable background colour should get a "special" low-collision value too...

Anyway, I decided to give the mask colours values that will really never collide accidentally with anything that you'd want to use as comfortable normal colour when creating tilesets. Eg the foreground colour from something that is much more likely to get used in drawing (0xff00ff) to something that won't impact artists much but choosing colour numbers that have almost zero chance of collision.

Of course in effect that means that we have "two variable colours" now, without any really qualitative distinction between "foreground" and "background" nomenclature (ie they could also just be called "fg colour 1" and "fg colour 2" instead) plus one transparency colour. Although I think the current implementation is not in a working state for having a bg colour different from 0x000000 and will then be in need of fixing^^ the two colour-masks (bg and fg) are not implemented symmetrically atm.

A concrete example how to use a background colour is for specifically those types of terrain that you expect to "be on other terrain" instead of being the "bottom-most terrain", for example trees: Trees currently "stand on" black background, and on the tree is maybe a monster that still has the tree visible thanks to its transparency. Now the tree however cannot again be transparent, because we don't send 3 tiles (eg 1=grass,2=tree on the grass, 3=monster on the tree on the grass) but only 2, otherwise it might really become toooo much. And it might become too much of a pixel salad? not sure here. So the tree however could simply utilize background colour, that varies depending on terrain the tree supposedly stands on, instead of just being black: The tree could have dark green background colour for grassland tree, or dark brown for tree standing on a mountain etc.

But for foreground tiles such as monsters, objects, players, I think having a background colour is indeed mostly superfluous, at least I cannot think of a good use off the bat atm. (For example we probably want ego-monsters to flicker their foreground colour as they always did, because people are used to it, and not utilize the bg colour for ego power indication.) I thought though that there was no need to remove the background colour and have it reborn as transparency colour, removing potential future options thereby. But that we could just have both just in case we ever want to use it. To my knowledge so far there were no problems regarding drawing speed.

Last but not least: There is currently an annoying bug that messes up the screen on sunrise/sunset, but only for Windows clients. I was unable to reproduce it on Linux or on WINE. So far I haven't been able to find it - and I don't have/use Windows -_-.

Re: Outlines

Looks good yes, some foreground tile + terrain tile combos are indeed not that well visible.

[jezek]

Re: Re: 2 masks:

You are right, I should have chosen other color for bg mask as #000000. Maybe something like #330033. I read somewhere, that the color #ff00ff is used as mask, because this color is seldom to find in nature. But this is an easy fix. Let's have the bg, fg (and transparency) color codes configurable in .tomenerc (or TomeNET.ini). This way should be everybody happy. :)

So you wan to keep current 3 mask system, cause you plan to utilize the current bg color as fg2 color. So in future there will be fg1, fg2 and transparency mask instead of fg, bg and transparency. Wouldn't this collide with the terminal (gcu) version?

Here is the colorful "grass, tree, monster" example with only two masks. Let's say the terrain color is "dark green". When there is only "grass and tree on the grass", the grass tile will have the bg color solid "dark green" and the tree will have the bg color transparent. You will see tree on grass on dark green background. Then the monster comes so there will be "grass, tree, monster" on one tile. The server sends only 2 tiles, so the client gets "tree, monster on tree". Now the tree's bg color will be terrain color (dark green) and monster's bg color will be transparent. You'll see monster on tree on dark green background. See, no need for 3 masks and everything is as intended. Or did I misunderstood the example? (Note: I don't talk about the outline, this can be done automatically)

I'm not against the 3 mask system (fg1, fg2, transparency). I'm just saying, when there is no fg2, only fg & bg colors, there is no need for 3 masks.

Anyway, maybe this can change in near future. Currently I'm in the middle of writing a SDL2 client. This way we could have only one graphics codebase for linux & windows and there will be no need to write everything graphics related twice. And I think, SDL2 supports real transparency (R,G,B, Alpha), so there will be again only 2 masks and transparency mask will be in the Alpha channel. If you have any ideas for the sdl2 client, I'm all ears.

Thanks for your answers, I'll come back, when I have the SDL2 client working (hope soon).

Note: I don't know if it is the case now, but last two times I compiled the linux client from latest github (about one and two weeks ago), the fg color mask in my tiles (#ff00ff) did not get replaced with fg color (everything was pink).

[CBlueGH]

Wow @ sdl client :O!

Yes you are right, in effect, 2 masks could do the trick (just fg and bg).

I just thought, having 2 variable colours instead of just 1 might be nice, as it carries over the "foreground colour + background colour" state of things from text mode (ie in theory TWO variable colours, although we really use only one in TomeNET except for things like skill menu background in the test-client), while giving the additional "transparency" feature of graphics.

Your graphics are purple because as mentioned I changed the mask colours to much more unlikely to collide values. These are now (sorry, the guide still partially mentioned the outdated values): 0xfc00fb (252,0,251) fg, 0x3e3d00 (62,61,0) bg, 0x1d211c (29,33,28) transparency.

EDIT: Sorry, changed the transparency colour once more (to the value above, was 0x0b100a before that). Reason was that it was simply so dark that editing tilesets was annoying.