Transport Tycoon Forums

I am almost done making a transparency-options toolbar for TTDPatch like OpenTTD's toolbar:(That question-mark is for toggling invisible trees, and yes, I need a new sprite for that, but that's not particularly germane to this discussion.)
I had hoped that Open provided a defined behaviour for variable 1B, bit 4 (transparency) that I could copy, but it does not.

On discussion, there are two competing views of the definition for that bit:
1) That bit is clear[0] if anything is transparent, and set if nothing is transparent. An additional variable should be provided to specify which items are transparent.
2) That bit is clear if the current feature is being drawn transparently, and set if the current feature is being drawn non-transparently.

Both mean a change. For #1, transparency might even be indicated just because station signs are being drawn transparently (CC text without a background box, instead of black text on a CC background box). For #2, transparency would not be indicated to things like vehicles and cargos, unless it becomes possible to, for example, toggle transparency for vehicles.

So, I think the questions are:
A) Which is less likely to break existing code, if any?
B) Which would you consider more useful?

[0] Logical or not, this part is obvious. Clear means transparent and set means non-transparent.

The main idea of that discussion is to find which of the two behaviours would be the most appropriate.
Or even a better solution.
Remember that the call to that variable is done during callbacks, therefor, it is linked to the feature triggering the call.
An industry callback would return if industry is set as transparent.

It could be important for writers who would like to see some parts of their work use this or that sprite while in transparency mode, as an example.

So we are awaiting your comments, guys

Another query is: does anyone actually use this bit anyway?

DaleStan wrote:On discussion, there are two competing views of the definition for that bit:
1) That bit is clear[0] if anything is transparent, and set if nothing is transparent. An additional variable should be provided to specify which items are transparent.
2) That bit is clear if the current feature is being drawn transparently, and set if the current feature is being drawn non-transparently.
So, I think the questions are:
A) Which is less likely to break existing code, if any?
B) Which would you consider more useful?

Currently it would not break my code, but for my taste (I do not have more sensible reason now) the second solution is better. But, again, it is only a question of taste. So, I would of cause agree with the first solution if any reason is provided (easy coding for example).

peter1138 wrote:Another query is: does anyone actually use this bit anyway?

I don't know either way on this, but I do know that when drawing transparent bridges, I remove the tram sprites completely, rather than drawing them transparently. It seems reasonable that someone might want to do something similar with other features.

As 1B is directly linked to bDisplayOptions, you can't change the meaning.

As seen in the commented variable:
+10h No building transparency

The comment should be checked if it's correct and the missing data added to the wiki...

If you want something more special
a) new flag to displayoptions
b) create a new variable, the meaning is up to you.

If you name the variable transparentoptions, a bit set should enable transparent drawing mode.
If I press a button on the toolbar, it should enable transparency for that feature... (and not do the opposite)

eis_os wrote:As 1B is directly linked to bDisplayOptions, you can't change the meaning.

As seen in the commented variable:
+10h No building transparency

Yes, I can. And did. It's now "+10h Meaningless". (I can also fudge its value at entry to getnewsprite.)

eis_os wrote:The comment should be checked if it's correct and the missing data added to the wiki...

It *was* correct. It is no longer correct.
Every instruction that reads that bit, and most instructions that write it, have been either changed or removed. The only reading instruction I can't remove (or ignore on the grounds that the flags it sets aren't tested) is the one that hands variable 1B to the GRFs.

eis_os wrote:a) new flag to displayoptions

Not nearly enough space. I've got 10 or 11 (depending on whether you count hidetranstrees) bits worth of transparency options now. Plus it doesn't solve the problem.

eis_os wrote:b) create a new variable, the meaning is up to you.

Which also doesn't solve the problem: If houses are transparent and stations are not, should bit 4 of var 1B be set or clear? And does the answer depend on whether we're currently drawing stations or houses?

eis_os wrote:If you name the variable transparentoptions, a bit set should enable transparent drawing mode.
If I press a button on the toolbar, it should enable transparency for that feature... (and not do the opposite)

Yes, it works that way, in both cases. But that implementation detail is not relevant to whether and when to set/clear bit 4 of var 1B, which is what I want opinions on.

Maybe it wasn't that obvious in my post, so I repeat it.
First, you aren't allowed to change the meaning, read the following.

To be exact the meaning is, if buildings should be drawn transparent or soild. Station signs are the wrong example. This bit doesn't have anything to do with it by definition. This is documented in the wiki as being the display options, so the IDB tells use the definition. GRF Authors like Michael use the IDB to check the meaning.

Btw. What happens with the t transparency key?

You have two classes, the Action321 based ones can access that byte and the other can't.
The meaning for a building is defined by the thing you draw and by the feature. bDisplayOptions bit setting has to be emulated so it shows the right bit setting in this context. If you want to check other "features", you will need an extra variable. *

(Note: canal locks may have buildings too)

The other things like trees can't be controlled by action2, so there is no problem, they can't access that byte. **

* If a tree is on a station, the grf checks for the building option as before, or tests for the new variable if the tree should be transparent, but generally transparency is controlled by TTD and not the grf, the grf can only opt in to show something different (a new station layout). I can't see any reason why someone needs to know that state. Again, it's up to TTD to know the style of a tile, not the grf author... (Station allows to bypass the building transparency setting, still it means the station building in this context)

Or in a quite simple hack:
Change bDisplayOptions to set to the right context.
Call ClassXDrawLand

-edit-
** If you later want that feature to know a transparency setting, you have to emulate a transparency setting somehow, a) you have an own setting, or the better b) option, the display setting building definition for that feature is an actual an alias for tree transparency, you still get some kind of context... and so you can decide it context wise again.

After all how you name it, the building transparency setting can be only seen in the context. So after all the meaning is already fixed implicit. The only real way is #2.

Ohh, and GUI wise, this means to get the old behavior back, you need an extra button/way, to enable all/disable all transparency.

eis_os wrote:Maybe it wasn't that obvious in my post, so I repeat it.
First, you aren't allowed to change the meaning, read the following.

It's already too late for that; OpenTTD has an undefined value for that bit. One of the objects here is to provide a definition that Open can obey too.

eis_os wrote:What happens with the t transparency key?

If nothing is currently transparent, [t] restores the previous transparency settings. If anything is transparent, [t] saves the current setting and clears all transparency bits.

eis_os wrote:You have two classes, the Action321 based ones can access that byte and the other can't.
The meaning for a building is defined by the thing you draw and by the feature. bDisplayOptions bit setting has to be emulated so it shows the right bit setting in this context.

So what you're saying is that when drawing stations, var 1B bit 4 must be set if stations will be drawn transparently and clear if they will be drawn normally; when drawing industry tiles, var 1B bit 4 must be set if industry tiles will be drawn transparently and clear if they will be drawn non-transparently; and so on?

And for vehicles, cargos, &c.? Can I wrangle "undefined for features 00..04, 06, 08, 0B, 0C, and 0E"? Or do we have to have a definition, and if so, how many of which new transparency bits need to be set before we clear bit 4?

eis_os wrote:(Note: canal locks may have buildings too)

They do not have a test for displayoptions in Patch code, nor do they appear to draw through one of TTD's test [displayoptions], 10h instructions, so they're not currently relevant. Or do you mean that they may, but ttdpbase[w].grf doesn't take advantage of this feature? If so, I can easily attach the feature 06 definition to the "ship depot transparency" bit, and call it the "non-station water structure transparency" bit instead. But that, by itself, won't cause the canal or lock walls in ttdpbase[w].grf to be displayed transparently.

eis_os wrote:Or in a quite simple hack:
Change bDisplayOptions to set to the right context.
Call ClassXDrawLand

That involves finding and patching the calls, which might be unpleasantly interesting. I already have it working properly by patching the tests in ClassXDrawLand.

eis_os wrote:I can't see any reason why someone needs to know that state.

DaleStan wrote:... when drawing transparent bridges, I remove the tram [track] sprites completely, rather than drawing them transparently. It seems reasonable that someone might want to do something similar with other features.

eis_os wrote:Ohh, and GUI wise, this means to get the old behavior back, you need an extra button/way, to enable all/disable all transparency.

Or you whack [t]; the initial value for "previous transparency" is the old default. Or you turn off the switch.

DaleStan wrote:

eis_os wrote:Maybe it wasn't that obvious in my post, so I repeat it.
First, you aren't allowed to change the meaning, read the following.

It's already too late for that; OpenTTD has an undefined value for that bit. One of the objects here is to provide a definition that Open can obey too.

Well if they don't support the specs for it, they have to emulate it or risk that a grf may not work.

DaleStan wrote:So what you're saying is that when drawing stations, var 1B bit 4 must be set if stations will be drawn transparently and clear if they will be drawn normally; when drawing industry tiles, var 1B bit 4 must be set if industry tiles will be drawn transparently and clear if they will be drawn non-transparently; and so on?

The specs say exactly the opposite, it's set when solid, a reason why I told it should be checked again, but yes, otherwise it's exactly how it should work.

DaleStan wrote: And for vehicles, cargos, &c.?
[..]
Can I wrangle "undefined for features 00..04, 06, 08, 0B, 0C, and 0E"?

Well currently they are undefined for all tile drawing operation without building context.

So I would suggest this definition:
00..04 transpareny for vehicles in the future (Note: TTD has the concept of fully transparent in tunnels)
06 transparency for bridges, (you seem to already use it with trams)
08 undefined, it's an global variable, it has no context.
0B the context is defined by the thing it want to draw, so you can't define it properly.

0C For sounds, atleast on tiles with buildings it means something, but I don't think we ever need that, well or do you want to hear more when you can see into some buildings? I guess for industries it may be a nice idea...

0E undefined.


Canals: As canal is action based, you can use a test on displayoptions. The drawing routine doesn't really need to know that, I don't think there is a good way to use it, but it is defined via common:

http://wiki2.ttdpatch.net/tiki-index.ph ... nalAction2

It's accessable and has a meaning, as locks may have houses... You view is ttdpbase[w].grf centered with canals. Michael has a grf for canals too. Well not released since ages...

DaleStan wrote:

eis_os wrote:I can't see any reason why someone needs to know that state.

... when drawing transparent bridges, I remove the tram [track] sprites completely, rather than drawing them transparently. It seems reasonable that someone might want to do something similar with other features.

You remove them by GRF test or by assembler code? And if it's done by grf you already attached the right meaning, If bridges get drawn with transparency, you don't want that be influenced by say the houses...

eis_os wrote:The specs say exactly the opposite, it's set when solid, a reason why I told it should be checked again, but yes, otherwise it's exactly how it should work.

No, the specs merely say "transparency". They imply, yes, but they fail to specify whether set or clear means transparent. Unfortunately for everyone's sanity, TTD draws things transparently when that bit is clear.

DaleStan wrote:And for vehicles, cargos, &c.?
[..]
Can I wrangle "undefined for features 00..04, 06, 08, 0B, 0C, and 0E"?

Oh bah humbug. I scrambled the features there. I meant "undefined for features 00..03, 05, 08, 0B, 0C, and 0E".

I hope that change covers your bridge comments, but just in case there's still a misunderstanding on canals:

eis_os wrote:Canals: As canal is action based, you can use a test on displayoptions.

But it uses the vehicle-style standard 2s. As far as I can tell, this means you can't specify multiple sprites, varying bounding boxes, or other things that make transparency detection particularly useful. But as I have the code now, it's quite easy to define that bit for canals in relation to the ship-depots transparency bit.

eis_os wrote:

DaleStan wrote:... when drawing transparent bridges, I remove the tram [track] sprites completely, rather than drawing them transparently. It seems reasonable that someone might want to do something similar with other features.

You remove them by GRF test or by assembler code?

Assembler, as bridges don't have graphic-selection 2s. If this turns out to conflict with some future changes to the bridge drawing, then it can go; I'm not attached to it. I did it because it seemed like a good idea.

So, the documentation for 1B would get the following text added:

Bit 4 is:

• Undefined if the item currently being drawn is never drawn transparently, (features 00..03, 05, 08, 0B, 0C, and 0E) except industries, (feature 0A) which follow the definition for industry tiles.
• Clear if the item currently being drawn (or for which the callback is being called) would be/was/will be drawn transparently.
• Set if the item currently being drawn (or for which the callback is being called) would be/was/will be drawn normally.

I'm also not attached to revealing the industry-tile drawing mode to industries; it, too, just seemed like a good idea.

DaleStan wrote:

eis_os wrote:The specs say exactly the opposite, it's set when solid, a reason why I told it should be checked again, but yes, otherwise it's exactly how it should work.

No, the specs merely say "transparency". They imply, yes, but they fail to specify whether set or clear means transparent. Unfortunately for everyone's sanity, TTD draws things transparently when that bit is clear.

With specs I did mean the IDB database here.

DaleStan wrote:

eis_os wrote:Canals: As canal is action based, you can use a test on displayoptions.

But it uses the vehicle-style standard 2s. As far as I can tell, this means you can't specify multiple sprites, varying bounding boxes, or other things that make transparency detection particularly useful. But as I have the code now, it's quite easy to define that bit for canals in relation to the ship-depots transparency bit.

If it's possible to add later it's ok to let it currently be undefined.
As I said, currently there is no good way to use it right.

Note: Canals have the "Add sprite offset callback (147)", generally it would be possible to show a different sprite depending on this transparent state.
Say, you could hide a building by using a different sprite (without building), this callback isn't yet used much and doesn't cover all features

DaleStan wrote:

eis_os wrote:

DaleStan wrote:... when drawing transparent bridges, I remove the tram [track] sprites completely, rather than drawing them transparently. It seems reasonable that someone might want to do something similar with other features.

You remove them by GRF test or by assembler code?

Assembler, as bridges don't have graphic-selection 2s. If this turns out to conflict with some future changes to the bridge drawing, then it can go; I'm not attached to it. I did it because it seemed like a good idea.

For later compatibility I wouldn't want to expose this flag to grfauthors now and let it decide by ttdpatch code only. Later it can be changed....

DaleStan wrote: So, the documentation for 1B would get the following text added:

Bit 4 is:

• Undefined if the item currently being drawn is never drawn transparently, (features 00..03, 05, 08, 0B, 0C, and 0E) except industries, (feature 0A) which follow the definition for industry tiles.
• Clear if the item currently being drawn (or for which the callback is being called) would be/was/will be drawn transparently.
• Set if the item currently being drawn (or for which the callback is being called) would be/was/will be drawn normally.

I'm also not attached to revealing the industry-tile drawing mode to industries; it, too, just seemed like a good idea.

I would suggest to say undefined for all except the ones mentioned. This makes the whole more robust as soon as we add new features ... So something like this:

The transparency bit is undefined for all actions except for the following features with various meaning:
Note: When this bit is set, solid drawing is used, otherwise TTD will draw in transparency mode.
[insert list with feature and meaning]