[3.4-dev] Problems with tiles in alphablend/overdraw mode

[PowerWyrm]

Found the following problems while experimenting with tiles using alphablend/overdraw:
- the Win32 client doesn't display those tiles properly: this comes from the fact that Term_pict_win_alpha() should be used for the "pict_hook" hook, but it is still defined as Term_pict_win() in term_data_link()
- all clients don't refresh the cursor properly when using the "look" command on a double-height tile

[Blue Baron]

Found the following problems while experimenting with tiles using alphablend/overdraw:
- the Win32 client doesn't display those tiles properly: this comes from the fact that Term_pict_win_alpha() should be used for the "pict_hook" hook, but it is still defined as Term_pict_win() in term_data_link()
- all clients don't refresh the cursor properly when using the "look" command on a double-height tile

Term_pict_win_alpha is supposed to be set in Term_xtra_win_react (around line 1751), after the graphics are initialized. Is this not happening? the alpha function hook is not set in term_data_link because the alpha function is slower than the blitting function and should only be used when needed. (It should not be used for the 8x8 - 32x32 tile sets.)

for the cursor not refreshing properly, I thought it had always been there. However it may be that the first tile of the tile sheet is fully transparent/masked, when it should be opaque black. I guess that the first tile is used for blank spots as well as hidden stuff like lurkers (in the past).

Edit: actually the above is not correct. it relates to the larger tile sizes. with 1x1 tiles the cursor refreshes properly.

Edit2: it turns out the problem was in the pref file. it was just that the coordinates of the nothing tile were off the tile sheet. The fix for Shockbolt's tileset and the UT32 tileset will be in a pull request shortly. (as long as this computer holds out.) It still shows up with text and tile multipliers, but I don't know what to do about that.

[PowerWyrm]

One problem comes from the fact that the cursor is drawn with Term_pict and erased with Term_text. A second problem comes from the fact that double-height tiles use "Term_mark" which sets the attr/char to "Term_blank" on both top and bottom parts of the double-height tile, forcing Term_text to be called with non-info.

I've fixed the first problem (which also occurs with the normal 16x16 and 32x32 tilesets in > 1 width/height mode) with the following code in Term_fresh():

            /* Hack -- Restore the actual character */
            else if (oa || Term->always_text)
            {
                if ((((tile_width > 1)||(tile_height > 1)) && (!smlcurs) && (Term->saved == 0) && (ty > 0) && !((tx == scr->cx) && (ty == scr->cy))) || bigcurs) 
                {
                    int i, j;

                    /* Hack -- Erase a big cursor */
                    for (i = tx; i < tx + tile_width; i++)
                        for (j = ty; j < ty + tile_height; j++)
                            (*Term->text_hook)(i, j, 1, old->a[j][i], &old->c[j][i]);
                }
                else
                    (*Term->text_hook)(tx, ty, 1, oa, &oc);
            }

For the second problem, I didn't completely understand the code behind Term_mark(), so I'm struggling a bit to find a solution. But clearly, the double-height tile should keep its attr/char info, at least for the top part. Maybe it's just a question of considering the tile as having height = 2 * tile_height and modify the code accordingly...

[buzzkill]

Edit2: it turns out the problem was in the pref file. it was just that the coordinates of the nothing tile were off the tile sheet. The fix for Shockbolt's tileset and the UT32 tileset will be in a pull request shortly...

I noticed this when updating UT32 to v3.3.2 just a few days ago. Darkness, all three shades (previously mapped to 0x7? something), is now mapped to 0x80:0x80 in my repo. Is that the correct solution?

[Blue Baron]

One problem comes from the fact that the cursor is drawn with Term_pict and erased with Term_text. A second problem comes from the fact that double-height tiles use "Term_mark" which sets the attr/char to "Term_blank" on both top and bottom parts of the double-height tile, forcing Term_text to be called with non-info.

The first problem is because of the wrong info in the pref files (graf-dvg.prf and graf-shb.prf). the coordinates in the f:0 lines should 0x80:0x80, which is a tile glyph (which gets drawn at the right size). The coordinates that are there now are 0x79:0x79, which is a text glyph, and drawn at the font size. Setting the coordinates in the pref file to 0x80:0x80 fixes the issue for me.

Term _mark sets the attr/char pair of the old screen info so the current screen info would be considered a change and be drawn again, without actually changing the current info. (only changed areas are drawn). term_mark only sets the old screen info, which is not drawn, and expands the dirty rectangle, which controls what is tested to be drawn.

However, term_mark is a problem because it causes more draws than necessary. It is possible for term_mark to cause extra drawing every frame for a while, even if nothing changes. But term_mark was the only way I could get the double high tiles to draw properly with the current framework. (since creatures around and behind the double high creature can move without the double high creature moving.)

Also, there isn't an attr/char pair for the top part. its just if a tile is drawn from a particular set of rows in the tileset, the tile above is drawn as well. it works because except for the cursor, the dirty areas are drawn from the top down. A major graphical limitation of the current framework is that regardless of the number of layers in the cave grid, only two are drawn. If there were an attr/char pair for the top part, the program wouldn't be able to draw a creature beneath it.

So you were seeing the cursor not refreshing when moving around blank areas with the 16x16 tileset? when I looked at it on my computer, the cursor was being erased after it moved. are you seeing something different?

[Blue Baron]

I noticed this when updating UT32 to v3.3.2 just a few days ago. Darkness, all three shades (previously mapped to 0x7? something), is now mapped to 0x80:0x80 in my repo. Is that the correct solution?

Yes it is. (If Powerwyrm and I are talking about the same thing : )

Also, in the pull request I made a little while ago, I included a UT32 tileset from late January with a some extra tiles for the trap detection border, piles, and some space for shaded doors,stairs. (Too answer a question you asked in another thread, AFAIK all features can use the shaded tiles.)

I attempted to download your current UT32 now, but this computer is acting up again. Anyways the graf-dvg.prf I uploaded a little while ago should have all of the features in it for 3.4-dev.

Lastly, the wrong coordinates for feature 0 were also in 3.2.0, so you might want to check your new file (since you did not mention it above).

[buzzkill]

I may have lost or abandoned my Vanilla 3.2 graf-dvg.prf at some point. I can't seem to locate it, but my Vanilla 3.3.2 files have been corrected. I won't update mediafire/buzzkill until about 4PM EST today as I'm presently working on UT32, so any changes made today won't be available to the public until this evening.

I also noticed that the darkness tile was transparent in UT32. That may have been on oversight on my part when I created the png (overzealous masking). I'm not sure if that's also the case with the png currently being distributed with Vanilla or not. Fixed on my end, fresh UT32 files will be available later today.

[PowerWyrm]

I noticed this when updating UT32 to v3.3.2 just a few days ago. Darkness, all three shades (previously mapped to 0x7? something), is now mapped to 0x80:0x80 in my repo. Is that the correct solution?

In graf-dvg.prf, the <darkness> tile should be remapped to "F:0:all:0x80:0x80" yeah. Dunno the reason why it was mapped to something outside the tileset...

[PowerWyrm]

I may have lost or abandoned my Vanilla 3.2 graf-dvg.prf at some point. I can't seem to locate it, but my Vanilla 3.3.2 files have been corrected. I won't update mediafire/buzzkill until about 4PM EST today as I'm presently working on UT32, so any changes made today won't be available to the public until this evening.

I also noticed that the darkness tile was transparent in UT32. That may have been on oversight on my part when I created the png (overzealous masking). I'm not sure if that's also the case with the png currently being distributed with Vanilla or not. Fixed on my end, fresh UT32 files will be available later today.

The darkness tile is transparent because the drawing function first draws a black background before adding background and foreground tiles.

[PowerWyrm]

The first problem is because of the wrong info in the pref files (graf-dvg.prf and graf-shb.prf). the coordinates in the f:0 lines should 0x80:0x80, which is a tile glyph (which gets drawn at the right size). The coordinates that are there now are 0x79:0x79, which is a text glyph, and drawn at the font size. Setting the coordinates in the pref file to 0x80:0x80 fixes the issue for me.

Term _mark sets the attr/char pair of the old screen info so the current screen info would be considered a change and be drawn again, without actually changing the current info. (only changed areas are drawn). term_mark only sets the old screen info, which is not drawn, and expands the dirty rectangle, which controls what is tested to be drawn.

However, term_mark is a problem because it causes more draws than necessary. It is possible for term_mark to cause extra drawing every frame for a while, even if nothing changes. But term_mark was the only way I could get the double high tiles to draw properly with the current framework. (since creatures around and behind the double high creature can move without the double high creature moving.)

Also, there isn't an attr/char pair for the top part. its just if a tile is drawn from a particular set of rows in the tileset, the tile above is drawn as well. it works because except for the cursor, the dirty areas are drawn from the top down. A major graphical limitation of the current framework is that regardless of the number of layers in the cave grid, only two are drawn. If there were an attr/char pair for the top part, the program wouldn't be able to draw a creature beneath it.

So you were seeing the cursor not refreshing when moving around blank areas with the 16x16 tileset? when I looked at it on my computer, the cursor was being erased after it moved. are you seeing something different?

Nope, the problem happens in only two cases:
- browsing dark areas with 32x32 tiles (fixed with changing graf-dvg)
- looking at unmapped tiles (no entry in graf-xxx, tile displayed as an ASCII symbol); that was the reason for adding the code to erase a big cursor when using Term_text